Coordinación

to distinguish between equivalence classes for valid and invalid inputs. We think it's easier to evaluate the coverage of invalid equivalence classes.

Unfortunately, these tables are often bulky. There are often many more columns than in Figure 7.1, there to reflect interactions between different pieces of data, expand an event into sub -events ("Enter a name" might break down into "Enter the first letter" and "Enter the rest of the name"), or expand an equivalence class into subclasses.

You can start with big charts for rough work, then make final drafts with three columns by using a new line for every variation on the same theme. However, this hides much of the thinking that went into the chart. All the logical interrelationships that were so interesting in the wide table are no longer apparent.

One of us makes these charts on large desk pads or flipchart paper, then tapes them on the wall for future reference. It's hard to add new lines to these handwritten tables, and it's hard to photocopy them. Spreadsheet programs are a good alternative. Tape the printouts of the spreadsheet together to make your wallchart.

We also make outlines at the computer. Good outline processing programs make it easy to add to, change, reorganize, reformat, and print the outline. (Mediocre outliners don't make reorganization so easy. Don't give up; try a different one.)

We break conditions and classes down much more finely when we use an outline processor. We've shown this in Figure 7.2. This is usually (but not always) a good thing. However, we also repeat things more often with an outline processor and the initial outline organization is often not as good as the organization of the tables^

We don't recommend one approach over the other. Both are quite powerful.

This outline also illustrates a practical problem. Look at outline section 1.2.5.2 dealing with arithmetic operators. Conceptually "arithmetic operators" is an equivalence class of its own and the programmer might in fact treat this group ay an equivalence class by testing inputs against a list of every arithmetic operator. Now consider 1.2.5.3.1 and 1.2.5.3.2. These also include all the arithmetic operators.

How should you deal with overlapping equivalence classes? You don't know how the programmer checks these inputs, and it probably changes from variable to variable, so there's no reliable rule based on what the programmer is "really" doing.

The simplest way is often best. A note on your chart that points out the overlap will steer a tester away from repeating the same tests. Don't drive yourself crazy trying to figure out elegant ways to define non-overlapping equivalence classes.

Look for ranges of numbers

Every time you find a range (like 1-99), you've found several equivalence classes. There

are usually three invalid equivalence classes: everything below the smallest number in the range, everything above the largest number, and non-numbers.

Sometimes one of these classes disappears. Perhaps no number is too large. Make sure that the class is gone. Try outrageously large numbers and see what happens.

Also, look for multiple ranges (like tax brackets). Each subrange is an equivalence class. There is an invalid class below the bottom of the lowest range and another above the top of the highest range.

132

Look for membership In a group

If an input must belong to a group, one equivalence class includes all members of the group. Another includes everything else. It might be possible to subdivide both classes further.

For example, if you have to enter the name of a country, the valid equivalence class includes all countries' names. The invalid class includes all inputs that aren't country names.

But what of abbreviations, almost correct spellings, native language spellings, or names that are now out of date but were country names? Should you test these separately? The odds are good that the specification won't anticipate all of these issues, and that you'll find errors in test cases like these.

While you enter the name, the program might scan characters. The first character must belong to one of two groups: capital letters or lowercase letters. These are the valid equivalence classes. All non-letters are in the invalid equivalence class. These can in turn be subcategorized, as in Figure 7.2. (Note: A more complete chart would also consider accented letters. This is lots of fun because different language groups use different character sets, with different accented letters and different codes for some of the same letters. )

Analyze responses to lists and menus

You must enter one of a list of possible inputs. The program responds differently to each. Each input is, in effect, its own equivalence class. The invalid equivalence class includes any inputs not on the list.

As one example, if a program asks Are you sure? (Y/N), one equivalence class contains Y (and should contain y too). Another contains N (and n). Anything else is invalid (or everything else should be taken as equivalent to N).

As another example, American taxpayers file as single, married filing a joint return, married filing separate returns, head of household, or qualifying widow(er) with dependent child. Some refuse to describe their marital status, which is also legal. There is an invalid equivalence class: some people claim not to fit into any of these categories. They write notes on the tax return explaining why. How does the program deal with these?

Look for variables that must be equal

You can enter any color you want as long as it's black. Not-black is the invalid equivalence class. Sometimes this restriction arises unexpectedly in the field—everything but black is sold out. Choices that used to be valid, but no longer are, belong in their own equivalence class.

Create time-determined equivalence classes

Suppose you press the space bar just before, during, and just after the computer finishes reading a program from the disk. Tests like this crash some systems. What are the equivalence classes here? Well, everything

133