Back in the day of cross-Atlantic boat travel, luggage that wasn't needed during the long journey was labeled "Not Wanted on the Voyage" and stowed away below decks. In this column, Fiona Charles suggests that testers can also be viewed as heavy baggage and not exactly welcome by some parties during the journey of software development. To understand why others might think this way, Fiona takes a good, hard look at what testers do that could possibly make them undesirable team mates.
Before intercontinental air travel became ubiquitous, people crossed oceans by ship. The things they needed for practical, everyday use traveled with them in their sleeping and living quarters. Other baggage—typically consisting of heavy and cumbersome items like steamer trunks—was labeled "Not Wanted on the Voyage" and consigned to oblivion in the ship's hold until the end of the journey.
In an earlier column ("What's In a Name?") I wrote about my concern that testers are often second-class citizens in the software world. I had just been hearing yet again that many agile teams don't value testers—that to them testers are heavy baggage and Not Wanted on the Voyage. But agile teams aren't the only people to have issues with specialist testers and their practices. Many managers, too, believe that testing is excessively slow, expensive, and not nearly effective enough for the realities of their delivery projects.
Some reasons for negative perceptions about testers and testing are beyond testers' control. And some of the conclusions are just plain wrong, or misguided at best. But in this column, I'd like to explore our own responsibility. What are the things that testers do or don't do that lead some software practitioners and managers to believe their projects are better off without us? Do we have beliefs and practices of our own that may be getting in our way?
Process vs. Skill
Too many of us put too much reliance on process and not enough on skill. In many organizations, before any testing can begin, testers must develop detailed test cases or scripts from frozen, documented requirements and then get them signed off. In some places, it's routine for "testers" who have no actual testing skills-or even business domain knowledge that might compensate a little for the lack—to execute test cases written by others.
I have managed many test efforts where it was appropriate—even essential—to the context to use predesigned test cases. Although, I have always insisted that testers execute tests they have researched and designed themselves. But this process is time-consuming, expensive, and flawed. It is not the most effective way to find bugs as other writers have said, and my teams have demonstrated many times with supplementary exploratory testing. Perhaps worst of all, it assumes a quality level in documented requirements that I don't remember ever seeing in thirty years.
When this is the only kind of testing done in an organization, is it surprising if managers don't see benefits commensurate with the costs? We need to be more flexible. The "traditional," structured test process is neither the only right way to test nor the only disciplined way. It should be one option among many, used only when it's clearly the right thing to do in the circumstances. But that means that all testers need to educate themselves and their organizations about other valid methods. Operating with flexibility rather than routinely following a structured process demands more of testers. The flexible tester needs skills to evaluate project contexts for the appropriate methods and techniques to use. That's only possible if the tester has a broad knowledge of what is available and the skills to execute the chosen methods and techniques.