Apples And Oranges
In “Leadership, Teamwork, and Trust“, Watts Humphrey and James Over build a case against the classic “Test To Remove Defects” mindset (see the left portion of the figure below). They assert that testing alone is not enough to ensure quality – especially as software systems grow larger and commensurately more complex. Their solution to the problem (shown on the right of the figure below) calls for more reviews and inspections, but I’m confused as to when they’re supposed to occur: before, after, or interwoven with design/coding?
If you compare the left and right hand sides of the figure, you may have come to the same conclusion as I have: it seems like an apples to oranges comparison? The left portion seems more “concrete” than the right portion, no? Since they’re not enumerated on the right, are the “concrete” design and code/build tasks shown on the left subsumed within the more generic “Product Development” box on the right?
In order to un-confuse myself, I generated the equivalent of the Humphrey/Over TSP (Team Software Process) quality process diagram on the right using the diagram on the left as the starting reference point. Here’s the resulting apples-to-apples comparison:
If this is what Humphrey and Over meant, then I’m no longer confused. Their TSP approach to software quality is to supplement unit and system testing with reviews and inspections before testing occurs. I wish they said that in the first place. Maybe they did, but I missed it.
Leave a reply to bulldozer00 Cancel reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
I completely concur with your understanding. Defects found during the personal and team inspections are recorded to help understand if any issues crept in before the code was even passed down to Unit and System Testing; the compiler only finds around half the issues, so jumping straight into unit testing, in theory, would result in the remaining half of those issues being found at more expensive stages in the process. The coach should help ensure that inspections are finding enough issues (they can estimate how many should be found based on the number of lines of code being compiled). If hardly any issues are being found during inspections and a lot during unit/system testing, it points to poor quality inspections. Coaching can help encourage developers to ensure they spend adequate time on inspections.
Thanks for stopping by Jared