Software Tester: A Role in Transition
It was John Seddon, the British psychologist and author, who coined the term “failure demand” for demand that occurs on a system only because it fails on the first try. Seddon was talking about call centers that put you on hold, transfer you, or force you to call back because they don’t solve your problem the first time, but we experience the same thing in software all the time.
Over the years, some people have advanced the argument that all testing is failure demand—after all, if the software would “just work,” we wouldn’t need to test it. They argue the entire test/fix/retest cycle is waste.
The common counter to that argument is that the number of test combinations is infinite, no one can think it all through, and it still makes sense to check. “Measure twice, cut once” is not waste, goes the thinking.
But that’s not what happens. Most of the time, the tester role is created to deal with too much failure demand. The software is terrible and the customers get skittish, so the company creates a test role to deal with it.
I’ve seen the same thing happen with business analysts, and even development management. The programmers ask questions about what the software should do, the eyes of the customer glaze over, and a translation layer between the two is formed. Done poorly, these roles create more problems than they solve.
Twenty years ago Extreme Programming suggested “cranking the dials to 11” to eliminate failure demand. Get rid of the BA role, get rid of testers, program in pairs, define acceptance checks (which were probably automated), and create unit tests that run constantly. A few organizations—mostly contract shops—experienced massive improvements using those methods, but for many, the transition was too much, too quick.
Instead of trying to cover up failure, the Extreme Programmers were trying to program better. Teams doing Extreme Programming can drastically reduce the defect rate, while teams automating parts of deploy and monitoring can find bugs in production faster and reduce time to recovery. On many much-touted examples, these teams have no testers. The tools Extreme Programmers use—unit tests, continuous integration, refactoring, and defined examples—are becoming more and more popular.
Will the testing role go away?
The tester-as-homework checker role, where we make sure people do what they should be able to do themselves—that might go away. However, that probably won’t be anytime soon, so there is plenty of time to learn other testing functions.
The state of the traditional tester role is in flux, so it’s time to take a fresh look at testing.
How do you think testing will evolve? What are some important skills to have for the future?
