The Role of QA in an Agile Development Project

An interesting question in Agile Development is “how do you incorporate QA?” I guess that all depends on what you see as the role of QA. For instance, if you have your QA people involved from start to finish, then you really wouldn't have to change a thing. For instance, a QA person can:

• help to determine if your stories are well defined
• suggest adding stories related to testability
• make sure that people are creating good unit tests and/or write unit tests
• increase your code coverage by adding more automated tests
• write tests for stories before (test first) or after they are completed
• organize usability testing
• add stories for improving usability
• do exploratory testing on early builds
• verify the completion of stories as they are completed

If they are involved from start to finish in this manner, then you eliminate the need for a well-defined QA stage. If you find at the end of an iteration that QA is "falling behind" then it could be argued that your ratio of development to QA is off. If so, then you can either add more QA resources or have developers take on some portion of the above tasks to restore the balance.

For AccuWorkflow, I had the partial use of multiple QA resources over time, so I had a "virtual QA person" which was different people at different times including developers doing the various tasks I mentioned.

With short iterations, it is likely that there will still be some touch-up work to be done on the previous iteration when the next one starts. Perhaps QA has not finished evaluating the iteration, or perhaps somebody wants to do a demo but runs into a bug that needs to be fixed first.

We were doing variable length iterations where the iterations were between 2 days and a week, so we ran into this hand-off period on a regular basis. The way we handled it was to create a stream for the “hand-off” period.

As an iteration ended, we created a new stream based on the existing development stream. Depending on the SCM system you are using that probably translates to either creating a branch or a label. In any case, the new stream then represented a stable version of the “previous iteration.” If somebody needed to do a little follow-on work, for instance to get things ready for a demo, they used another configuration called “demo” based on the “previous iteration” stream. To prepare for the demo they made changes in the demo stream without affecting the previous iteration or the current one. Once they finished the demo they then merged any changes into the current stream.

Having streams representing multiple iterations also made it possible to easily find out what had changed between iterations which aided in tracking down problems.

Of course, there are all of the standard things that a good QA organization brings that operate at a higher level than stories, but I'll just take those for granted for the purpose of this post.

Next: The Role of QA in an Agile Development Project Part II