When I started studying for the premier QA certification (ISTQB), my head performed an inelegant 360-degree spin.
The book Software Testing Foundations: A Study Guide for the Certified Tester Exam by Andreas Spillner, Tilo Linz, and Hans Schaefer, 4th edition, and published by Rocky Nook (2014), requires four different terms to describe a problem in software. Is this science gone too far, or is a software problem really so hard to comprehend that four terms are necessary?
Here are the four terms from the book’s glossary that stopped me in my tracks:
- Defect
- A flaw in a component or system that can cause it to fail to perform its required function, such as, for example, an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.
- Error
- A human action that produces an incorrect result. Also a general, informally used term for terms like mistake, fault, defect, bug, failure.
- Failure
-
- Deviation of the component or system from its expected delivery, service, or result.
- Result of a fault that, during test execution, shows an externally observable wrong result.
- Behavior of a test object that does not conform to a specified functionality that should be suitable for its use.
- Fault
- An alternative term for defect.
Software Quality Assurance (QA) is more practical than this kind of sterile academic language suggests. And no—being successful in QA absolutely does not require an advanced degree. To understand why these terms exist, we need to translate them into how QA actually works in practice.
- Error
- The human mistake
- Fault/Defect
- The problem in the system (source code)
- Failure
- The user-visible behavior
Humans make errors that introduce defects or faults into systems. Software users experience failures when those defects are encountered during execution. These terms describe different perspectives of the same underlying problem—what we usually just call a bug.
So why might we need four terms to describe a bug?
QA approaches depend on risk. Testing regulated medical devices carries far higher risk than testing a video game or typical line-of-business software. Higher-risk systems demand more formality, and with more formality comes stricter terminology in day-to-day communication.
In practice, the terminology matters less than clarity—but understanding why these distinctions exist helps QA adapt its rigor to the risk at hand.
Leave a Reply