Why an effective bug report is necessary?
It's crucially important to write an accurate error report, as in this way you will increase the chances of fixing the bugs you found. Writing an effective bug report is not that difficult, you just need a good pattern and some practice. Remember that a good bug report is the primary responsibility of a successful software tester.
Two main advantages of an effective and accurate report:
- The assigned developer has all the necessary info to start working on it
- Any other tester of the team can then retest it, even if the reporter is not at work
Let's start to see how you can write the best report!
4 general rules for writing an accurate defect (bug) report
- Clarity and accuracy: Good writing and communication skills are essential here, as you have to avoid confusions and misunderstandings. Don't miss key points and important information, as this will lead to the slowing down of the development process. It's also quite possible that your report will be neglected and the bug will remain unfixed.
- Research before raising a report: When you find a bug, before raising a report, do a quick research for duplicate issues. In many cases, there are long lists with unresolved bug reports, so it's quite possible that a bug is already reported. Make sure that the one you found is not a duplicate of an older issue.
- Simplicity: Write your report in a simple and easy-to-understand way. Use short, but meaningful sentences, avoiding too complex explanations and difficult words that can only confuse or mislead the readers.
- Create different reports for different bugs: Report every bug as a separate issue. In this way, you can more effectively organize and tracking your issues, closing each issue when the respective bug is fixed. Additionally, reviewing and fixing the issue will be done faster.
How to write a basic bug report (template)
Let's see now in practice! Check this simple report template and adjust according to your needs. In most of the cases, you will be using a bug tracking tool that makes easier the process of writing a defect report, as it will automatically fill some of the information, as the reporter or the issue number. If you don't use such tool, you will probably need to manually write this info.
Description aka Summary: Keep short but informative
Steps To Reproduce: How did you produce this bug? Write down all the steps you followed
Expected result: What is the expected behavior in your case? The expected results are usually predefined in the related requirements.
Actual result: What was actually the behavior in your case? Write the actual behavior of the bug.
Additional, but VERY important information you have to provide:
- Credentials of the user(s) with whom you produced a bug
- Problem area / URL
- Version of the product (if applicable)
- The browser you used, especially in cases of design issues
- Priority - it depends on the severity of the bug. Most serious bugs should be fixed first.
- Severity - show the impact of the bug. There are 5 severity types:
- Blocker: No more testing can be done
- Critical: Application crashes, there is a loss of data
- Major: Major loss of function
- Minor: Minor loss of function
- Trivial: Small UI errors
- Screenshots or / and Screencasts (screen recording). A picture is equal to a thousand words. Take a proper screenshot or screencast and capture this annoying bug in action!
- Report the bug as soon as you find it. If delay, it's possible you forget some important info.
- Try to reproduce the problem again. Make sure your bug is reproducible.
- Double-check before submitting the report. Read again to find and correct any problems. After all, you are a tester, you should test even your own artifacts!
- Take care of the language you use. Don't harass or criticize the developer who made the mistake.
Are you ready to write your best bug reports and increase your productivity? Give it a try!
As software gets more and more integrated into our lives, the industrialization of its crafting process becomes inevitable. But the over-generalization of software engineering can be crushing the creative side of programming.