1959 <————————————————————————————————-> 2012
COBOL ———————————————————————————————– Today
During the first 53 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.
Just prior to 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 would that look like?
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… for example, the ubiquitous term “unit testing” could be divided into two categories:
- Unit (Quality) Designing
- Unit (Regression) Inspection
With these labels as inspiration a balanced application development journey could commence whose outcome is uncertain; perhaps options other than a continuous integration hammer are available for every quality-deficient nail?
Unit 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.
Unit Designing might include ”verify” methods that enable design quality feedback. For example, verification that a Domain Entity includes two constructors… or that a Util class has a private constructor to avoid inadvertent instantiation… provide simplistic examples of verification to team mutually agreed upon patterns.
So how do we sequence our work if we are using the same tool for both Designing and Inspection? Start with design… and when the design stabilizes and you are happy with it… use a coverage tool to decide the desired quantity of inspection. Said another way, mentally separate the practise of Quality Designing and Regression Inspection — and then begin to discover which one deserves greater focus.