This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: Is QA Redundant for Agile Software Projects?
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
A recent topic on The Server Side forum discusses the role of QA on agile software projects. Apparently a talk by Scott Ambler ruffled a few feathers in the testing community.
The basic argument given in the discussion is that QA is irrelevant on agile projects, since each iteration is a smaller increment of functionality and therefore easier to test. Developers do testing in the form of automated unit and acceptance tests, which guarantees quality moving forward.
Complete and utter nonsense.
The primary role of QA is to provide information to the business on the state of software. This means having an objective view first and foremost, and being able to back up that view with repeatable tests that exercise the software in it's intended context.
I've developed software for many years, and led software teams for nearly as long. We were rarely objective about the state of the software, try as we might. Now, sometimes that meant we thought the software was in bad shape, and sometimes the opposite, but it's very difficult to be independent reviewer and a creator at the same time.
Agile methods do help by making the increments smaller, so that there is less to obsess about and less to test, but the objectivity problem remains. This role is given to the customer in agile projects.
Inevitably, though, customers (who frequently have real jobs other than handholding the development team), have difficulty writing exhaustive acceptance tests and doing complete reviews of the software until it's in production. And of course, for commercial software, the role of the customer is played by a product manager or a marketing group. While they can provide guidance, again, they aren't trained to consider every possible exceptional scenario.
QA teams, then, are the last resort for most projects (whether we consider them to be part of the customer role or not). Certainly there are bad QA teams (or possibly just badly managed), but calling all QA activities irrelevant is just short-sighted.
There are several good resources on how to better integrate QA into the development team on agile projects, including Brian Marick's website, and Lisa Crispin's book. Do today's testers need to step up a bit to work with agile methods? Certainly. But let's not throw the baby out with the bathwater.
Previous Topic
