Tuesday, May 15, 2007

The Role of QA in an Agile Development Project II

At a high level, you should work to keep the ratio of development to QA balanced. The ratio will vary from project to project, so I'm not commenting on that, but once you have a ratio there are several ways to maintain it. In an Agile project, you may quickly find out that the ratio itself is off and need to adjust the ratio. In a project with long iterations, you might not find out that the ratio is out of whack until it is "too late."

In any case, once you find that you are short of QA resources, there are a couple of options. The first option of course is to get more QA resources. Failing that, you can use development resources. It may also be that you have a short-term need for more QA and in that case using development resources might be exactly the right short-term solution.

I think a common rule of thumb, which especially applies in the context of compliance, is that different people do the development and testing of a particular requirement. That is, if Sue is responsible for issue 12345, then Sue doesn't do the testing of it.

As to the exact use of development resources, I advocate that developers take on a sub-set of QA activities, thus allowing for better leveraging of the existing QA resources. For instance, creating automated unit tests or the general generation of automated test cases.

You can of course set whatever policy makes sense for your organization. Having people only write test cases for other people's code is always a good idea. Beyond that, I would assume that QA would take what the developers had done as a starting point, supplementing with additional tests, reviewing what the developers had done, running the official test cycle according to the test plan and reporting on the results.



Next: Multi Stage Continuous Integration

4 comments:

Tammy Coombs said...

We have use the scrum process for about 6 months and I feel we are still practicing mini waterfalls. I really need help to defining the role of QA from start to finish. Are we suppose to write test plans? While we are waiting for development, we are unable to write test cases because the specs are not fully define and items that are being added are changing. In the end, we have the product not fully testing and catching up with the next sprint. No test cases are done and no automation is done. Seems like it is what we were doing before.

Kelly Waters said...

Hi,

I wrote a post on my blog where I comment on the role of QA in an agile development where there is a shortage of QA people...

http://kw-agiledevelopment.blogspot.com/2007/03/developers-cant-test-for-toffee.html

Kelly Waters
http://www.allaboutagile.com

Unknown said...

Hi,
Could anyone please let me know how an agile test plan needs to be prepared. What all points need to be taken into account. If anyone has prior experience working in an agile project then do let me know, how testing is planed for first phase of development?

Anonymous said...

I know this is an older post, but for posterity...

QA (as in assuring quality - not just product testing) has to approached in a fresh way on an Agile project. Quality either happens or doesn't happen with the people, process and THEN product. Therefore the role of QA becomes more of a support role than a phase or department of "quality crusaders".

To my projects that means that QA works very closely with the Product Owners to flesh out risks and dependencies at release and sprint planning. We also preview acceptance criteria and are even involved as scrum masters sometimes to remove blockers and offering analysis on fixes. We've also made an effort to "inspect and adapt" our testing in the same way as the project is being developed. This means more appropriate, timely and purposeful test plans that match current iteration expectations or "pruned" regression plans. No more "testing like hell". (The test version of TDD's fight against "program like hell")

No doubt it takes a strong QA'er to be able to wear these multiple new hats. Furthermore, you need to have development and QA management bought into this idea of quality being built into the game from the ground up. But it's well worth it.