Agile Zone is brought to you in partnership with:

Chris Spagnuolo has been working in the Geographic Information Systems (GIS) field for nearly 15 years. If it involves GIS, he's probably done it...everything from field data collection to large scale enterprise GIS deployments. Through this experience, he has reached the conclusion that the most effective way to deliver value is by the implementation of agile practices. He believes strongly in the effectiveness of agile practices and he is leading a new group to evangelize the benefits of agile. Chris is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. You can read more from them at their website. View Full User Profile

Q&A Testing in an Agile Environment

11.05.2008
| 4725 views |
  • submit to reddit

In the past few weeks I’ve been asked about and have been considering exactly how to fit QA and testing into a two week iteration. A primary concern of the folks I’ve been talking with is that QA’s and testers on an agile team have nothing to do at the start of an iteration.

The second concern is that we can’t keep writing new code up until the last minute of an iteration if QA is to adequately test the code, and as such, what do the developers do at the end of the iteration. Of course, the underlying concern in both of these cases is keeping the QA’s and the devlopers effectively utilized during an iteration. Software quality always seems to boil down to a utilization/cost equation doesn’t it? Well, after giving it some thought, I think I’ve come with a basic schedule for QA’s and developers over a two week iteration. Here’s the plan:

Slide1.jpg

So, let’s take a walk through the schedule. On the first two days of the iteration, the developers get busy coding the stories in their backlog while the QA’s start writing test cases/acceptance tests. The QA’s should also be running these tests against the existing code base. This validates that the test harness is working correctly and that the new tests do not mistakenly pass without requiring any new code. Obviously, the new tests should also fail for the expected reason. This tests the tests themselves, in the negative: it rules out the possibility that the new tests will always pass, and therefore be worthless. OK, so that’s day one and two.

Over the next five days, the QA’s begin testing any testable code that has been completed. At the same time, the developers continue coding and also start working on fixing any defects picked up in the testing. Pretty standard days. Code-test-fix.

OK, we’re deep into the iteration now. Days eight and nine see QA continuing to test all of the remaining code written during the iteration. Yes, ALL of the remaining code. At this point, the developers effectively stop writing “new” code and focus their energy on fixing all defects identified in testing. If the dev team has no defect work or find themselves with down-time while waiting for testing results, they can and should be helping the product owner develop and refine the user stories that are likely to be played in the next iteration. Additionally, developers can start considering the design aspects of the immediate upcoming stories and coordinating design decisions with the project architect.

Last day! Don’t start scrambling now, you’ve got a demo and review later today. So, on Friday, the developers focus on bashing any remaining defects and making the code bombproof. We’re shooting for zero defects here folks. The QA’s are spending most of their time doing some final acceptance testing (as is the product owner). That’s it. It’s noon and it’s time for your review and demo. You’ve tested and fixed everything so you and your team can demo with total confidence. No surprises for your team, you’ve built serious quality into your software!

So, there’s my idea for a basic schedule that completely integrates QA and testing into your iteration. Now, this is only one way I think QA can be integrated into an iteration. There are probably dozens of other ways to do this and I think ultimately, the way teams work QA into their iterations really needs to be assessed on a case-by-case basis. So, I’d like to pose the question to agile teams out there: How do you currently fit QA/testing into your iterations?

From Chris Spagnuolo's EdgeHopper - Tales From the Edge

Published at DZone with permission of Chris Spagnuolo, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Sindy Loreal replied on Sat, 2012/02/25 - 11:04am

Another approach is to break the QA and developer silos and create more diverse teams. Meaning, put one or more QA testers on a team of a few engineers. The definition of done becomes when the team completes the item including testing. This is simple but it works for me.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.