The Results specified so far all represent conditions that can be checked after the action is performed. However, it is also possible and desirable to add conditions that can be checked before the action—usually upon entry to the page.
Suppose that as part of the login page we want to check that the fields are empty and no messages are present before the tester enters the user ID and password. We can do that by adding more result entries.
Because I like these prechecks to appear before the action-triggered results—what I’ll call “postchecks”—I’ll make room on the left.
Now I can add the three postchecks.
In order to make sure these checks that are done before the action, I don’t mark any action. I also don’t mark any inputs, but I may mark environment conditions.
Save the file and upload it to TAME.
Now when you look at the protocol you’ll see three additional verifications, instructing the tester to not only check that he’s on the Login page, but also that there’s no error message and that the user ID and password fields are empty.
As with all results, titles alone are good, but they are sometimes too terse. To solve this you can add comments to the result cells:
These more descriptive comments will be put into the protocol. Save the file, upload it.
And then open the protocol to see the more descriptive test case.
Now this is getting pretty indistinguishable from a hand-written test. Well, it is a hand-written test, but it’s been built in a much more organized way.
So far all of the tests we’ve create are looking at only a single page. But what if we want to create tests for a whole sequence of pages—for example, starting at the homepage, then going to the login, then the My Tests page, and finally logging out? In the next video, I’ll show you how to do that by adding additional tabs to the workbook.
1 If you haven’t noticed already, unused results will give you an error.
2 Later we’ll build upon this for the scenario where a user might already be logged in.