One of the most important roles of a QA tester, among other things, is to find problems within the software that’s being tested and report them to be fixed. This means that reporting a bug correctly is essential to its removal and improving the overall experience of the user.
So, how should a bug be added?
Before anything else, make sure that the bug is valid, meaning that you must check if it is really there and it’s not only a simple mistake you have done. In order to be on the safe side, check if the bug has already been reported by someone else, to avoid any duplicates.
The structure of a bug report has to contain information that is both precise as well as simple to understand and clear for anyone who reads it. Below, we will list a few of the things that any good report should contain.
Ticket contents
-
Title contents
The title will have to contain three main notions (the so-called 3W rule): what happens, where and when it happens. Keep in mind that this will help you or anyone who searches for this bug to find it fast.
-
Description contents
Writing bugs isn’t poetry. With this in mind, try to write everything using the least amount of text in order to clearly describe what’s occurring, no more, no less. Also, add screenshots if the bug can be easily seen in it or, if needed, do a short video of it.
-
Preconditions
– Write here if you need to set up the environment, anything related to the server or the user.
– anything related to the testbed, if you need some user account specific details etc;
– make sure you trim your bug really good using these preconditions so that the steps to reproduce are clear enough -
Steps to reproduce
As the name says, in this section, you must include the exact steps necessary to reproduce the conditions in which the bug appears. That includes:
1. Log in to using user A, B & C on the ;
2. Do this;
3. Do that; -
Actual results
Here you have to write what happens at the above-mentioned steps. Describe if the client’s functionality is affected in any way and, if needed, attach a video of it. You may take some of the previous steps and explain each of them what results occur. E.g. This happens at step 2, this happens at step 3, etc.
-
Expected results
In this section, you must focus on what should happen if the app would have worked correctly, as expected. Again, you can take each step and explain: this should happen at step 2, this should happen at step 3, etc. One thing you must not forget is that this section should include the link or the quote to the specification, indicating why this is the expected result.
-
Note
Here you can include certain ideas that must be taken into account about the bug’s reproduction. “Take into account this and that…” (if needed)
-
Workaround
Sometimes there are ways through which the client can get around the bug and continue to use the client. In this section, you can post such a method, if there is one.
Before adding the bug
Make sure you insert the link of the WiKi page, if one exists, that is related to this bug, as well as to put the acceptance criteria or the requirements that characterise the bug.
Fields that the JIRA ticket should contain before creating it
Whenever you add a bug on JIRA, there are some fields that must be filled in before you create the ticket and post the bug.
a. Appropriate affects version (fix version no longer required);
b. Reporter (selected automatically);
c. Environment, if needed (the platform under use; e.g. iOS 6.1.6 or Android 4.2);
d. Priority/Severity;
e. Frequency of occurrence;
f. Attachments of logs – only if the bug is not a UI one;
g. Attachment of video – only if the bug’s description is difficult to follow;
h. Screenshots – if the bug’s description is difficult to follow, the bug can be easily seen via the screenshot or if you need to compare the actual design with UX specifications;
i. Leave the Sprint field empty;
k. Link to the Story that this bug relates to, if such a story exists and only if it is not yet closed;
l. Link to the tickets that this bug is dependent or related to;
Found in build
This last section should include the client and server version.
As you can see, finding a bug isn’t enough. One must report it following some strict steps in order to clearly state what, where and when it is happening. It all depends on your ability to pin-point the problem concisely, use words to your advantage and keep everything as simple as possible.
