Test and Dev have historically been at odds. In the worst teams the only reason Dev and Test acknowledge each other’s existence is to work out some signal so that Test knows when to array themselves along the wall to catch the app when Dev throws it over, and so Dev knows when to go looking for the stones with bug reports rubber-banded around them that Test throws back over the wall each time they find a bug. (Some Test teams opt to impale the bug reports onto the bloody mass that is what’s left of the app after their bug bashes, and then heave that chunk of rotten carcass back over to Dev in a bit of payback. Sounds fun and quite cathartic, especially if you take the time to build a catapult that enables you to hit Dev’s barracks or lunch hall rather than just their back forty. I’ll have to try it the next time I run into a bad Dev team.)
I’ve never had the bad luck to be on a team this bad, but neither have I been on a team that was all that much better. Every team I’ve been part of used some method to say “OK, Dev is done with this code; here you go, do whatever you like with it.” These turnover processes have been many and varied (one team used Test Release Documents, or TRDs — it was with great glee that we testers discussed the latest “TuRD” a developer gifted us with), but at their core they all simply released Test to feed on the teeming mass of bugs we had been smelling from the first character Dev wrote.
I just lied, actually — I have had the pleasure of being on one good team. We were small and somewhat of a skunkworks, and we simply ignored the official process. I was involved in all of the design reviews, and Dev reviewed all of my tests. Dev wrote unit tests — sometimes with my help, but much of the time they managed to do pretty good on their own — and checked these tests in alongside the code they tested. Before the version control system had completed the checkin transaction I had the new code synched and built and was putting it through its paces. As good as this was, though, there was still a handoff, albeit a very informal one.
And still I lie, because my current team is pretty good as well. We’re making a concerted effort to push testing upstream and blur the lines between Test and Dev and PM. The entire feature team reviews both the feature spec and the test spec. The more senior testers attend the Dev design reviews. Dev and Test both use the same tools and frameworks to automate our tests, and so Dev and Test both review and help build those tools and frameworks. Dev tests and Test tests live next to each other in version control. Even with all this goodness, however, there’s still a more-or-less formal handoff of features from Dev to Test.
I don’t think this is a question of methodology, either. Waterfall has clear handoffs between Dev and Test (between all disciplines, actually — analysts hand off to designers hand off to coders hand off to testers hand off to users hand off complaints that nothing does what they need it to do to their bosses), but even Extreme Programming makes a clear distinction between Test — who help the customer write the acceptance tests — and Dev, who writes code until the acceptance tests pass.
The only way to completely eliminate a handoff between Dev and Test would be for the developer and the tester to pair program/test. This pairing could be very productive, but it might be counterproductive as well. Developers are famously unable to test their own code; this is because they know it too well and so “know” what can and can’t happen. (Yes, even testers who code. The second a tester picks up a keyboard and starts slinging code they become a developer, with blind spots and everything. Bizarre but true.) If the tester knows a piece of code just as intimately as the developer does, the tester will likely develop the same blind spots the developer has. This would be a Very Bad Thing.
Perhaps a certain amount of handoff isn’t actually a bad thing. If the entire feature team is involved throughout the product cycle, and everybody hands things off in lots of small chunks to everybody else (PM gives Dev and Test many small chunks of spec, Test gives PM and Dev many small chunks of tests for that functionality, and Dev gives PM and Test many small chunks of implemented functionality), that might be a good compromise along the various axes of optimization. Exactly where this line between not enough handoffs and too many handoffs lies, though, I haven’t figured out yet. Be sure to let me know if you have. <g/>
*** Comments, questions, feedback? Or just want a fun job on a great team? </g> Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. I need testers, and my team needs a data binding developer, program managers, and a product manager. Great coding skills required for all positions.