Generally, a bug/defect report should be self-contained and include all information required to reproduce and triage the bug.
Clarity and reproducibility are key. The better bugs you write, the happier the devs will be. Happy devs write happy code. Happy code means less bugs!
The key components of a bug/defect report are:
- Title
- A concise summary, don't include reproduction steps (at some point you'll be tempted to)
- Description
- A discussion of what is wrong, possibly how it affects the user. If you are familiar with the issue or the code, give that information.
- If there is a history with this issue or this type of issue, include it here.
- Environment
- version or build #
- platform or server
- browser (Chrome, FireFox, etc.)
- data such as user info (could also just be in Steps to Reproduce)
- Can include other things (on mobile you could include things like connection type of WiFi or Cellular)
- Steps to reproduce
- Actual result
- Expected result
- Evidence
- screenshots, logs, stack traces, etc.
- for search ability: copy/paste key parts of logs, error msgs, and the top several lines of stack traces. Screenshots of logs or err msgs are fine but ALSO paste the text in the description or a comment
- Priority
- How urgent should we fix this?
- Severity
- How severe are the consequences of this bug when it does happen?
I like to format my Steps to Reproduce as shown below, to allow for a discussion after each step (numbers = actions, dashes = how the app behaves).
Most companies don't have strict formats, this is just my personal style guide (just as dev teams have style guides for coding).
1.login to www.xyz.com as user01 password abcd1234
2.put any item > $100 in the cart
-cart shows the item but not the tax
3.go to settings page, then go back to the cart page
-cart now shows item AND the tax
I've included multiple actions in step 3. Personally I think this is ok as long as it's unmistakably clear.
Priority vs severity:
See this post.
