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.
_Marvin
Revised: 10/2012
Hi Marvin! Can you say more about how what you wrote above differs from Design by Contract (DBC) as proposed by Betrand Meyer (who argued for things like preconditions, postconditions and invariants to be part of the programming language for specifying the interface instead of relegated to comments and/or assertion subroutines).
[NOTE: Some folks believe that the basic ideas behind DBC are what TDD (and later BDD) were derived from.]
hmmm… have my “Object-Oriented Software Construction” (2nd Edition) text here… all 1,254 pages… not sure I see a conflict — do you see one?
_Marvin
Not seeing a conflict, just wondering if youre talking and discussing your way through a road that’s already been travelled and which might benefit more from building on and referring more of the same concepts as those of the “giants” whose shoulders you are standing on, to see if it might give more clarity and simplicity (beyond just rediscovery).
ah… see your point. This will take some future thought.
I’m wondering if the current relevancy of Bertrand Meyer (2nd edition 1997) is clear? I’ve been surprised teaching both in North America and India regarding the lack of “giant” awareness… and am not feeling up to rebuilding “shoulders” at the moment.
Regardless, this sounds like a thoughtful mental exercise and the suggestion is appreciated.
_Marvin