As designs are updated and expanded (or even reduced) during the development process, it is important for quality assurance efforts to keep pace. Not only do the intended changes to the code base need to be properly tested as a design iterates, QA additionally is needed to ensure that no new bugs are introduced as the result of these changes.
Generally, iterative QA does not need to be broad in scope, but it does need to touch on the following major areas:
The intended changes need to be tested thoroughly.
- Does everything work as designed?
- Are edge cases handled properly?
- Does the design itself work well, or are there areas that may confuse users?
Some compatibility testing of the changed areas may also be necessary, especially if new technology is incorporated or the changes are particularly major. The bulk of QA should be aimed at the areas that are being directly changed or that incorporate data and features that are being changed.
The overall application needs to be smoke tested.
All major features should be reviewed to ensure that nothing unintended has been introduced. Functionality should be exercised in an intended manner, although edge cases can usually be skipped without introducing too much risk during smoke testing.
- Care should be taken to look at minor details that may appear in multiple locations, such as updates to copyright dates of TOS text.
This is also an opportunity to catch a few issues that may have been overlooked in previous test cycles (There’s always another bug. Always.). Smoke testing often benefits from the use of a simplified set of test cases or a checklist to keep things on track.
It is important not to overlook the need for ongoing testing while making iterative updates to an application. Even months of relatively minor updates add risk if they are not subject to careful testing, and major updates, of course, always need to be properly QA’d before deployment.
While it is tempting to see an existing application as having already been ‘thoroughly tested’, this view is dangerous, and can frequently lead to preventable issues being discovered by clients or customers, rather than by developers and testers.