Skip to main content

How to Write an Effective Bug Report?

  • 21 June 2023
  • 2 replies
  • 157 views

Hey ShiftSync Community!

I hope you're all having a great day. I recently came across a fantastic video on YouTube that discusses software testing and the importance of bug reports. Here's the link to the video: https://www.youtube.com/watch?v=cgkhx7NqXCE&ab_channel=ResterTest.

After watching it, I realized that writing an effective bug report is crucial for improving software quality and ensuring smooth user experiences. I believe it's a valuable skill for all of us in the tech community, and I'd love to hear your thoughts and advice on the matter.

If you have experience with writing bug reports or if you've encountered bugs and reported them before, I would greatly appreciate any tips you could share. Here are a few questions to get the conversation started:

  1. What are the essential components of a good bug report?
  2. How do you effectively reproduce and describe a bug in your report?
  3. What additional information should be included, such as system details or error messages?
  4. Are there any best practices or common pitfalls to avoid when writing bug reports?
  5. How do you strike a balance between providing enough information and keeping the report concise?

Feel free to share your personal experiences, tips, and any resources you've found helpful in mastering the art of writing bug reports. Let's use this opportunity to learn from each other and enhance our collective knowledge.

I'm excited to hear your insights and engage in a fruitful discussion. Thank you in advance for your input!

Looking forward to your responses.

2 replies

A
Userlevel 5
Badge +3

Really good question!

What are the essential components of a good bug report?

  • A short summary line of the bug for business, management and similar
  • Steps which are guaranteed to reproduce the bug for developers
  • A description of what the bug is and the behaviour it causes + if necessary, why you believe it a problem & any error messages, codes or similar generated
  • Categorisation, priority and severity to aid decisions by the project team on risk, if and when it ought to be fixed (in relation to other bug fixes, maintenance, technical debt and new feature promises)

 

What additional information should be included, such as system details or error messages?

  • Any system, user, timing etc. details relevant for reproducing the issue. I.e. does it only appear when an Admin account is logged in, on TEST but not DEV or PROD and only between the hours of 00:00-02:00.
  • Error messages stated above. I’m personally not a fan of screenshots on the whole as they take up backend space, require an extra step or few clicks to open & largely just show the same useful error message anyhow. 
  • The date and time the bug was encountered as well as the computer name and user name if a logging system is in use which the developers can use to lookup event logs, stack traces etc.

 

How do you strike a balance between providing enough information and keeping the report concise?

Often the test management tools will do this for you, by means of different dropdown fields etc. so everything isn’t in 1 single textbox and providing traceability linking of a defect back to a test case where the steps to follow (to reproduce the bug) can be found - all reducing the amount of detail needed to be entered into a description field.

 

By including as much detail as possible, you’re reducing the scope of misunderstanding or backwards + forwards communication between you & the developers who need to troubleshoot & potentially fix the bug. I’d err on the side of caution & recommend too much rather than too little detail myself. 

 

However you could add a summary line for non-developers, a one-liner description at the top for those who don’t need all the details. These links might give some inspiration for formulating those:

https://hbr.org/2016/11/how-to-write-email-with-military-precision

https://www.linkedin.com/pulse/what-military-can-teach-us-writing-effective-emails-damon-penny/

mmario.ffrohlich
Userlevel 5
Badge +3

This is an example on how i structure bug reports. Please keep in mind that the actual report that should/is used also depends on the processes and regulations set by the company you work for.

 

Tester: details of the user performing

Date: date when the testing was performed

Browser: browser that was used during testing

Severity: low, mid, high, critical, blocker…

 

Title: [ X > Y > Z] short and concise description of the issue

(the X>Y>Z part denotes the path to the part of the application where the issue was found)

 

Description: this part is used to explain when and where the issue was found. It can also be used to outline any details that are relevant to the issue

 

Steps to reproduce:

1. Step X

2. Step Y

            1. Step Z

 

Expected results:

At step X:

  • Something-something that is expected to happen at any given step

Actual results:

At step X:

  • Something-something that is happening that is different form the expected results

Acceptance criteria:

  • some criteria that has to be met in order for the ticket to be considered successfully finished

Attachments:

  • include images with clearly marked issue observed
  • include network details from the google console (or any other browser that you use)
  • video showing steps to reproduce the issue and the issue observed (personally, I try to include these as much as I can)
It's a me, Mario! Sticks and stones may break my bones, but testing stuff excites me

Reply


ShiftSync Terms and Conditions