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 (also check the spec, maybe the feature does what’s expected)

. 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.

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 characterize the bug.

Or, just connect the bug with the ticket, comment or chat channel discussion based on why you added the bug in the first place.

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; (this is detailed in the following blog article https://betterqa.co/blog/bug-priority-vs-severity-levels-how-to-correctly-identify-a-bug-severity/)

e. Frequency of occurrence;

f. Attachments of logs or network request payload (sent and received) 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;

j. Link to the Story that this bug relates to if such a story exists and only if it is not yet closed; If it’s related to an epic, add the epic too!

k. 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.

Conclusion

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.