The Pacific Northwest AYE Community members gathered on 3/6/2005 in Seattle. The group, split between developers and testers discussed the recent phenomenon of using developers to do testing.
It Only Makes Sense
After all, developers have always done some testing.
- Does the code compile?
- Does the project still build?
- Does the new code do what it should?
Great! What’s next on the list of things to do?
Agile methods promote test driven development. The testing plan gets written before the code does. Management is simply proposing the logical result. Fire the testers since the developers are now doing the testing! But does this really make sense?
You Mean There’s More To Testing?
Yes, Virginia, there’s more to testing. I’m a developer, not a tester. I know only a little bit about testing, but I DO know that testing methodologies move just about as fast as development methodologies do. It’s no longer just about white boxes and black boxes. Check out Quardev and Satisfice for some great ideas in testing. Developers are lucky if they have the resources (time and training) to stay current with new development concepts. What are the odds management will think to include resources for learning how to test?
The View From Over Here
Another point to consider: Developers and testers have different local and global view points. The goal of development is to create and prove software works. Testing tries to discover those conditions where the software doesn’t work. Two very different ways of looking at the software. Shannon Severance does both developing and testing, but never on the same project. Once you get a particular view point on a piece of software, it’s hard to switch to another viewpoint. The difference in view points leads to better software.
Slip Sliding Away
Given that developers like to develop, not test, how does having developers do testing impact testing time? A quick review of the most project dynamics indicates that everthing can slip as far as delivery except the final ship date. Software development requires discovering what features should be coded, figuring out how to code them, coding them, testing the code and delivering the software. Testing time gets compressed in most projects to the time left (if any) after the major development is completed and the scheduled delivery date. With developers doing the testing, time (if any) will naturally shift to development to squeeze in “one more feature.” After all, “I’ve been testing as I go along.”
A Tester, By Any Other Name
Any significant software project involves multiple development teams. Who tests the overall results? Designate a developer to handle this release’s integration testing? Doesn’t that make them a defacto tester? And an unhappy one at that. Developers don’t have the mindset, training, and knowledge to do a good testing job. Why force this on them? Good software needs multiple viewpoints (after all, pair programming is basically instantaneous code reviews). Why not get the view point of some one who wants to do the job?
Let’s Think About This Some More
Firing the testers and using developers to test is a Siren’s song. Do it long enough, and you’ll hear sirens again as the software crashes and burns on your former customers’ computers.