Tester/Dev Communications

The space between computer programmers and testers is shrinking - but there are still a lot of communications problems. For example, when I first met Harry Robinson, he was working at Microsoft, and pointed out that Microsoft had a very hard time finding "true" Developer/Testers. Oh, they had plenty of good manual testers who were professionals and had read the literature. And they had plenty of programmers who wanted to write test frameworks - frameworks that allowed somebody else to define and automate tests. The problems was finding programmers who were excited about testing - who wanted to design good tests and then automate them against existing systems.

Harry was interested in me because I was a tester who likes to automate stuff, instead of an automater who likes to build frameworks.

I view this as a fundamental problem for dev/testers - software testing takes expertise. Taking a dev and saying "write test automation" is about as useless as telling a tester to write code.

And true, skilled testers aren't helping much. To explain this, I drew a picture:



First of all, complaining that programmers don't know how to test doesn't help them. Then we make it worse by adding a hurdle of test education "Before you can talk to me about testing, go read Beizer, Meyers, Jorgensen, Kaner, Bach and Copeland" -- all good books, but they don't help a developer write automation today.

For requirements, we finally figured out that you need two people in the room - both the customer and someone technical - to balance the cost and the business value. I submit that it's the same thing with test automation. Start with pairing a dev and tester, and eventually, grow the skill set so that both people can do test automation.

There are only a few people in the world of software that are working on this. Brian Marick teaches courses in unit testing for developers, and Elisabeth Hendrickson works in that space as well. As for me, I'll be doing my part, speaking at the Google Test Automation Conference this August in New York.

We're getting close to bridging the gap between programming and test. Let's keep going.

UPDATE: Jon Kohl points me to this article he wrote in Better Software Magazine, expressing some of the same concepts.