TAME’s technique for managing this combinatorial explosion is to define the expected results, and then to mark the choices that lead to those results.
One result is the missing User ID error message. To define it, go to the Results section and, in the second row, enter “missing user ID.”
Now that’s caused by a blank user ID and appears when you click the Log In button. So mark those two choices by putting Xs in the missing user ID column—one in the row for the empty user ID and another in the row for the Log In button.
Another result is the missing Password error message.
As before, go to the Results section and enter “missing password.”
That’s caused by a blank password and, again, appears when you click the Log In button. Mark those two choices: one in the missing password row, and another in the Log In button row.
What’s another result? Well, if the user ID isn’t in the form of a good email address, you’ll get another error. So add a third result, this one called “bad user ID.”
By now you can probably guess what cells to mark: the bad syntax User ID and the Log In action.
You can do the same for the too long user ID…
…and for the password containing all space characters.
Finally, of course, there’s the successful result from the good choices. Add a result—we’ll call it “can log in” and mark the choices for the good syntax user ID, the good syntax password, and the Log In button.
Save the workbook…
…and upload it to TAME.
Now you’ll see that TAME has generated only seven test cases, and the redundancy I pointed out earlier is gone.
The blank cells in the choice columns indicate “don’t care.” For example, if I leave the user ID empty, I get a missing user ID message, no matter what I enter for the password.
The same is true of the empty password.
You can see that TAME now generates as few as one test case for each expected result, making for a much more reasonable set of tests1.
Now you might notice that I labeled the happy result as “Can log in.” To explain why I wasn’t more definitive, take a look at the next video. There I’ll introduce environment conditions—situations that are true before the test runs—as a way of testing situations that aren’t solely based upon the inputs.
1 There should be a whole Aside on dealing with don’t care options. This can also cover the issue of default values and marking default values—so these aren’t part of the main flow.