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.

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

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

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

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

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

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

12. 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 resources). Other bugs will be prioritizing in a bug status meeting.

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

14. Software Platform/Environment/Product Version

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

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

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