thefrugalprogrammer

Everyone wants QA early, and let me assure you developers do too. Many agile gurus simply repeat the mantra -- QA early and often -- but provide no tactical guidance. The question is: how do you accomplish it without massive overhead? Here's my take on agile QA; take what works for you.

The problem starts small: Let's bring QA up front early, and they get brought on to an early and unstable release. QA moves through the system, hitting roadblocks and documenting them. Development is rapidly swamped with a growing number of trouble tickets that have to be read, evaluated, reproduced, and then fixing them.

When QA is normally engaged, closer to launch, this is a Good Thing. But what happens is a game of Ticket Kismet as tickets' comment lists grow and they are passed back and forth between QA and the dev team.

In my opinion there are two key pieces that can help us tactically get QA up and running early.

The bare minimum has to be done early. This may seem obvious, but developers and UI people need to get broad early, not deep. The initial 'breadth checkpoints' should be the bare minimum to getting your system up and running; with these completed, QA can come in and begin documenting problems.

And there should be lots of them. But the dev team needs to ignore them.

Now the second part: Development needs to, at this point, keep track of their own task lists and not pay any real attention to the growing list QA is developing until 'reconciliation' (which I'll get to in a minute). Is this duplication? Probably. But it keeps the dev team from getting rutted in the quagmire of going back over what are probably known issues that QA is documenting. If QA discovers that something in the breadth checklist is not done, it should be brought to development immediately -- something was missed. Otherwise, Development needs to go deep and flesh out the remaining components.

As deep components are completed, they, too, should be handed to QA. At this point, most of what is in the QA bug list should be relatively minor. Some of it will be resolved by the developer going deep on the component. I like to reconcile early; some may want QA to take another pass before reconciling. In either case, reconciliation involves both the QA people and the developer(s) in the same room, with QA driving via a shared screen, and going over the list. Those issues that are small enough should be fixed immediately (I usually gauge it at under 5 minutes). Yes. Right there with everyone in the room.

The goal is to remove the overhead of bug reproduction at this point in the process. Not everything will be fixed in reconciliation, but a fair amount should be knocked out. Reconciliation itself should happen early and often, because it shows that deep issues are being resolved and the bug backlog itself is legit, fully integrating what is known by both the dev team and the QA team.