logo logo

14 Tricks To Write A Good Bug Report

Bug Reports

A bug report is often the reason testers and developers might encounter a fight 🤯 Yep, fight – you read it right! Well, there are of course other reasons too, but a bug report is definitely one of them, and its a tale as old as time 😅

Every tester has to write bug reports and if your bug report is clear, crisp and accurate, chances are that the bug will not get rejected. However, often come a time when testers log a bug that developers reject and it becomes a never-ending cycle of defect tracking and bug rejections. I recommend exploring this great article to learn more about the reasons developers might reject your bug report: Defect Tracking: 5 Common Reasons for Bug Rejection.

Anyone can write a bug report, but in order to write a good bug report, one needs to gain good analytic skills and patienceFirst and foremost, make sure other testing team members are not reporting the same bug you are, otherwise, you’ll both be creating duplicate issues and an unnecessary cycle of defects. So, once we do end up opening a bug – how can we make sure to write an effective bug report in just a few simple steps? Let’s get started 👉

1. Issue ID: We need to make sure the issue ID is maintained. If you are using a bug tracking tool, then it will create auto-generated IDs and no duplicate IDs will get generated.

2. Issue Summary: This is the most important section of bug reporting. The issue summary defines the problem statement of your bug. Try to write a crisp summary, stating what your bug is about. For example: The login button is not working on the Home page. From this summary, the development team will easily understand where the issue is deriving from and what needs to be fixed.

3. Issue Description: In the description area, you need to mention steps to help the developers reproduce/regenerate the issue. For example: The home page of the Application is throwing a 500 internal server error. Steps to reproduce:

  1. Enter the URL of the application.
  2. Add Customers Login Id and Password
  3. Observe the home Page

From the above description, the development team/Product Owner/Scrum Master will understand that once using the customer’s login credentials, the home page is throwing a 500 internal server error. Try to add a bit more detail in the description, such as: customer’s login ID/password because there may be other role permissions, and for some it might be working. That being said, make sure not to make it too long 📚

 4. Expected/Actual result: Expected and Actual results are probably one of the most important aspects that need to be mentioned in your report. Everyone should know what you expect the result to be as opposed to what is the actual result you receive. For example:

  • Actual Result: Home page is throwing a 500 internal server error
  • Expected Result: Customers should land on the home page of the Application.

5. Severity/Priority: Severity and Priority must be present in your bug report as it shows how complex the bug is and how urgently it needs to be resolved. For example: We can define the Priority from P1-Blocker, P2-Critical to P5-trivial, etc. Whereas we can define Severity as follows:

  • Blocker – Testing can’t be done, you are blocked from using the application.
  • Critical – Application crash, Hardware issue, etc.
  • Major – Major functionality break.
  • Minor – Minor functionality break.
  • Trivial – Some UI enhancements.

Depending upon the complexity of the bugs, you can add the above factors to your bug report.

6. Platform/Environment: The Platform/Environment mentioned in your report suggests in which environment your bug is reproducible. There is a high possibility that your bug is reproducible on the QA environment but not on any other higher environment such as AUT or PROD.

7. Assignee/Reporter: In case you are using a bug reporting tool, it will automatically take your name as the reporter. However, if you are entering the data manually, for example in an excel sheet, then you need to mention the reporter and correspondingly it needs to be assigned to Dev/PO as per your team structure.

8. Screenshots/Video recording: This is the tester’s all-time greatest weapon 💪 You MUST add screenshots/videos for the scenarios which you are reporting on. It is good practice to attach screenshots/videos in your bug report, since it acts as proof if the bug is not reproducible at a present situation but was reproducible some time ago once you tester the feature. You can also attach logs of your environment if it’s easily capturable and available to you. For example: API logs, UI logs, etc.

9. Status: Status is something from which we can get an idea of what is the current state of the bug, for example: ‘New’. Later on, such issues go through various states like Fixed, Verified, Reopen, Won’t Fix, etc. 

10. Component: It’s not a mandatory section, but if you mention the various components, it will be easier for your team to filter out which component exactly is creating the issue. If your application is not that big, you can also add to the report whether it’s related to UI, API, database, etc.

11. Version/Release: Please do not forget to mention in which version/release the bug has been detected in. It acts as a guide for testers and developers and the entire team.

12. Fixed Version/Release: It’s always good practice to mention which version it’s fixed on so we will be able to see changes. It’s usually mentioned by the developer/PO.

Two additional pro tips to make your bug report the best

13. Read through all your bug reports once before hitting the submit button, making sure steps 1-12 above are included ✅

14. Make sure your bug report should not look rude or abusive. Keep it positive tone and polite manner. 


Your bug report should be a high-quality document, easy to read through, clear & concise, and shouldn’t raise any additional open questions for anyone reading through them. A good bug report will always make you feel confident once submitting to the developers, and will also create a good relationship with the entire development team ✨

Which steps do you go through while filling out bug reports? Please share them in the comments for everyone to learn and take inspiration. Happy Testing 😉

About the author

Aditi Mokasdar

I am a Software Tester having almost 4.5 + years of experience in Functional Testing and Test Automation. I like to learn and explore new things :)

Leave a Reply