Bug Report

From Klenwell Wiki
Revision as of 22:47, 22 September 2022 by Klenwell (talk | contribs) (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...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.

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]
  • Steps to Reproduce [Text]
  • Expected Behavior [Text]
  • Actual Behavior [Text]
  • Proof (Screenshots, Videos, Logs, Error Reports) [Text]
  • 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.

References