Consumers might drive your company, but software makes it possible for those consumers to access and purchase your products and services. Not only that, but software makes it possible for your staff to interact with consumers and even work with your backend.
In other words, without software, your company would struggle.
You might purchase the applications you use from nearshore software developers, a local development firm, a “big box” company, or you might even develop them in-house. Java, JavaScript, .NET, Python—programming languages across the board can serve these purposes. No matter the language or where you get your software from, it has to work.
Unless you’ve managed to find the promised nirvana of software that works without flaw or vulnerability, you know the routine. You deploy a new piece of software and wait for the problems to occur. And when issues creep into the pipeline, you address them.
However, you can’t address a problem until you know the said problem exists. How does that work out?
Bug reporting.
Two words that send end users (and some software engineers) into eye-rolling fits of despair. Why? Getting users to actually submit bug reports can be an exercise in futility. This happens for a number of reasons, such as:
- It’s not always easy.
- It takes precious time from being productive.
- End users don’t understand the importance.
- End users assume they need to understand code.
So how do you get those users to work on the side of your engineers and start submitting bug reports? Let’s take a look at a few possibilities.
Create a bug bounty
As a business owner, you get the idea behind incentives, and the bug bounty is one of the best incentives you have to get users to start reporting bugs. Bug bounties are simple: You establish a reward for users who submit bugs. The more bugs users submit, the bigger the bounty.
In other words, you reward your entire staff for helping your developers improve the software they use. These rewards can be monetary, time off, small gifts, or a special parking spot. For example, Google has its Vulnerability Reward Program, which uses a sliding scale for bug reporting. Users can “win” anywhere from $100 to $20,000 dollars. The average payout for Google’s program is $1,000.00. Of course, your bug bounty program would probably be smaller than that, but you get the idea.
As you know, nothing motivates people like financial gain, so bug bounty programs are always a big hit. In fact, once you implement such a program, you’ll be shocked at how many bugs are “all of a sudden” found and reported.
Create a leaderboard
If you can’t afford a bug bounty program, you can certainly create a leaderboard to inject a bit of competition into the mix. This leaderboard should be visible for all to see. Hang it up in the breakroom, or just about any room you’ve got. Just make it obvious.
People like a good competition. And you can always make it a bit more enticing by adding a single reward for the year-end leader. So whoever has reported the most bugs by the end of the year will receive the coveted title and a prize.
Although you might be hesitant to monetize this, remember how important the squashing of bugs is for your company.
Make it easy
The biggest reason people don’t report bugs is that it’s complicated. Many developers require very specific documentation for their bug reports. The thing to remember, however, is that the largest number of users aren’t developers, so they don’t necessarily have the understanding of how the software works to fill out a proper bug report.
That’s why you want to make this as easy as possible. Have your users answer questions like:
- What’s the name of the application you were using?
- What were you trying to do with the application?
- What happened when you encountered the problem?
- Did you get an error? If so, what did the error say?
Even better, create an internal form that allows users to select from drop-downs or checkboxes. The less a user has to input, the more likely they’ll report the bug.
One thing to consider is that you’ll need to add clear instructions, to help users understand what is expected of bug reports and to guide them through the process. This might sound a bit harsh, but don’t let your programmers write those instructions. Why? Many software engineers are not able to communicate their ideas in terms an end-user can understand. Use a mid-tier manager, a seasoned developer, or someone adept at translating otherwise complicated concepts into human-readable information.
It’s also important to make sure your bug reporting system strikes a balance between easy for end-users and informative for the developers. If your end-users aren’t submitting information that actually helps the engineers improve your Ruby, Node.js, or cloud project, they may as well not be submitting bug reports at all.
Improve the lines of communication
The conversation goes both ways. You need end-users willing to take on the task of filing useful bug reports, but you also need developers willing to communicate to end-users in helpful ways.
When an end-user files a less-than-helpful bug report (“When I click a button, it crashes!”), if your developers lash out at the end-user (“What can I do with that lame bug report?”), it will only help discourage that user from ever filing another report. Your developers need to be understanding that end users don’t speak their language or understand how the software works under the surface. To that end, make sure your developers handle their end of the communication pathway with a nod to sympathy and patience.
When a user submits a less-than-ideal bug report, a developer should follow up with the user and ask questions in a way that isn’t off-putting or demeaning. Improve that particular line of communication and the bug reports will flow with much more regularity.
Conclusion
You owe it to your company, your developers, and your staff to improve the bug reporting process for the software you use. Even if that software isn’t developed in-house, those bugs can help the third-party developers not only improve the application in question for you, but for everyone.
Bug reporting is a win-win proposition. Take the time to develop a seamless and simple process and your business will run more smoothly and efficiently.
