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 scoresheeta spreadsheet that lists each of the test cases.  Its perfectly reasonable to take this and make up tests.  But in order to really give this to someone to runor to be able to turn this into a set of automated testswe need real values and detailed instructions.

Its 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 1this has to match the name in the input celland then the different values in row 2.  What different values do we have?

To test with a good user ID whos in good standing and a good password, choose one value.  Well call this user “gary.” 

Notice how, just like a result, the value is marked with the choices that say when it will be used.  Its obviously of good syntax, and it names a real user. We dont need to select the action when specifying values.

Another good syntax user ID is “charlie.” But charlie isnt a user ID of a real user in good standing.  It gets a different marking.

We can do the same for the password.  Here well 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.”

Its good but its 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 dont 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. Well see how to create a protocol in the next videos.