Kenneth Hass 2002
1
What Is a Defect Anyway?
Reevaluating our understanding of defects
A definition
What is a defect anyway? If you ask 10 people, you’re bound to get ten different answers
(or at least 9 different answers and a dumb look). For years, a war of words has been
raging about how to define just what defects are, and just how important fixing them
really is. Defects, or bugs, have been defined, categorized, classified, rated, and still we
can’t seem to agree. So why is getting some kind of consensus like trying to nail Jell-O
to a tree? Because developing and testing products are, in most cases, distinctly different
activities. You have different groups, each with different (often oppositional) charters,
each asserting its own definition on a single process. Probably the most accurate and
succinct definition I’ve heard came from… well, me.1 I was giving a presentation on
exploratory testing methods and someone in the rear of the audience (they’re always in
the rear of the audience) spouted out the “what’s a bug” question. I paused, poised my
head on my hand Rodin-style, pontificated for a moment, and then answered, “I’m not
sure, but I know it when I see it.”
There are surely more formalized definitions of what constitutes a defect than my semi-
intuitive response above. Most projects define defects as operation or functionality that
fails to meet the product functional specification. Where the functional specification
document calls out the ability to do a specific task or operation with the product, a failure
to do that task successfully constitutes a bug. This definition, however, seems a bit
nebulous, allowing too much wiggle room if debates arise over whether something is a
defect or not. The lines heard most often in these cases are “that’s not a bug, that’s a
feature,” “it’s not in the spec[ification],” and “it’s working as designed.” My favorite
rebuttal to the last one is that it’s working as poorly designed. Unfortunately for
simplicity’s