Bug vs. Defect

Many times, I get caught up in discussions about the validity of a defect.

“Isn’t that actually a change request?”

“That looks more like a data problem.”

“This is a feature; not a defect.”

One of the root causes for this is that testers are supposed to report any deviation from the expected behavior of a system. Now – don’t get me wrong – this is how it should be! However, due to limitations in the standard configuration of most of the defect reporting systems, these deviations are often being reported as “Defects.”

“Defect” is therefore being used as an equivalent expression to “Deviation.” And that can cause a lot of problems and unhelpful discussions, especially when working with external software vendors. Defect management and reporting can get a “hot topic” very quickly, because there are direct contractual implications associated with the word defect. Please note that I am not saying here that it is wrong to use that word– I just want to highlight that this is likely to cause trouble when dealing with the developers and vendors.

One way of solving this issue is to introduce the term “bug” to your defect lifecycle and have a clear definition of what is a bug, and what is a defect.

Last time I spoke to James Bach, he came up with a definition that I believe makes great sense:

A bug is anything about the product that threatens its value to someone who matters

A defect is a breach of – a contractual agreement (if working with Vendors) – or – of the agreed functionality of a software (requirement) in cases where the developers are in house (while you could argue that the first statement – “contractual breach” – is valid for both scenarios since you would have kind of a “internal contract” between the Sponsor and the developers.

In contract law, there is a concept of “substantial compliance” to a contract. Substantial compliance means “compliance with the substantial or essential requirements of something (as a statute or contract) that satisfies its purpose or objective even though its formal requirements are not complied with.” (http://bit.ly/1Qs5m2J) This allows us to distinguish between a substantial defect (one that represents a failure to substantially comply with the contract) and a minor defect (or any other kind of bug that threatens the value of the product but does not violate the terms of the contract).

Testers are reporting potential bugs – not necessarily defects. This is because, at the time the tester reports, he doesn’t necessarily know the true nature of the problem. Since you don’t want the tester to accidentally dismiss a big problem just because he doesn’t understand it, testers should be instructed to report potential problems even if they seem somewhat marginal.

Bugs need to get analyzed and “triaged” before one can agree on if a particular bug is a defect or not (best in a team incl. all required stakeholders). If it is, the status will be changed to “defect” and it follows the usual defect-cycle.

I have experienced a lot of benefits and positive feedback from introducing this solution. It resulted in much less discussions with the vendors/developers and a more accurate and less challenged reporting practice.

What is your view on bugs vs. defects - and how did you solve the above challenge in your defect lifecycle?