How to Write a Quality Bug Report

Posted: September 20, 2018 by Natalya Rahmany

How to Write a Quality Bug Report

See if the bug report meets a software testing methodological standard!

The purpose of the reporting standard to determine a high-level and quality bug report.

The quality standard of a bug report stands by accepted testing methodology and was written due to my extensive experience in the testing.

The Bug Report includes the following Characteristics :

1. All bugs/issues will be documented in English. Most of the organizations still insist on using a local language. Some of the projects are managed with foreign clients and the fact that development in technical English only brings us to the management of bugs in English.

2. The bugs should be reproducible. The tester should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step.

A bug that is described step by step is easy to reproduce and fix and the important thing intercepts the ping pong between the development to the testing team.

Try to reproduce the bug at least 3 times before you record it in a bug tracking tool.

3. Be focus on your bug report. Try to summarize the problem in minimum words in an effective way. Do not combine multiple problems even if they seem to be similar. Write different bug reports for each problem.

4. The issue title should be understandable for everyone. The title should briefly summarize the bug and mostly shouldn’t be more than 40-50 words. Make sure your title is reflecting what the problem is and where it is.

5. Assignee a bug to a relevant R&D team leader or developer.

6. Write a detailed description with the issue steps reproducing: 

Use the following fields for the bug description:

  • Bug Reproduce steps: Clearly, mention the steps to reproduce the bug.
  • Expected result for the bug: How the application should behave on the above-mentioned steps.
  • Actual result: What is the actual result of running the above steps i.e. the bug behavior.

Join the Productive Hut newsletter

Subscribe to get our latest posts and tips!

I will never give away, trade or sell your email address. You can unsubscribe at any time!

7. Add attachments for the issue. A screenshot is worth a thousand words.

Take a screenshot of the instance of failure/error with proper captioning to highlight the defect. Highlight unexpected error messages with red color. This draws attention to the required area.

Take a screenshot of the GUI problem or even the design paragraph. The bug should include all information to develop. Recording effective bug will all information should save “ping-pong “between the QA group to Development.

8. Take a log of the failure/error. In case of a long log attach the failure time. It will promise an easy log troubleshooting by development.

9. If issue founded follows the product design, take a paragraph/sub-paragraph number and attach to the bug description. It will help the developer to understand that it a functional bug and should work by product design.

10. Set severity to the bug. A new tester – the severity will be determined by the QA Team Leader. An experienced tester will determine the bug severity according to the system’s knowledge and experience.

11. Set priority for the bug. For the critical/blocker issues the priority will be set by a tester and will be fixed as soon as possible (due to project schedules and resource). Other bugs will be prioritizing in a bug status meeting.

12. Bug occurrence. Test the same bug occurrence on other similar modules.

Sometimes the developer uses the same code for different similar modules. So there are higher chances for the bug in one module to occur in other similar modules as well. You can even try to find the more severe version of the bug you found. Set occurrence for the bug.

13. Software Platform/Environment/Product Version

Mention version of all relevant components for the bug. It could be a server, client, configuration, services and etc.’

The OS and browser configuration are necessary for a clear bug report. It is the best way to communicate how the bug can be reproduced.

Without the exact platform or environment, the application may behave differently and the bug at the tester’s end may not replicate on the developer’s end. So it is best to mention clearly the environment in which the bug was detected.

14. Avoid duplicate issues. It creates extra noise in the bug tracking system. Search manually bug keywords before you are open a bug. Probably the bug already founded by another tester from your team.

15. Please read the bug before you submit your bug details. Make sure again that the bug is clear and contains all the information.

Is this post helpful for you? Share your thoughts in comments on how it helped you. 

Join to Productive Hut Family and be part of a testing community!

Join the Productive Hut newsletter

Subscribe to get our latest posts and tips!

I will never give away, trade or sell your email address. You can unsubscribe at any time!

3 Comments

  • YourFriendPablo February 12, 2019 at 8:15 am

    Great, I really like it! Youre awesome

    Reply
  • Reginia Cernota February 29, 2020 at 11:21 am

    Appreciation to my father who told me regarding this website, this weblog is in fact amazing.|

    Reply
  • firtuklo imutrzas April 5, 2020 at 7:25 pm

    I really appreciate this post. I?¦ve been looking all over for this! Thank goodness I found it on Bing. You have made my day! Thank you again

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.

%d bloggers like this: