It seems to me the value added by a specialized QA test group that tests an application after-the-fact is that they can test the application as a whole in ways the development team is not equipped to do. This may include a wide range of testing, such as performance testing, break testing (finding the load limit of the application, useful for capacity planning purposes), testing the application in the context of a shared execution environment with other applications active, various forms of stress testing, longevity testing, failover testing, and more.

Since traditional software development methods typically deliver very buggy code, in many cases the QA test group uses up its portion of the project schedule in testing basic functionality. They aren’t given a runnable application to begin with, and so they can’t perform the kinds of testing that really add value.

From this point of view, one of the advantages of agile development methods is that the development team will deliver relatively bug-free code to the QA test group. Assuming the team has properly applied agile development methods, the basic functionality of the code are already tested before the product is handed over to the QA test group for dedicated, after-the-fact testing. This frees the QA test group to concentrate on the kinds of testing that really add value, instead of just trying to get the code to run.

A troubling trend I’ve seen are process QA folks moving from policing traditional processes to calling themselves “Agile Testers” and policing Agile teams. This post is a good reminder to be aware of that, and to listen to the symptoms of process problems.

I’m also glad you have identified some of the narrow thinking about software testing that some Agilists have perpetuated. At worst it prevents skilled testers from being able to contribute on collaborative teams, and often encourages predictive, clerical testing under a BA, customer or programmer role. Your work is an antidote to that kind of thinking.

-Jonathan