‘Alien bugs’: how self-made regulations help in dealing with unclear bug reports
When talking about bugs and defects detecting, the two most common problems are:
First, when you read the bug description and can’t understand what it means. These unclear defect reports can come from users, customers and beta testers, saying things like, “I pushed the button and everything collapsed.”
Second, how do you handle it when the real challenge is not in fixing the bug, but in “decoding” the report about it?
I have provided some step-by-step instructions below that can help any automated testing company in such situations.
Write your own algorithm
First of all, let’s think about the nature of all those defects with indistinct descriptions. Why does everyone write bug reports in his own way? Well, there are many reasons – the most common being “underqualifying” or “overqualifying.” On the one hand, it could be a tester who is new to the field and didn’t describe the bug correctly. On the other hand, a tester could be so experienced that he treated the bug as an unimportant one. You could also have meticulous developers and project managers reporting bugs.
In all of these cases, bug reports are written inaccurately in one way or another. The best solution, therefore, is to create clear regulations for dealing with bugs – a detailed algorithm on how to describe and fix bugs. Any form for that algorithm could be chosen; most importantly, it should include the three following points:
- A list of attributes that must be filled (in other words, which graph and how should the graph be filled);
- A description of the defect life cycle, accepted by all project members;
- A list of parameters and samples for every stage of the life cycle, if possible.
Do not be afraid to spend a couple of hours on this writing detailed regulations step, since it will save you time in the future. Also, if you have well-structured regulations approved by your team, you can always refer to them when you find yourself in the middle of a controversial situation that requires a fast decision.
However, it is not enough to just write the regulations. The second step is to persuade every team member to follow the regulations you developed. To achieve that, you should develop an agreement with everyone involved to move all bugs that do not match your regulations to the “better definition required” status. Since the automation of that stage is impossible, the project manager is the one who will ultimately be the judge on all controversial defects.
Automate bug registration
Once your team agrees to follow the bug reporting regulations you have defined, it doesn’t mean all bugs will be reported automatically. We can’t forget about the bug reports from customers and users, as well as from beta testers, none of whom are part of the team that has agreed to the regulations. While you are not going to teach them how to report on bugs, you can create an algorithm for reporting. How, you ask? Consider the creation of a reporting form that excludes loose descriptions. Also, every field should have as many preinstalled parameters as possible, describing possible problems.
Another approach is to automate bug reports. Let’s say a user has a button he can push to report the bug he found (configuration parameters, logs, screenshot or even a video showing last activities of the user). A good example of this type of bug reporting function was used by Microsoft – useful when they released the first versions of Office and Windows.
Quite often, users don’t even need to push a button. Android and Apple apps offer to send a bug report to developers once it has collapsed. Even more, platforms like Ubertesters allow users to test apps themselves, which helps developers and testers to automate the bug reporting process.
Nevertheless, you should be really sensitive when thinking of installing the bug-report button, because it has the potential to scare users. Imagine when a user installs an app and sees that button. He may be under the impression he has installed a bugged product. Also, you must keep in mind limitations on a user’s confidential information, such as direct reporting from his own device.
