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/
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: g 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)
