When Programmers and Testers Collaborate
Janet Gregory
SOMETHING MAGICAL HAPPENS when testers and programmers start to col- laborate. There is less time spent sending bugs back and forth through the defect tracking system. Less time is wasted trying to figure out whether some- thing is really a bug or a new feature, and more time is spent developing good software to meet customer expectations. There are many opportunities for starting collaboration before coding even begins.
Testers can help customers write and automate acceptance tests using the lan- guage of their domain with tools such as Fit (Framework for Integrated Test). When these tests are given to the programmers before the coding begins, the team is practicing acceptance test–driven development (ATDD). The program- mers write the fixtures to run the tests, and then code to make the tests pass. These tests then become part of the regression suite. When this collaboration occurs, the functional tests are completed early, allowing time for exploratory testing on edge conditions or through workflows of the bigger picture.
We can take it one step further. As a tester, I can supply most of my testing ideas before the programmers start coding a new feature. When I ask the pro- grammers if they have any suggestions, they almost always provide me with information that helps me with better test coverage, or helps me to avoid spending a lot of time on unnecessary tests. Often, we have prevented defects because the tests clarify many of the initial ideas. For example, in one project I was on, the Fit tests I gave the programmers displayed the expected results of
184 97 Things Every Programmer Should Know

a query to respond to a wildcard search. The programmer had fully intended to code only complete word searches. We were able to talk to the customer and determine the correct interpretation before coding started. By collaborating, we prevented the defect, which saved us both a lot of wasted time.
Programmers can collaborate with testers to create successful automation as well. They understand good coding practices and can help testers set up a robust test automation suite that works for the whole team. I have often seen test automation projects fail because the tests are poorly designed. The tests try to test too much, or the testers haven’t understood enough about the technol- ogy to be able to keep tests independent. The testers are often the bottleneck, so it makes sense for programmers to work with them on tasks like automa- tion. Working with the testers to understand what can be tested early, perhaps by providing a simple tool, will give the programmers another cycle of feed- back that will help them deliver better code in the long run.
When testers stop thinking that their only job is to break the software and find bugs in the programmers’ code, programmers stop thinking that testers are “out to get them,” and are more open to collaboration. When programmers start realizing that they are responsible for building quality into their code, testability of the code is a natural by-product, and the team can automate more of the regression tests together. The magic of successful teamwork begins.