Wednesday, April 25, 2007

Where does QA fit within Agile?

Like many development shops that have been around doing Traditional Waterfall development over the years, we have a separate department called Quality Assurance. This team consisted of non-developer types that focused primarily with ensuring quality of the product through testing activities. In our case, because we have legacy products that have been developed in technologies that don't lend itself well toward test automation, these testing activities were largely done manually. Unlike the unit-level testing that was done by the developers, the QA team primarily focused on overall system testing. This included test verification of current requirements but also a fair amount of regression testing (again manually done) to ensure that
past functionality continued to work.

As with Waterfall development, QA was largely involved late in the process. Once developers felt their code was completed, they would "throw in over the wall" to QA for testing. QA would do their initial testing, and submit bugs for things not working. Until the overall product was stable enough to give to our customers (through several release cycles), it would go through several fix/build cycles. How long this would go was highly unpredictable, and therefore would cause much frustration if our initial test estimates were too far off.

A couple of years ago, I attended the local Northwest Software Quality Conference here in Portland, Oregon. This is an excellent conference and while anybody in the software industry can get something useful out of it, the primary audience are people involved in QA. As Agile started to heat up in the software industry, presentations started to show up in every conference. Given this audience however, very few had even heard much of Agile and for those that did, weren't using Agile practices. Why? Because Agile assumed (at least at that time) that the testing role and other QA activities were just another hat that developers wore. So for those that had heard of Agile, they were resistant because they feared their jobs in the long run.

I was seeing that same reaction from my own QA group, and was dealing with how to best transition that group into a valuable role of an Agile team. After many sessions with both developers and QA, I started to see the light of how QA could fill some holes that the teams were having. So, here's how QA will look in our organization:

1) QA integrated into every team - Each member of the QA team is now co-located with the Development instead of being in a separate department.

2) QA plays Testing Manager role - QA is responsible for helping the team identify how we know when a story or task is "done". They define done by developing tests with the team that ANYBODY can run including the QA person. They also determine how best to implement that test (manual or automated, which tools, etc.)

3) QA plays Process Improvement Manager role - QA is now going to lead retrospectives at the end of iterations and releases with the team. They will ensure that there is just enough process for the team to ensure quality but not too much that the team doesn't see value in the process. They are also to ensure that all action items from the retrospective get reflected in the work in future iterations and releases.

With these three implementations, we hope to build more quality into the entire process and ensure quality earlier and often in the process. While anybody can wear the Tester hat, now QA has a much broader role in ensuring quality beyond just testing.

2 comments:

Unknown said...

Skip, the mantra you should be striving for is "QA's role is to prevent defects, rather than finding defects." Defects are waste, which is clearly something to be eliminated as a lean principle. When you think about it in this way, what other changes would you make? At Net Objectives we like to say that QA has to be moved up in the process. Test-driven development, and QA writing acceptance tests prior to coding being started, are just two things that help.

If you are embedding QA members with the team, then you still have the issue of how they function. If they are part of the team but still do all their work after things have been coded, then you have created a mini-waterfall situation. It would be much better to have the QA person work with the developer at the start of work to determine the acceptance tests. By working together, both end up with an understanding of what is actually being implemented.

Skip Angel said...

Bob, I totally agree with you. I am position QA to encourage the entire team to be responsible in building in quality at every opportunity. The earlier the better.

In the past, throwing code "over the wall' to QA late in the process was painful. I have learned with Lean that this is also waste but much code had to be improved in order to finally be stable enough.

Fixing bugs is Waste; Prevent defects as much as possible is Value. Why? Preventing defects allows you to deliver faster because you are spending less time in prevention than bug fixing/stabilization practices.