Long-time reader Patricia Osorio Aristizabal sent the following question via e-mail (info@rbcs-us.com):

Hi Mr Black

I have a dilemma and I would like to know your thoughts about it.

It is clear for me the difference between error, defect, and failure (IEEE 610). Besides, the convenience of keeping in mind and use these words orally in order to help the project team – may be – to find out where or when an issue (incident) occurs. However, it is not easy to change all the team to use these words without cause resistance and incredulity to the importance of that difference. In your experience, how I could get to change first, my team and then all the organization to standardized the use of that concept? Could you please give some tips to do this change?

For those readers not familiar with the distinction to which Patricia alludes, here are the ISTQB Glossary definitions for each of those terms:

error (or mistake): A human action that produces an incorrect result.

defect (or bug): A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.

failure: Deviation of the component or system from its expected delivery, service or result.

incident: Any event occurring that requires investigation.  [Note: During testing, any failure that occurs would be an incident, though some incidents ultimately turn out to be false positives caused by things like bad test cases, bad test data, bad test environments, etc.]

So, based on these definitions, the programmer makes an error (or mistake) in their thinking while writing a program, leading to a defect in the code.  The code is executed during testing and the defect produces a failure.  The tester observes the failure, investigates the incident, and presumably files a bug report.

Certainly, having clear thinking in one’s mind–reflected by understanding the distinctions drawn–can help testers understand what’s going on.  However, it can be difficult to convince people to adopt the definitions. As a consultant, I’m familiar with the challenge of trying to motivate people to make changes of any sort.

The general rule for change, in my opinion, derives from a basic rule of sales:  People move away from pain much more quickly and reliably than they move toward a desirable situation.  In other words, if you want to motivate change, make people aware of the organizational pain–waste, delay, frustration, etc.–associated with the behavior you want to change, and then suggest how to make that pain go away based on your proposed change. 

So, Patricia, if you can find a way in which a lack of clarity on these definitions is causing waste, delay, frustration, or other sorts of organizational problems, then you might succeed at motivating changes here.