One of the most important roles of a QA tester is to find problems in software and report them to be fixed. 

For that reason, reporting a bug correctly is essential to its removal and improving the overall user experience.

So, Here’s How to Add a Bug

Before anything else, make sure the bug is valid

To do that, check if it’s really there and it’s not a simple mistake you made. Also, check the spec; maybe the feature does what is expected. 

To be on the safe side, check if the bug has already been reported by someone else to avoid duplicates.

A bug report has to be precise, clear, and easy for anyone to understand. Below, we’ll list a few things any good report should contain.

Ticket Contents

Title contents

The title must contain 3 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 describe what’s happening as shortly and clearly as possible. 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

You must include the exact steps needed 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 write what happens at the steps mentioned above. 

Describe if the client’s functionality is affected in any way and, if needed, attach a video of it. 

Take some of the previous steps, explain each of them and the results that occur. For example, this happens in step 2; this happens in step 3, etc.

Expected Results

Focus on what should happen if the app worked correctly, as expected. 

Again, you can take each step and explain: this should happen in step 2; this should happen in step 3, etc.

*Remember, this section should include the link or the quote to the specification, indicating why this is the expected result.

*Note: 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, 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 WiKi page link (if it’s the case) related to this bug and put the acceptance criteria or the requirements that characterize it.

Or

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

Fields the JIRA Ticket Should Contain Before Creating It

Whenever you add a bug on JIRA, you must fill in some fields before creating the ticket and posting 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; (more about this here: 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 easily be 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 this bug relates to (if it exists) only if it’s not yet closed. If it’s related to an epic, add the epic too!

k. Link to the tickets this bug is dependent or related to; Found in build. This last section should include the client and server versions.

Conclusions

As you can see, finding a bug isn’t enough.

You have to report it following strict steps about what, where, and when it is happening. 

It all depends on your ability to pinpoint the problem, use words to your advantage, and keep everything as simple as possible.

You can reach us through the contact form, by email, on Facebook, or here:

https://calendly.com/betterqa