Pesquería de la Corvina rubia en la región del RDP

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.

Dunn (1984) and Freedman & Weinberg (1982) list many other possible design errors and provide extensive checklists for evaluating a design document. Read Beizer (1990) on design testability.

R

The objective for any review meeting is to identify problems with the design. It is not to solve them. Review meetings should be small (about seven people). They should include people who did not work on the design. Reviewers should read design documents in advance and challenge or question them in the meeting. Many companies don't consider a design complete until it is approved in a formal review. A design is reworked and re-reviewed until it is finally abandoned or accepted. Three common types of review meetings are walkthroughs, inspections, and technical reviews:

• Walkthrough: The designer simulates the program. She shows, step by step, what the program will do with test data supplied by the reviewers. The simulation shows how different pieces of the system interact and can expose awkwardness, redundancy, and many missed details.

42

TESTING DURING THE DESIGN STAGES REVIEW MEETINGS

• Inspection: Reviewers check every line of the design against each item in a checklist. An inspection might focus on error handling, conformity with standards, or some other single, tightly defined area. If time permits, an inspection checklist might cover a second area of concern.

• Technical review: Reviewers bring a list of issues to the meeting. During the meeting, they describe their objections and point out things that are ambiguous or confusing. The purpose of the review is to generate a list of problems and make sure that the designer understands each one. Deciding what changes to make, and designing them, are not part of this meeting.

The ideal review meeting is administered by a meeting manager (or facilitator) and a recorder. Neither comments on the design. The meeting manager runs the meeting. This includes finding the room, recogniz- ing speakers, stopping interruptions, keeping the discussion focused, and preparing a summary report. It is the meeting manager's job to make sure that the meeting does not bog down into discussions of possible solutions of particular problems. These must be done later, by a smaller group, outside the meeting.

The recorder writes all significant comments on flip chart sheets, transparencies, or other surfaces that can be kept and that everyone in the room can see. Anyone who thinks the recorder has missed something important can ask her to put this on the record. The record includes every agreement. When an issue is left open for later discussion, the record should list the questions that must be answered next time (if these have been identified). This process can yield much more productive meetings, especially when the design is controversial.

Some Testing Groups train their staff to be meeting managers and recorders for design reviews. This is a valuable service: few software development companies have access to meeting managers or recorders, and their review meetings (if there are review meetings) aren't always very satisfying. To learn more about meeting management techniques, read Doyle & Straus (1976). For excellently written applications of these techniques to review meetings, read Freedman & Weinberg (1982) and Gause & Weinberg (1989).

P

Pseudocode (structured English) is an artificial language that combines coding language constructs with

English (or another natural language). For example, the following description, from Chapter 1, is pseudocode:

IF ASCII_CODE_OF_ENTERED_CHAR is less than 48 THEN reject it

ELSE IF ASCII_CODE_OF_ENTERED_CHAR is greater than 57 THEN reject it ELSE i t ' s a digit, so accept it

As designers develop more detailed documents, they find it convenient to describe the design in a language almost as formal as a programming language, with many of the same constructs. Many designers find pseudocode natural for this.

43