(^184) 97 Things Every Programmer Should Know
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