The D.E.B.S.C.I. Bug Reporting Format

As QA, we've all run across it at one time or another - a user enters a bug that is incredibly vague and leaves us clueless as to what the problem is. It's a sentence, or a fragment of a sentence, or a blank bug with the title "Page Got Broke" and an attached screenshot of a seemingly normal page (to you, at least). As a QA Resource who has interacted with outdated bug tracking systems and little guided structure to how to enter a bug, this issue can be persistent and troublesome. The time spent on back and forth between the client and resource, trying to squeeze all the information that is needed out of them could better be spent on resolving or discussing the issue with the development team as necessary.

It's clear that people need direction on how to enter a bug and what information to include. If you suggest providing "as much information as possible", you're likely to be flooded with unnecessary detail about the smallest issues. Suggesting that someone "use their best judgement" often leaves them feeling uneasy and unsure of themselves. The best solution, then, is short instruction that can be remembered by the vast majority of people. Why not take that idea and create a short acronym that people can easily remember? The D.E.B.S.C.I. bug reporting format is a way to minimize the amount of poorly reported bugs within a loosely structured bug tracking system. Let's break down the acronym:

Description - Provide a small paragraph explaining the issue. For example, "I navigated to the homepage in a new browser, went to the contact us page and saw an error"

Environment - Provide the environment this issue was identified in. Alpha, Beta, Production, etc.

Browser - Provide the browser you saw the issue in. This works for web applications and websites. If you are a software QA tester, you could replace this with "Version" for OS or program version

Steps to Replicate - Provide step by step instructions on what you did when you saw the issue. For example:

1.) Navigate to [URL of homepage]

2.) Locate and click on "Contact us" link in the footer

3.) Determine if user sees an error instead of the contact us page

Current Outcome - Provide the current outcome, or current bug. For example, "When a user clicks on the "Contact Us" link, they are taken to an error page

Intended Outcome - Provide the intended or expected outcome. For example, "When a user clicks on the "Contact Us" link, they are taken to the Contact Us page without error

Although not perfect, this simple acronym can assist in the QA process by allowing team members and clients to more easily remember the information that should be provided in a bug report. Clients no longer feel that they have no instruction on how to enter an issue; they can be reminded of the DEBSCI format via a quick e-mailed explanation or document as needed. While it has not fully eliminated vague bug reports, it has certainly diminished the number of bugs I get that make me scratch my head.

How do you guide clients and coworkers on entering bug reports?