This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: Should Agile developers test their own software?
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
James Bach writes here about whether programmers should test their work extensively before delivering it to testers.
His conclusion:
Many testers would advise the programmer to test the product himself, first. I have a different answer. My answer is: send me the product the moment it exists. I want avoid creating barriers between testing and programming. I worry that anything that may cause the programmers to avoid working with me is toxic to rapid, excellent testing.
He goes on to indicate that he has no problem with programmer testing, and in fact considers it to be a good thing. But that if it contributes to a wall between developer and tester, then he'd rather just have the code now, please.
A common theme has emerged recently in the Agile world, where I've seen a lot of questionable enthusiasm for doing away with dedicated testers, and having the developers write all of the tests.
I believe in unit tests, especially the automated kind, but acceptance testing is a trickier proposition. Having worked for over 15 years with both developers and testers, I can say unequivocally that a good tester can test circles around a good developer.
So why would we want to throw away the talents and viewpoint of a great tester under the guise of automation or agility?
Well, in an Agile process, fast feedback is important, and the more hoops that need to be jumped through to release software, the harder it is to get that feedback. A dedicated testing team is just another obstacle to overcome on the way to a release, right?
Or is it?
What if dedicated testers weren't a hoop to jump through, but rather a valuable feedback source? What if you could not only find and eliminate more defects, but also find under-specified areas of the software, and be able to anticipate customer needs sooner?
A good QA/testing team can help you do these things.
Does this mean that developers should stop creating unit tests? Of course not. The better the input, the cleaner the output will be. Unit testing (along with Test-driven Development) is an internal quality practice that makes code easier to maintain.
But as for the final acceptance testing and other areas that are difficult to automate, I for one welcome the opportunity to work with talented testers who can help make my software better.
Previous Topic
