The seven test cases generated so far are good, but they’re not really enough. Just having a good syntax user ID and a good syntax password won’t guarantee that the user will really be logged in. In the words of the worksheet, just because the user “can log in” does not mean that the user will really be logged in.
A successful login also requires the user ID names a good user. This is an example of an environment condition or precondition—some property of the system environment that needs to be in place before the test runs.
In the happy day scenario, the user ID should identify a real user who’s in good standing. We’ll need that to be able to log on.
However, if the user ID doesn’t identify a real user in good standing, or the user ID does identify a real user but the password is incorrect, those will lead to different outcomes where the person logging in will get an error message.
The way to address this in TAME is to add environment conditions. These are categories like inputs, except that they represent different situations that influence the outcome of the test.
Let’s see how environment conditions can make for more complete tests.
The first question is, “does our user ID name a good user?” So create an environment condition for that: put “Condition” into column one, the name of the condition into column two, and then list the two choices.
The second question is, “is the password correct for the user?” Create a second environment condition for that: name it, and then list two choices for that one.
Of course the environment conditions are used to define the different results.
One result is that we’ll see the “Invalid login attempt” error message when the user ID and the password are good syntax but the user ID doesn’t name a good user. And just like with the inputs, we don’t have to mark every environment condition. If the user ID doesn’t name a good user, we don’t care about the password. Think about it. A user that doesn’t exist doesn’t have a password.
This same “Invalid login attempt” error message also occurs when the user ID does name a good user, but the password is bad for that user. It makes sense to have the same message in both cases because we don’t want to give away whether a user exists or not.
So we’ll solve this by making a second column for the same result.
In one column choose the good syntax user ID, the good syntax password, and the choice where the user ID doesn’t name a real user. This occurs when the user clicks the “log in” button.
In the next column choose the good syntax user ID, the good syntax password, the choice where the user ID does name a real user, and the choice where the password is wrong for the user. Also, this happens when the user clicks “Log in.”
Finally, there’s the real happy day scenario. That requires the good syntax user ID and password as we had before, but also a user ID that names a real user and a password that’s right for the user. When the Login button is clicked, the user actually gets logged on.
Once these environment conditions are added, we can save the workbook and upload it. Download the scoresheet and see that TAME produces these nine test cases:
That’s a lot of tests for something as simple as the login page! But I think you’ll agree that these are all different real scenarios that need to be tested.
The difference in using TAME is that on a TAME worksheet we can see them all at a glance and understand what leads to each scenario.
In this video we’ve used tame to create many test cases based upon different choices of inputs and environment conditions. Next up will learn how to create test protocols with actual input values and specific instructions for the testers to follow.