What does QA Mean on Agile Teams?

I have struggled with getting traditional QA professionals to work effectively with agile teams. Testers are frustrated because there is scant coverage of “tester” practices in much of the agile literature. For instance, the XP bill of rights covers the rights of the customers and the developers. Testers don’t even get a mention.

I think this stems from an emphasis within agile processes on test-driven design and automated acceptance tests. Done well, these practices result in much higher software quality. Agile developers then question the value of “monkey” manual tests which are often covering the same ground as the developer and customer facing tests that are already passing. Now, to be fair, there certainly is information out there on the role of agile testers such as work done by Lisa Crispin, Janet Gregory, Brian Marick, Jonathan Kohl and Michael Bolton to name a few.

And there are groups and forums out there such as the agile-testers Yahoo group. Michael Bolton recently posted that perhaps the confusion arises from what we mean by QA:

One important step is to stop thinking about testers as “QA” — unless the A stands for “assistance” or even “analysis”, but not “assurance”. We’re testers. Management (in one sense) and the whole team (in another) provide the “assurance” bit, but since we don’t have control over schedule, budget, staffing, project scope, contractual obligations, customer relations, etc., etc., we can’t assure anything. We should be here to help — not to slow the project down, but to aid in the discovery of things that will threaten value.

I think Michael has it right. In a private email he provided a great distinction between a developer’s and a tester’s perspective:

In the developer’s world, the job is to create value. In the tester’s world, the job is to defend value by looking and seeing where it might be missing. The developer’s job is to discover how it can work. The tester’s job is to discover how it might fail — and by disproving a failure hypothesis, getting one more piece of evidence but never certainty that it will work under these sets of assumptions — ‘cos the assumptions are never sure things.

I couldn’t agree more. I see the role of a tester then as supporting quality infusion into agile teams.

Delivering Better Software

Hi, I am a software developer and agile coach. And this is the start of my blog on delivering better software.

Delivering working software is crucial. Many teams worry about their methodology or eliciting better requirements or designing higher quality and so on. These are all important but they are secondary to actually delivering systems that meet stakeholder needs. So the focus for great teams must be to deliver, deliver, deliver.

Better Software is about making software better today than it was yesterday. Better software is made with small incremental changes that compound over time. It takes great teams to make better software. So another focus for great teams must be on continual learning, reflection and improvement.