secondary work products
07.07.12 - 15:57 - Filed in: Software Testing
There was a civil defense educational film back in the 50s that taught children to duck and cover in the event of an atomic attack. People lived in constant fear of annihilation and searched for behaviors that could be helpful. Although, in the face of the enormous destruction of such an attack, the behavior they were taught wouldn’t probably have been of real use.
But that was not the point. As the real problem was outside the capabilities of the people, the belief in the effectiveness of the behavior was good enough. The advocates of this educational initiative must have known quite well, that there was no point in ducking and covering. But it was much easier to achieve than to really solve the problem.
Such was the world in the times of the cold war.
In the testing world, the factory schoolers also do their ducking and covering by focusing on secondary work products such as reports and plans and test case counting and not on the testing itself. Same here, it is much easier to create templates, processes and standard operating procedures than acquiring the skills of an excellent tester. It is much easier to proscribe actions that can be followed like check lists. And the production of piles of paper is intimidating, it covers your ass and it bores intelligent people.
If you cannot do the real thing, engage in ersatz behavior instead. That would be cute, if all this testing was just a game and software was something that was presented as a spectacle in a circus. But there are many areas - especially in the medical software domain - where people’s lives might depend on the robustness of applications. That is not something to be handled with a cover-your-ass mentality.
Just recently, there have been two elaborate blog posts by Huib Schoots and Johan Jonasson on the subject of adaptability vs. context-driven. Quite interestingly, a discussion between a TMap advocate and Huib evolved. As expected there was no agreement because both spoke about different things.
As an example lets take the word ‘test’. In the context-driven world ‘test’ is a verb. It is an action that yields information. The factory schoolers understand ‘test’ as ‘test case’ or ‘test case document’. A test is something that is handled in a tool and proves coverage of something. So, when a factory schooler discusses testing with a context-driven person, they won’t understand each other because they speak about different things.
Whenever we do testing, let’s never duck and cover.