Q&A Testing in an Agile Environment
Q&A Testing in an Agile Environment
Join the DZone community and get the full member experience.Join For Free
Discover how you can take agile development to the next level with low-code.
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:
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
Opinions expressed by DZone contributors are their own.