A bug identifies and describes a problem detected in the system. Even if the right bug reporting tools are used, testers can fall into some bad practices that put the entire task at risk. Here are the 3 most common bad habits testers have when reporting bugs and their solutions.

Author: Juan Pablo Sanchez Rizza

When testers are running a test suite (the collection of test cases to verify a feature or functionality in the system), they might observe that actual results vary from expected results according to requirements specifications. This is a bug, and when found, it needs to be reported in the project’s defect tracking tool in order to communicate this finding to the rest of the team.

Defect tracking tools do not guarantee good bug reports, and unfortunately, some testers have a few bad habits while writing bug reports. Good practices are the ones that save the day so let’s deal with the bugs and come up with solutions in order to break them!

1. Laziness

Some testers report the bug without much information, for example:

• They fill in the bug report without a proper title or with a vague description about the problem, meaning there are no steps, test data, or expected results that help developers understand the issue and try to reproduce it.
• They do not check for duplicates (the list of existing bugs previously reported), so team members find an issue that has been reported more than once.
• They tend to report the problem immediately without double checking its validity or without doing a thorough assessment about the scope of the feature under test. This usually happens when testers are presented with incomplete test environments or when our test cases get outdated due to requirement changes.

The problem is that these bugs are sent back to the testers asking for more information about the incident or sometimes they get rejected making the whole team spend precious time reviewing them.

Solutions: For each of the examples given above, we propose the following solutions.

• Testers need to be responsible for their deliverables, so take your time to fill in the bug report with as much information as possible, including a brief and objective description, preconditions (if any), reproducible steps, actual and expected results, and test data used. Screenshots or videos are a plus.
• To avoid duplicate bugs, testers need to organize their work and keep track of the list of issues reported. When working with more than one tester in the team, it is a good idea to divide the test features among testers to avoid having people working on the same task.
• When a feature is ready to be tested, learn about the scope of testing by asking the team so you can understand what can and cannot be tested. Also, when there are requirement changes, make sure you keep your test cases up-to-date.

2. Rushing

Sometimes, when the testers are rushing to report a bug, they forget to give a correct assessment about the impact of the problem in the system, or even worse, they get confused and think the priority is the same as the severity.

The priority indicates the importance or urgency of fixing a bug, while severity indicates the degree of negative impact on the quality of the software.

The development team needs to understand the priority and severity of the bug clearly. We are not just saying, “This is not working”; we are also saying, ”Here is what will happen if this continues to not work”.

Solutions: When setting the bug priority, keep in mind the rest of the open bugs and ask yourself which ones need to be fixed immediately, in the upcoming builds, or in the next release. Do not be afraid to realize that there may be bugs that cannot be fixed at all. In Hexacta, this task is mainly assessed by team leaders when analyzing the list of bugs raised by the testing team.

When setting the severity of bugs, consider the operation of the system and its data, whether it affects critical, major, or minor functionality and whether there is a workaround to the issue and how difficult it is for the user to bypass it.

3. Poor communication

Many people find testing as an activity that criticizes others’ work. We usually believe that we have done our best to produce work (documents, code, or tests) which is correct and complete. Therefore, when someone else identifies a defect, we might take this personally, especially if we are under time constraint.

We have also found that some testers share their findings via email to leaders and/or developers, and this can be a good approach when high priority bugs are found and need to be immediately fixed, but sometimes, these emails get mixed in with all sorts of unrelated content, and the bug never gets fixed at all.

Solutions:
Testers are not only focusing on an objective bug report but also communicating the issue in a polite manner. Communicate your bugs in a neutral, fact-focused way without criticizing the person who created it. Give praise as well as criticism.

It is also important that all bug reports are raised in the corresponding tracking tool and not shared via email where people might lose track of it.

In the End

It is our job as testers to provide everyone with clear, objective, and complete information about a problem in the system. Testers learn from their mistakes, so try to build up experience where errors are likely to be made and be curious with a critical eye and attention to detail. Moreover, learn to have good interpersonal and communication skills so that other team members are involved in improving the overall quality of the system under test. This way, the team will fulfill their goals, and this will lead to the project’s success.

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.