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!
Extra Tips
- 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!
Top comments (4)
It's good to see someone else advocating a two-metric system for basic bug classification. Quantified Task Management uses 6-point Priority and Gravity; the latter name makes it applicable to non-bug issues. As to the six-point scale, p0 is "Wishlist", while p5 is "something is on fire". I usually advocate p4 for the usual "top", leaving one spot above that for actual emergencies.
Of course, one should always know what classification system is being used by the project you're filing a bug report on.
I am happy you noticed this point! I really liked the metric system of QTM and it's actually pretty similar to the basic one mentioned in the post. Thanks for the link, very interesting material!
A couple additions to the list that don't always apply but when they do, are critical for a good bug report.
Required artifacts
Sometimes an issue can be reproduced in a build from scratch with just some user interactions. In this case the written steps, screenshots and/or videos (how I ❤️that videos have now become a normal part of bug reports). But there are plenty of times when that is not enough to reproduce. Maybe the issue only occurs on a specific data-set, or after uploading a specific file, or after specific configuration changes. Depending upon the nature/size of the artifact it can be either be attached or put on Dropbox/Sharepoint/network-share with a link. I've had to deal with way too many bugs that were like "this report shows an error when it used to show data" and I have to ask for them to give me the report before I can do anything...
Logs, logs and more logs
There are plenty of issues where logs are not relevant. But when they matter they REALLY matter. If an error occurred there's probably a stack-trace logged somewhere - it should be provided. And if it's a client-side error do some digging server-side to see if there was any errors there that could be a root cause. And if you are thinking "well when the dev reproduces the issue they'll see the errors so why should I go digging" there are plenty of issues that are hard to reproduce and those errors on your instance may be the only copy in existence. Treat it as such.
Full logs, not just errors, are particularly useful for those extra thorny performance issues. If a 1000 user stress-test is taking twice as long as the baseline I'm going to want as many logs and performance counters that are available, as there's no way a human can debug that test case.
Depending upon your setup these logs may need to be found and provided like the required artifacts or they could be automatically pushed to a central logger (graylog, elastic, etc). Even if that is the case you should still provide the query information to find the relevant logs - instance-id/machine-name, time-range, user, etc.
Thanks for the detailed and helpful comment! I really agree with your two points and think that everyone involved in testing should keep a look on them too.