I have been catching up on reading some blog posts and came across a couple at Damon Poole’s site that cover exactly what I have been pondering in the last week. (see the posts Part 1 and Part 2). Namely, how the heck should QA function when you are following an Agile development methodology. In the last project at work, we adopted an Agilefall approach midstream where the requirements were first “baked” and then dev set out implementing the requirements in a iterative fashion. A short QA cycle following the three dev cycle occurred. QA became most engaged after feature development ended. They would execute manual/automated tests and report bugs. Fixes for the bugs would surface in the next interation.

Of course, as anyone who has built software knows, requirements are never “baked”. This is not the fault of the requirement gatherers, the end users, QA, or Dev. Just like you can bet on the sun rising every morning, you can rest assured that requirements will always change. The question is, how do you handle it? Waterfall dictates you need change control to control/prioritize/approve the changes. From what I know about Agile (I have only been looking into it for the last 9 months), you get around the changing requirements by embracing the fact that they change. A small, cross functional group work very closely together to build the features and release.

For Dev and QA, this approach can be a tad unsettling if the Waterfall approach was used when they “cut their teeth” earlier in their careers. To get the most out of QA in an Agile shop, they should be engaged tightly with Dev from Day 1. Damon lists some great ways for this to be accomplished. Examples include having QA check the quality and coverage of the unit/integration tests. This alone would have gone a long way to helping our product achieve high levels of quality earlier. In addition, QA can work to build automated tests as well to test specific areas.

In the tail end of the project I mentioned above, we started to adopt some of these ideas. Two developers and a QA person teamed up to tackle a complex, brittle area of the system. They looked to find issues that fell into the categories of “it blows up when you do this”, “it works but could work better this way”, “this is missing”, etc. Close, daily contact on this small team led to rapid improvement in the quality of that area of the system and it engaged QA in a positive manner. It came close to fulfilling the idea of involving QA from the start.

As we move into a lessons learned phase for this project that goes live tomorrow, this relationship between QA and Dev will most likely help drive how we approach feature development in the future.