Schedule and Events



March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email: Matt.Heusser@gmail.com

Tuesday, May 22, 2007

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.

3 comments:

Jonathan Kohl said...

I especially like the diagram. :-)

Thanks for the link - this is an issue that we can all work on. Working collaboratively to help each other out. That article was an attempt at bridging the gap between the programmers and non-programmers. Both can add a lot to a project, and sometimes working together can have cool results.

-Jonathan

Vijay said...

ya the diagram is too cool and realistic.

I also observed the same things in my testing career. Developer doesn’t want to test his or her own code! Even if they test, they can't find anything wrong with it.
I am disagreeing with your point that "telling a developer to test is like telling a tester to write the code!" Dev and tester should work collaboratively as stated by Jonathan so that tester should also love the coding and debugging.
And if we want to build a automation framework then this is Essential.

Phil said...

As a dev turned tester it's nice to know I'm such a rare species though I did wince when I saw the diagram as I have been that finger pointing 'test expert'

Any ideas as to why there aren't that many ?
( I have a few ideas and hope to blog about them at some point )