During the first 54 years of IT business application development, when the conversation turned to quality, some said we need high-cohesion and loose-coupling while many postulated:
- We need to test more.
- We need to test better.
- We need a better testing process.
- We need better testing tools.
- We need to write duplicate code in the form of mock objects.
Just before the dawn of the COBOL age, W. Edwards Deming was busily contributing to a Japanese manufacturing quality transformation. His principles are clearly stated, including the following:
Cease dependence on inspection to achieve quality. Eliminate the need for
massive inspection by building quality into the product in the first place.
So a thoughtful person might be inclined to ask:
Is IT ‘testing’ a type of inspection?
And if so, why do we emphasize ‘testing’ so much?
If we were to value testing on the right, and building quality into the product on the left, what does that look like in the ‘real world’?1
It seems to me the first step toward clarity of practice is clarity of expression. Some new terminology might give us fresh perspective and creative focus… such as, the ubiquitous term “unit testing” could be divided into two categories:
- Quality Designing
- Regression Inspection
With these labels as inspiration a balanced application development journey could begin whose outcome is uncertain; perhaps options other than a continuous integration hammer are available for every quality-deficient nail?
Regression Inspection gives rise to “assert” methods that automate notification when the implementation no longer meets the Inspection Criteria established by a product owner… which is a good thing.
Quality Designing might include “verify” methods that enable class structural feedback. For example, verification that a Domain Entity includes two constructors… or that a Utility class has a private constructor to avoid inadvertent instantiation, provide simplistic examples of verification to mutually agreed upon team patterns.
So how do we sequence our work if we are using a JUnit-like tool to aid both Design and Inspection? One perspective is to start with design… and when the design stabilizes through Test Concurrent Development and you are happy with it… leverage a code coverage tool to decide the desired quantity of inspection. Said another way, even though we might use the same tool — mentally separate the practice of Quality Designing and Regression Inspection — and then iterate to mature both disciplines.
- Subtle reference to the Agile Manifesto semantic.