Design Phase Testing

TESTING DURING THE DESIGN STAGES

No code has been written yet, so we're still testing ideas. These ideas are more formally expressed and more detailed than the original plans. Examining the design documents, reviewers should develop a clear picture of how the system will work if it's built according to the design. Testers may not be included in these reviews, but they will be valuable for your test planning, so try to find time for them. (But don't speak in review meetings unless you have something valuable to say.) The reviewers should explore the following issues:

• Is the design good? Will it lead to an efficient, compact, testable, maintainable, product?

• Does the design meet the requirements? If the planning documents are informal, changeable, and ambiguous, the design will be the first formal statement of the product requirements. Management and marketing staff should review the design as such, not just as a design.

• Is the design complete? Does it specify all relationships between modules, how they pass data, what happens in exceptional circumstances, what starting state should be assumed for each module, and how that state will be guaranteed?

• Is the design possible? Can the machine run this quickly? Is there enough memory? Are there enough I/O devices? Can data be retrieved this quickly from a database? Can this version of the development language do the things you're trying to do?

• How well does the design cover error handling? Especially when doing top-down design, it's easy to think of error paths as "details," to be dealt with "later." All too often, by the time "later" rolls around, these "details" have been forgotten. Along with checking that all remotely plausible error conditions are dealt with in the design, it is also important to ask whether a given error is handled at the right level. For example, if an error detected in one module forces backtracking and cancellation or correction of work done in other(s), the error should probably be handled in the higher-level module that calls all the affected modules.