How To Write Good Bug Reports

How To Write Good Bug Reports

Writing good quality bug reports is very important not just for the tester but also for the whole team. The ideal scenario would be if you write down the problem in a clear concise manner, add relevant steps to reproduce and attach visual evidence, then this would allow the developer to reproduce and fix without going back and forth.

To help with this, we have put together general rules and report sections based on our extensive experience in bug reporting.

The Rules



  • Avoid duplication, search for existing tickets first
  • If you’re unsure about a bug, talk to the developer for clarification
  • Always be consistent in your bug reporting


 Write Well

  • Make sure it can’t be misinterpreted
  • State useful facts, not opinions or complaints
  • Lack of clarity can lead to misunderstandings or other errors
  • Can lead to requests for more information which take time


 One Per Ticket

  • A single bug report can help to avoid confusion and duplication
  • It makes it difficult to confirm and fix multiple issues in a report
  • If you describe too many defects, some may be overlooked
  • Reference related issues to convey relationship amongst issues


 Report Immediately 

  • Do not wait to write detail bug report later as chances are high that you’d miss some important steps
  • This will ensure a good and reproducible bug report
  • Search before you report to avoid duplicates



  • Always run the test and reproduce the bug at least three times
  • Developers have to be able to reproduce the bug to debug
  • If the bug is not reproducible every time, mention the frequency
  • Include the minimum number of steps required to reproduce


 Read Before Submitting

  • Read all sentences and cut out unnecessary words
  • Check for spelling and grammar
  • Make sure the ticket makes sense (no ambiguity)



Typical Report Sections



  • Should be able to sum up the bug just by reading the title
  • Needs to be clear, accurate and should describe the actual issue
  • A good title will enable tickets to be assigned without opening each one

TIP – If you’re testing a website, include the URL of the page (easily searchable)
TIP – If you’re testing an app include the name of the component (easily searchable)


  • Detailed description off the bug
    • What did you do?
    • What was the actual outcome?
    • What did you expect?
  • Include all the steps to reproduce and debug
    • Any prerequisites for the test
    • Should be numbered and have clear instruction
  • Detail the version information about the product that you’re testing
    • Name of product
    • Version
    • Hash of the file

TIP – Regardless if the bug is minor or major, always be consistent in your reporting
TIP – Document so any team member can understand the issue and reproduce
TIP – If the bug is found on a website, always include the URL
TIP – To save time, copy the description structure of a previous ticket


  • What operating system(s) does this bug affect?
  • What browser(s) does this bug affect?
  • What device(s) does this bug affect?
  • Any additional information?

TIP – Write the complete version of a product: Windows XP > Windows XP Pro 2002 SP3
TIP – Provide the system specs, as this can help debug with issues such as timeout due to performance: “16GB RAM, 4GB Free, Intel Core i5-2300 CPU @ 2.80ghZ64-bit”
TIP – Use the DirectX Diagnostic Tool on windows to collect system info: Open a command window type “dxdiag” and select “Save All Information…”


Which sub module(s) of the product does this bug affect?


  • Attach ALL relevant files to explain, reproduce and debug
  • .txt, .bat, .xml, .json, .dmp, .reg, .png, .avi, .js etc.

TIP – Highlight area(s) of interest in screenshots
TIP – Attach screenshots directly to the ticket (don’t zip)
TIP – Create a video if the steps are complex (steps should match video)
TIP – Compress and zip files that are too big to attach (logs, dumps etc.)
TIP – If the file size exceeds the limit to attach, split the zip files when compressing


  • Priority represents the importance of fixing a bug
  • Reflects a business decision (how soon that bug should be fixed):
    • HIGH – Resolved as soon as possible
    • MEDIUM – Resolved after serious bugs have been fixed
    • LOW – Resolved in the future or not at all



  • Tag each ticket with appropriate keywords that can be easily searched later:
    • Windows XP, Chrome, Vista
    • Crash, JavaScript, C++ Engine



, ,