Difference between revisions of "Bug Report"
Jump to navigation
Jump to search
(Created page with "== Overview == I guess I'm opinionated about bug reports. As a lead or manager, I often end up recommending some revisions in our bug reporting template or process. Nothing ra...") |
(→Closing a Bug) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 14: | Line 14: | ||
=== Closing a Bug === | === Closing a Bug === | ||
* Keep notes on your progress. Try to develop and prove a hypothesis. If that fails, document it. | * Keep notes on your progress. Try to develop and prove a hypothesis. If that fails, document it. | ||
| − | * When closing the ticket, write up a brief summary of both the problem and the solution. | + | * When closing the ticket, write up a brief summary of both the problem and the solution since your understanding of both will usually evolve as you work through the problem. |
== Template == | == Template == | ||
| Line 21: | Line 21: | ||
* Title [String] | * Title [String] | ||
* Problem Statement [Text] | * Problem Statement [Text] | ||
| − | |||
* Expected Behavior [Text] | * Expected Behavior [Text] | ||
* Actual Behavior [Text] | * Actual Behavior [Text] | ||
| − | * | + | * Steps to Reproduce [Text] |
| − | * Notes [Text] | + | * Evidence (Screenshots, Videos, Logs, Error Reports) [Text] |
| + | * Technical Notes [Text] | ||
* Environment [String/Enum] | * Environment [String/Enum] | ||
* Severity/Urgency [String/Enum] | * Severity/Urgency [String/Enum] | ||
Latest revision as of 11:31, 23 January 2023
Contents
Overview
I guess I'm opinionated about bug reports. As a lead or manager, I often end up recommending some revisions in our bug reporting template or process. Nothing radical. As the references below will show, this model is largely a synthesis of recommendations I've encountered and successfully used over the years.
For a great general treatment of the subject, I recommend Simon Tatham's How to Report Bugs Effectively.
Practices
Opening a Bug
- Include a problem statement with your bug that offers a human-friendly description of the problem with context that will help other people understand the issue quickly and precisely.
- In Steps to Reproduce, include links to URLs and be explicit in your guidance. This article offers some nice good/bad examples: https://medium.com/we-are-testers/chapter-4-how-to-write-clear-and-efficient-steps-to-reproduce-in-your-bug-report-d96039a1c77d
- Try to capture address bar (URL) in screenshots.
- If opening a ticket using an automated tool, update the ticket to include additional context and assign yourself as reporter.
- If you discuss the ticket in standup or on Slack, make sure to capture any important information in the ticket itself.
Closing a Bug
- Keep notes on your progress. Try to develop and prove a hypothesis. If that fails, document it.
- When closing the ticket, write up a brief summary of both the problem and the solution since your understanding of both will usually evolve as you work through the problem.
Template
I like having the following fields in my bug form. If you are using Jira, you can modify your template:
- Title [String]
- Problem Statement [Text]
- Expected Behavior [Text]
- Actual Behavior [Text]
- Steps to Reproduce [Text]
- Evidence (Screenshots, Videos, Logs, Error Reports) [Text]
- Technical Notes [Text]
- Environment [String/Enum]
- Severity/Urgency [String/Enum]
This list is based off this blog post: https://testlio.com/blog/the-ideal-bug-report/
Examples
I usually try to offer actual tickets from my company's ticketing system as good and poor examples.
