In order to deliver production-ready code at the end of every iteration, the iterative quality assurance approach relies on robust definitions of acceptance criteria for each story card and automated testing to unearth and fix bugs early in the process.
Each story card should describe both unit tests and the specific portion of the overall test plan to which it pertains.
Adequate testing coverage is important. It is useful to maintain a re-usable test plan throughout the project development life cycle, regardless of the project management methodology employed. With ITS Iterative, story cards are the natural input to the test plan. In other words, unit tests of specific objects or features can and should be included in the story card description. These smaller unit tests can also be used as inputs to the overarching reusable test plan. The test plan will thus reflect a change whenever a new feature or piece of functionality is introduced into or removed from the codebase.
A story card needs to detail, as much as possible, the specific portion of the test plan to which it pertains. It is not necessary, however, to refer back to individual story cards from within the test plan.
The content of QA tools and techniques is essentially the same for both ITS Iterative and waterfall development environments. The difference, as noted above, is at what point in the project life cycle they are used. It is still useful, however, to follow the ITS Software Development Life Cycle (SDLC) methodology when developing test scripts or creating test data in either environment.