information, where it uses each, what it will output (print, save to disk, etc.) and when. It takes a lot of pages to describe these diagrams. Read Gane and Sarson (1979). For more detail (about 125 very readable pages) read De Marco (1979).
Decision tables and trees
A decision table shows the program's logic. Each entry in the table, shows Y (yes) or N (no) (or T or F). The program will do one thing or another. The table shows which it will do under what circumstances.
Figure 12.14 illustrates a decision table. The system will print two summary reports. The first lists all problems deferred this month (July). The second lists all problems deferred to date. For each Problem Report, the program has to decide whether to include it in either summary.
The top three rows of the table show the questions the program must ask to make the decision: • Did the programmer defer the problem? (If so, RESOLUTION CODE is 3.)
• Did the tester say Yes in the TREAT AS DEFERRED field? • Was the resolution entered in July?
The bottom two rows of the table show the decisions.
Note that Figure 12.14 includes every possible combination of Yes's and No's for these three conditions. Decision tables always show what the program will do under any combi- nation of relevant events. They always list all relevant events.
Any decision table can be redrawn as a decision tree. Many people initially understand decision trees more readily than decision tables. Figure 12.15 is a decision tree that shows the same information as Figure 12.14's decision table. For more examples of decision tables and trees, we recommend Gane and Sarson (1979).
196
Keyboard convention table
The keyboard convention table is quite large. Use a spreadsheet to make it. In the form we describe here, the table shows the program's response to each character, in each program state.
The keyboard convention table reveals inconsistencies in the user interface (e.g., Fl means different things at different places in the program). Some inconsistencies are there by design (or by lack of design); others are coding errors. In creating the table you'll also discover undocumented behavior including half -finished discarded ideas (oops, crash), back doors into the debugger, strange messages, exotic animated image sequences, and once-planned features that the development team decided to drop but someone coded them and tossed them in anyway without telling anyone.
Each row in this table is devoted to a single character. A, a, B, b, *, &, -, ii, and • are all individual characters. So are <Alt-A>, <Ccnmand-D>, <Option-B>, <Open-Amiga-C>, <F1>, <Ctrl-Shift-Fl>, and the various dead keys on non-English keyboards.
The first column in the table lists the individual characters (one per line). Succeeding columns list the effects of entering the characters in the various states, dialog boxes, and entry screens of the program. For example, at a data entry screen, if you press A, the computer will echo the A in the appropriate field on the screen. On the row for A, in the column for this screen, enter an A. Now suppose that at error message boxes, the computer requires you to press <Escape> to continue. It ignores all other characters at the message box. On the row for A, in the column for error messages, enter Ignored
In practice, you will condense the keyboard table by grouping equivalent keys together. For example, you might group together all lowercase letters. You have to exercise judgment when you condense the keyboard table; your results will vary across programs and operating systems. Even after condensing the table, though, it is big—you (and the program's spec writer) will reserve rows for many groups and for many individual special characters. We describe some keyboard groupings later in this chapter, in "Components of test planning documents: Matrices: Error message and keyboard matrix."
It takes a few days to create this chart. After you've made it, print it out, mark the inconsistencies with a highlighter, perhaps suggest effective ways to use unused function or command keys, and pass your work to the project manager. If this work is done reasonably early, it often results in a signficant user interface cleanup.
198
Printer compatibility table
There are over 1000 printers on the market, and most of them emulate (work just like) other printers. If 50 printers all emulate the Hewlett Packard LaserJet II, don't test all 50 printers.
We've found it useful to create charts, along the lines of Figure 12.16, that show what printers are compatible with what others. (You can create similar charts for other devices but here, as in Chapter 8, we'll stick with printers as our model device.) Formats vary widely. All charts contain some of the following columns:
• Printer: make and model.
• Mode: some printers can be set in their own native mode, or to emulate a few other, different, printers. • Compatibility: make and model of the printer this one emulates.
• Source: how do you know this printer emulates that one? Name the magazine article, the person, the advertisement. Some reports are much more trustworthy than others.
• Tested: indicate whether your lab has tested this printer's compatibility and what test was used. Have you confirmed graphic mode compatibility? Escape sequence command compat
ibility? Character set compatibility?
• Notes: list incompatibilities, doubts, customer reports, etc.
Boundary Chart
See "Equivalence classes and boundary values" in Chapter 7 for a detailed discussion of equivalence class and boundary chart development. Figure 12.17 illustrates a boundary analysis of some of the input variables used in the Problem tracking system.
Don't expect to complete this chart early in testing. It takes a long time to do this chart well. Start by listing every input field (use the input variable list if you made one). Identify their functions. Assign limit values and further information as you learn more, but let yourself experiment with the variables from a full list from as early a time as you can.
OUTLINES—THE FUNCTION LIST
Function lists outline what the program can do. They express your organization of the program's functions. Organize them in a way that you'll find convenient for testing and test planning. We use a function list as the core of our notes.
You can develop these lists to almost any level of completeness and detail. We suggest an incremental approach. Start simple; add detail as you go. Figure 12.18 summarizes our approach.
You' 11 find it much easier and faster to add items and reorganize the list if you use an outline processor, rather
than a word processor. /
Figure 12.8 shows a basic, first draft, top-level list of the problem tracking system's functions. It shows everything the program is supposed to do. This first step toward a more thorough outline is valuable in its own right. Keep a copy at your desk while testing the program; check it as you go to make sure that you've tested each function on the list. You can summarize the stability of different parts of the program by highlighting working functions in one color and failing ones in another.