You say “defect”, the customer hears “defective” and the developers anticipate blame. You say “failure”, the customer hears “catastrophe” and the tech support staff anticipate overtime. You say “own goal” and the customer wonders what you’re talking about and you anticipate an imminent conversation with your boss.
As an industry we use many different names for bugs, including anomaly, call, crash, defect, DR, enhancement, error, events, exception, failure, fault, flaw, incident, issue, mistake, own goal, problem, side effect, suggestion, ticket, TR (collected from 1, 2, 3, 4). But surely it’s as Shakespeare never said:
What’s in a name? That which we call errors
By any other name would smell as sweat;
Really? What exactly are we talking about here? I like the broad Rapid Software Testing take on what a bug is:
A bug is anything about the product that threatens its value.
The BBST Bug Advocacy course has something similar:
Anything that causes an unnecessary or unreasonable reduction of the quality of a software product
finessing the idea by introducing the notion that there can be reasonable or necessary (to people who matter) compromises in a product, and that these might not be regarded as bugs.
Multiple names exist for many reasons including: because language is productive (e.g. metonymy, synonymy), because the distinctions are required or useful in some situations, because they’re taken from the tool used to manage them, because of misunderstandings, because of tradition, because of culture, because of migration of words from one person or project, or company or industry to another.
And some of the names here are probably not widely used as synonyms for bugs as a whole. Some are sub-classes of bugs, for example suggestion, crash and side-effect. Some are potential attributes of many sub-classes, such as regression or blocker. Some refer to the artefacts produced in the recording or acknowledgement of an issue and which, strictly, are distinct from its existence: ticket, call, report, incident and the like.
Does it matter that we have so many names, anyway? Put simply: yes, sometimes. People are highly attuned to nuances of meaning and also, more pertinently, to forming opinions based on their interpretation of a simple word. If you don’t believe me, sit in a meeting where a product or a company name is being decided. The choice of term for (let’s say) an issue can be interpreted as, amongst other things:
- Attributing blame for the issue, e.g. to a person, software component, process or company. Anne-Marie Charrett doesn’t use “the word defect because of the impact the word has on a developers ears. No-one likes to hear their code is defective, much better is a bug or an issue.” When I was a technical support manager, I made it policy never to refer to problems reported by customers as bugs (to the customer) instead we used the word issue, largely to avoid implicitly attributing blame to our product before investigation.
- Providing a value judgement on the issue, e.g. the existence of a defect as agreeing that the product is defective. When I attended Rapid Software Testing, James Bach was against using the word defect because of potential legal implications.
- Designating a severity or priority of the issue to e.g. you, a stakeholder, your company, your customer. For example, compare your reaction to being told there’s an incoming suggestion vs a failure. Similarly, the term used might identify a point in the time that the issue will be scheduled for resolution, e.g. an enhancement vs a blocker.
- Marking the issue as core or a symptom, e.g. a UI issue could be bad logic in the underlying model or bad rendering of the model. Jerry Weinberg makes a distinction between fault (an underlying issue) and failure (a manifestation of the fault) in Quality Software Management and other books. The BBST Bug Advocacy course makes error and fault synonyms and permits defect to cover both error and failure.
- Identifying a point in the production process that the issue was generated. The August 2013 issue of TEST magazine differentiates flaw (a design problem) from bug (coding error) while on the Software Testing Club forum, Chad Patrick noted a definition of error as “a problem created, found, and resolved during the same phase. So a bug introduced in code and caught during a peer review or unit test, an incorrect requirement uncovered and resolved during a static analysis during analysis, etc.” Fiona Charles suggests that defect has a pair term rarely used in software: “[the construction industry] also uses the term deficiency, to mean (approximately) things we should have built but didn’t – in contrast with defect, meaning things we built that don’t match spec.”
There’s some discussion on the STC about whether we need industry standardisation on these kinds of terms. I don’t think we do, although it’s clear that there’s a set of words that have loaded meanings in some circumstances and in any dialogue that requires non-shallow understanding, those terms are going to have to be defined.
As usual, context is the guiding factor. The people you’re talking to, the relationship you have with them, the kind of problem you’re discussing about the kind of thing that you’re building or supporting, how you’re discussing it need to be understood by both sides, or you’ll start to see issues, mistakes, errors, problems …
Recent Comments