When reproducing a crash-causing bug to developers


Adapted shamelessly from devops reactions.


When does a bug matter?

“Quality is value to some person (who matters). A bug is anything about the product that threatens its value.”

That quote is taken from Satisifice’s Rapid Software Testing seminar materials (a seminar which I attended last October. Great stuff.)

In the product that I’m working on these days, there’s this bug that’s been there for quite some time, where under certain conditions, a user may find himself stuck in an infinite loading screen. However, during triage this bug was always deemed “not important enough” to fix.

Now, our product is undergoing review by a certain big company that wants to include it in their product. They encountered this bug and they didn’t like it one bit. So, guess which bug just got promoted to “High Priority”?


The Smug Report

This made me laugh:

A [Smug Report is a] bug submitted by a user who thinks he knows a lot more about the system’s design than he really does. Filled with irrelevant technical details and one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it.

Also related to Drug Report (a report so utterly incomprehensible that whoever submitted it must have been smoking crack.), Chug Report (where the submitter is thought to have had one too many), and Shrug Report (a bug report with no error message or repro steps and only a vague description of the problem. Usually contains the phrase “doesn’t work.”)

As published on New Programming Jargon at CodingHorror.com