Encouraging Programmers to be Testers

A colleague wrote to me recently and asked about a problem that he’s had in hiring. He says…

The kind of test engineers we’re looking for are ones that can think their way around a system and look for all the ways that things can go wrong (pretty standard, so far), and then code up a tool or system that can automatically verify that those things haven’t gone wrong (a bit more rare, especially, for some reason, in the part of the country where I’m working).

Any thoughts on how to shift that perception here to be more closely aligned with the west coast?

My reply went like this:

I don’t like that particular perception, myself. I observe that the “Software Development Engineer in Test” view often presupposes that the SDET role is a consolation prize for not being hired as a Real Programmer on the one hand. On the other hand, the view poses a barrier to entry for non-programmers who want to be testers.

If your prospects think, “Oh, that’s QA” in this dismissive kind of way, what kind of testers are they going to be? Moreover, what kind of programmers are they going to be? To me and to our community, testing is questioning a product in order to evaluate it. Testing is a service to the project, wherein testers help to discover risks and problems that threaten the value of the product and the goals of the business. While testers are specialists in that kind of role, testing is something that any programmer should be doing too, as he or she is writing, reviewing, and revising code. So if prospects think that testing is some kind of second-class role or task, who needs them? Encourage them to take a hike and come back when they’ve learned not to be such prima donnas.

If offered a gaggle of programming enthusiasts to choose from, I’d prefer to hire the person who is most genuinely interested in testing. I’d give that person a toolsmith role, wherein (s)he provides programming services to other testers. In addition, the toolsmith can provide the service of aiding testers in learning to program, while the testers help the toolsmith to sharpen his/her testing skills.

If you’d like to motivate programmer-types to test, here’s a suggestion: Instead of treating testing as a programming exercise, treat it as a more general problem-solving task in which hand-crafted tools might be very helpful. James Bach and I do this by giving people testing puzzles that look simple but that have devious twists and traps. In my experience, most programmers (and all of the best ones) enjoy challenging intellectual problems, irrespective of whether programming is at the centre of solution. In our classes and at conferences and in jam sessions, we show programmers over and over again how they can be fooled by puzzles, just as anyone else can. We hasten to point out that programming can help to solve problems in a manner that can be far more more practical and useful than other approaches for solving some problems in some contexts. But as it goes with production code, so it goes with test code: working out how to solve the problem is the most challenging part, and writing a program is a means to that end, rather than the end in itself. The trick is to help people to recognize when they might want to emphasize writing code and when they might want to emphasize other approaches and other lines of investigation.

As Cem Kaner points out in his talk “Investment Modeling as an Exemplar of Exploratory Test Automation“, the best skilled testers (and especially those with programming skills) have the kind of mindset that we might easily associate with the best quantitative analysts. On Wall Street, they’re called quants, and they make a lot of money. In order to be successful and to reduce risk, both their programs and their models have to be useful, reliable, accurate—which means they have to be tested, and tested well.

Trouble is, many managers treat testing as a rote, clerical, bureaucratic, mechanistic activity. If that were all there is to testing, it would be a dead-end role and ripe for automation, but testing is so much more than coding up a set of checks. It’s up to us to help others to recognize what testing can do, by offering conversation, challenges, and leadership by example—and information about products and projects that people genuinely value. To do that, we need a community of testers who are passionate about their craft and practice it with skill, recognizing that it’s thinking—about risk, cost, value, and learning—that’s central.

But if you put the hammer and hammering at the centre of the task, you’ll get enthusiatic hammerers applying for the job, where I suspect you really want cabinet makers.