As testers, one of the greatest challenges we face is the perception that the service we provide is a commodity. This may not be universal, but it is endemic in many parts of the IT industry.

Is software testing a commodity? According to Investopedia; “When a product becomes indistinguishable from others like it and consumers buy on price alone, it becomes a commodity”. In order for testing to qualify as a commodity, testing services must lack qualitative differentiation. Yet testing has many sources of differentiation:

• Approach. Testing is context dependent. Some testers will bring practices and experiences that are relevant to a project, others will not. Some will attempt to bend project context to their approach, others will adapt to its specific needs. Perhaps one day this will cease to be a source of differentiation, but not today.
• Location. Testing involves the discovery, trade and transformation of information. When communication channels are open and information is shared, remote –even very remote- testing is feasible. When information is hidden and hallway decisions are the norm, colocation is a huge advantage. Project politics and project culture can have a significant impact on the value provided by testers in different locations.
• Skills. Testing is a vast and growing discipline, with ample room for specialization. Again, context plays a role: different projects will require testers with different skills. Further, the range of skills required is mind boggling: modeling skills, analysis skills, design skills, communication, relationship and interpersonal skills. Indeed, testing thrives on variety – the range of insights that different people with varied skills, outlooks and experiences bring to bear. The notion that testing is undifferentiated is anathema to testing itself.

In short, not all testing services are equal, nor should they be. Testing is not a commodity.

Then where does this perception come from? It originates from the belief that testing is unskilled. The most obvious act in testing is checking, which in itself requires little skill. In contrast, skilled activities such as modeling, analysis, design and evaluation are harder to observe. This belief is as superficial as believing that the cover is all that makes up a book.

Why is this important? The view that testing is a commodity provided by the unskilled has chilling effects on collaboration, effects that can destroy the mutual interdependence between testers and project.

Let’s consider one possible scenario that illustrates how this can play out. Imagine for a moment that you are a non-testing participant on a project.  Imagine that you see testing as essentially unskilled, a simple matter of translating specifications into scripts and then executing them.

You’re a busy person, and like anyone else on the project you are probably juggling a dozen different things at any given moment. The testers keep calling you, or emailing you, or messaging you, or asking for meetings. Why do they keep bothering you?!? Can’t they just get on with scripting? Can’t they do their jobs?

Testing depends on information. Mere specifications are a remarkably low bandwidth form of communication and on their own are seldom adequate for effective testing. Testers need to ask questions, it’s what they do. Yet by doing so, the tester can fail in the eyes of their stakeholders.

This is getting crazy, the testers won’t give up. Now they are calling the PM, BA and developers. Don’t they know we’ve got deadlines? Don’t they know we’ve got enough of our own work to do, without having to do theirs as well? It’s time to channel this through a handful of people.

A common reaction to the “we’re too busy to answer questions from testers” problem is to enact a communication plan which restricts the flow of information to (and from) testers through a small group of people. Those people may not have direct access to the relevant information, so may in turn have to ask other members of the project, thus continuing the distraction and introducing rounds of questions, answers and clarifications bouncing back and forth. With communications bandwidth restricted, and telephone game distortion, the value of information available to the testers diminishes rapidly.

What’s with these testers anyway? Not only are they a nuisance, but now I’ve seen their scripts, they’re missing important stuff! And that bug that got through the other week…this can’t go on. The testers are clearly rubbish, we need to manage them the directly.

At this point, the relationship between the testers and the wider project has completely failed. It is almost inevitable that this will lead to micromanagement, a master/slave relationship that further inhibits the testers’ opportunities for success. The mechanisms for this are varied. Perhaps the absence of trust will lead to demands for excessive documentation. Perhaps process or standards compliance will be enforced, in word rather than in spirit. Perhaps unsound performance metrics will be imposed. Each introduces opportunity costs, degrading the volume and value of the information the testers can provide. Each further distorts tester behavior. Each will increase the real cost of testing. And satisfaction in the testers will spiral ever downwards until the project comes to its naturally end, or the testers are dismissed.

A further implication of commodity testing is the notion that testing services are essentially fungible, i.e. that it does not matter who provides the service, or from where. All that matters is price; this is labor arbitrage. The result is a race to the bottom, with testing service providers in the lowest cost regions of the world the front runner. Remote testing may be successful in some situations, but imagine the scenario above compounded with multiple time zones and cultural factors such as power distance. In such circumstances, success is not an option.

How might things be different? We testers need to be aware of these issues, and to realize that things can be different. We need to continuously develop our skills, to market the importance of them, and to find ways to give visibility to those aspects of testing that are not checking. The alternatives to our craft are unthinkable.