Every single line of code, every application, game or service designed to be used by the audience should be tested. Every software developer has faced the challenge of fixing an existing feature. And many times they have got a bug report saying: “XYZ doesn’t work”. No specific information included no detailed description or relevant data.
Today, I would like to convince you that the so-called soft skills – the way you communicate and give information to others – are very important for every tester. In the 7th and 8th point of the tester’s decalogue, I am going to deal with communication and advise you on how to deliver good bug reports.
#7 Communication
„I’m a good tester because I can find plenty of bugs”. That’s not how this sentence should be formulated. Instead, you should say: “I’m a good tester because I can report the bugs that I have found clearly and effectively”. Clear and precise communication and reporting bugs in the correct way is every tester’s daily task. I also get in touch with fellow developers every day to support them in delivering top quality software. Thanks to the fact that I know how to report bugs, developers save plenty of time and effort when fixing them.
A tester’s role is not only to be responsible for quality control and making sure the requirements have been met. You have to deal with people of various characters and personalities, as well. Sooner or later, you will have to inform your team that a feature needs to be fixed. People’s reactions to this will be different. To err is human, they say, but some people may feel offended to hear a bug has been found in the software they have developed. Others will refuse to listen to what a tester tells them to do or they can react in an unpredictable way. Still others will take your report as another task they need to tackle. As a tester, you will be confronted with the fact that you are the one to break bad news. No matter what the reason for a bug is, your duty is to report it.
To avoid unexpected circumstances, make sure you refer to facts. Use a neutral tone of voice and don’t blame or criticise anyone. If a bug you have found occurs repeatedly over a period of time, don’t start moaning about it. Instead, have a chat with developers – perhaps together you will get an idea how to fix it. Pay special attention to the way you speak and behave – try to take control of the situation and calm everyone down instead of heating them up. Remember that proper communication is key to success.
#8 Proper bug reporting
Part of effective communication is correct bug reporting. What’s the difference if you have found a bug when no one but you knows where it is and how to reproduce it? When a developer has to deal with a bug, your description should be enough for them to be able to learn what is wrong. If they have to ask you for more information or to reproduce the bug yourself or they claim the bug cannot be reproduced, this means it has been incorrectly reported.
As a result, much more time has to be spent to trace the bug than to actually fix it. Remember, your bug report is a documentation that is supposed to show the difference between what’s required and what has actually been developed. It is to be as helpful for developers as possible. What should a well-prepared bug report look like?
Give it a good title
The title is what developers see in the first place. So make sure your title:
- is clear and understandable,
- includes keywords that will help categorise the issue and assign it to a team member (e.g. mobile, backend or frontend developer).
- is not too general. Instead of saying you had „a problem with purchase”, report that you had „a problem with selecting the method of payment when trying to make a purchase as a registered user”.
Describe the problem
The description is the most important and the most difficult part of your report. The more precisely you describe the issue, the bigger the chance it will be dealt with successfully and quickly.
A good bug description should include the following information:
- The version of the application and the testing environment where the issue occurs,
- The time and date when the bug was found,
- The initial conditions (cache, firewalls installed and applications that could affect the tested feature),
- The expected and the current test result,
- The test data that have been used in the test,
- How to reproduce the bug, with each step described in detail,
- Suggestions and tips on the reasons why the bug has occurred, features it influences or can influence and how serious it is.
Provide visual resources
There is a Chinese proverb saying that an image is worth a thousand words. It’s the same with bug reports. The more visual resources that can help the developer deal with the issue you provide, the better. Make sure they are relevant and clear enough to convey the message.
You can attach:
- Images and screenshots – use any graphic design software to get them. Mark the bug location with an arrow. If you can, show what it should look like in comparison to what it actually looks like at the moment.
- Video – there are a number of tools you can use to record a short video with or without sound. It’s helpful especially when there are a number of steps to reproduce the bug. Your film should show the whole process, not only the final result. Make sure it is consistent with your bug description.
- Log files – remember to provide log files in the format your developers prefer.
Define the severity of the bug and prioritise it
When reporting a bug you should be able to assess if its occurrence is critical for the system and how quickly it should be fixed. By defining its severity you predict the impact the bug can have on the system and the consequences it may lead to.
The severity of a bug may be:
- Critical – system failure, blocker, risk of data loss
- Major – requirements haven’t been met or features have been incorrectly implemented
- Moderate – minor issues that don’t affect the security or performance of the system
- Minor – issues that don’t affect the performance of the system; cosmetic errors
The priority status lets the team know when the bug should be fixed:
- High – to be fixed urgently
- Medium – to be fixed in the next release
- Low – to be fixed when other issues are dealt with
Conclusion
A well-prepared bug report is every tester’s key task. When you find a bug, note it down and verify it. Don’t hesitate to spend a while diagnosing it. Consider reasons for its occurrence and test other functionalities that can be influenced by the deficient one. Note down your assumptions and conclusions to let developers save their time and effort. Read your report and check it thoroughly. And what’s the most important – remember about people and make sure you take a proper approach when reporting bugs. Don’t exaggerate and don’t blame anyone. The problem is always in the functionality, not the person who developed it.
***
I hope the tips mentioned above will come in handy in your work, enable effective communication with your team and make your work more satisfying and productive.
The next, final part of the Decalogue is coming soon. If you would like to brush up the knowledge from the previous parts, read part 1 and part 2. If you would like to share your opinion on this part or tell us about your experience, leave a comment.