In the last video I showed you how inputs, environment conditions, and results can be put together in a TAME worksheet to create tests for a login page.
We can see the nine test cases on the scoresheet—a spreadsheet that lists each of the test cases. It’s perfectly reasonable to take this and make up tests. But in order to really give this to someone to run—or to be able to turn this into a set of automated tests—we need real values and detailed instructions.
It’s not enough to just say, “enter a good syntax user ID;” you need to say what that user ID should be. To do this the test spec should define actual values for the user ID and the password.
Notice the gray divider column following the results. To the right of the results, you can specify actual values for the different inputs.
To specify a value, write the name of the input in row 1—this has to match the name in the input cell—and then the different values in row 2. What different values do we have?
To test with a good user ID who’s in good standing and a good password, choose one value. We’ll call this user “gary.”
Notice how, just like a result, the value is marked with the choices that say when it will be used. It’s obviously of good syntax, and it names a real user. We don’t need to select the action when specifying values.
Another good syntax user ID is “charlie.” But charlie isn’t a user ID of a real user in good standing. It gets a different marking.
We can do the same for the password. Here we’ll make “test.123” the good password for gary, and “bad.456” the bad password for gary.
Other values include the blank or missing user ID and password…
…and bad syntax values.
To make the test spec read a little easier, we generally merge the Row 1 cells so that they become headers for the different values.
Once we apply the values we can again run TAME to generate test cases.
Notice that the actual values to use are now specified for each test case. In order to avoid confusion between the name of the choice and the specified value, the choice column headers contain the word “choice.”
It’s good but it’s still not something that I think that a tester would be able to follow right away. There are two things we need to work on. One is that some test cases don’t specify a value for either the user ID or the password. The other is that it would be great if the test case could actually be written in terms of the steps click this, enter this, tab to this, and so forth. That is a real protocol. We’ll see how to create a protocol in the next videos.