As I was talking to a friend about my beginnings as a tester I remembered my struggles on how to report bugs during my internship, as we were given challenges rather than simple solutions…
Bugs of course come in all shapes and sizes, but the right bug report is essential to enable the decision making people to make the right decision whether the bugs should be fixed or not and when (and to make further work with the bug as easy for the developers as possible).
Using the right temple is important but it is as important to understand why each element is there. I will write about the template I use (and consider it a good practice), but if you use something else or have any thoughts – let me know in the comments section.
First thing to ask should always be – is what you have found a bug or a feature (sometimes it is easy to determine, sometimes it can be hard). If you are not sure, it is good to search in the documentation and/or ask other team members. When you know it is a bug – proceed.
Bug report should have a name that will meaningful while also being short.
ID can be either given manually or generated by the bug tracking software. It will enable easy identification and search for the issue.
Where am I ? – Environment
Give as detailed information as possible as the environment is very important the same thing that works in one may not work in another and vice versa. Of course if you test on only one environment you would not need that, but that was never the case for me.
Is it desktop/ mobile (phone or tablet)/ wearable/ embedded kind?
What is the system version?
What is the browser version if applicable?
Is there a specific viewport ?
What do I need to occur? – Precondition
Maybe You need to be logged in to the system to be able to reproduce?
Maybe You need to have weak internet signal?
Maybe the battery must be almost depleted?
Maybe you need to set up a testing tool beforehand ?
If there is any thing that needs to be done before reproducing the steps it is better to write it down as precondition, than to make the list of steps much longer. This ensures clarity of the report.
What needs to be done to see me? – Steps to reproduce
What did you expect ? – Expected result
This will tell the reader what should have happened after performing all the steps in the preset environment. It may also contain a business rule/expectation mention and the output if applicable. It has to be clear what the outcome should be. If there is more than one thing (usually that is the case) it might be a good idea to make a simple bullet list.
What happened? – Actual result
This is what went wrong – the core of the report. State clearly what was not as expected, what happened and how You saw it – e.g. error in console, something did not render etc. Sometimes bullet list is a good idea here too. I sometimes make a table were I list all the things that should happen and mark in with X and V – it is clear, precise and gives visually nice information about what happened and what did not.
Any comments? – Comment
There might be something else that you want to tell the reader that did not fit in the other places – do it in the comment!
Maybe you suspect what the bug is related to?
Maybe it is connected to other bug?
Maybe you have encountered something similar before and want to offer some advice or insight?
Something else to add? – Attachment
We all know the saying that the picture is worth a thousand words, but so is the short movie, screenshot, console log or any other thing that can help to decide about the bugs’ future. So if it is possible – add an attachment that shows what happened and what you are reporting. Depending on the bug reporting system you may either store it as a normal attachment to the report or give a link to the picture/log/movie that is hosted in some shared space.
There is one more thing I always add to my bug reports: information about Priority.
I did not put it on the list because in some teams Priority is given to the bug by Product Owner or Project Manager or Test Manager or Test Analyst, not the tester who found it.
Assigning the right priority to the bug requires experience and project knowledge, because you have to take into consideration, among others :
- bug itself,
- how it affects the part of the system where it was found,
- how it affects User Experience (usability),
- how is it connected to project and product risks.
Priority given to a bug would also inform the decision makers (ex. team during planning) where in their task priority list should it land.
The priorities I mostly use are (from bottom to top) are: Trivial, Minor, Major, Critical, Blocker. Some people also just use 1-5 scale, although some see 1 as the highest priority and some see 5 as such, so always remember to check the used leveling.
Remember what is the most important thing in the bug report: its’ purpose. We want to do it well, because what we need is to communicate efficiently, create common ground for the team collaboration and provide information for the decision makers.
Any thoughts? 🙂