Suppose it's your job to build tests for TAME. One of the use cases you need to test is a manager creating a new project. You might start by writing the procedure as a series of steps:
- Open a web browser to the TAME home page.
- Click the Log in link to bring up the Log in page.
- On the Log in page enter a good manager's user ID and password, then click the Log in button.
- Verify that you're now on the My Projects page.
- Verify that the My Projects page shows the manager's current projects, both those that he manages and others to which he merely belongs.
- Click the "Create a New Project" link.
- Enter a name and description, then click "Create New Project."
- Verify that the new project appears on the "My Projects" page.
- Click the Log out button to return to the TAME home page.
- Verify that the manager is logged out.
That procedure defines the common main success (a.k.a. "happy day") scenario. But your work as a tester is far from done.
First, you need to elaborate on each of those steps to make them more precise and consistent. Instead of just saying
- Enter a date and a number of miles driven, then click "Submit."
you need to divide this into specific steps such as
- Enter a good project name, where "good" is a name that isn't blank, doesn't start with a blank or special characters, and is less than 64 characters in length.
- Optionally enter a description. If only whitespace characters (blanks, tabs, returns) are entered into the description box, the description is assumed to be blank.
- Click on the Create New Project button
This level of precision is an absolute requirement for automated testing.
Then you will need to create many more scenarios to deal with all kinds of alternatives, including:
- What if the project name is blank?
- What if the project name starts with a blank?
- What if the project comments are blank?
- What happens if the manager is already logged in?
- What happens if another user is already logged in?
- What happens if a bad user ID is entered?
- What happens if a bad password is entered?
- What happens if the user ID or the password are left off?
- What happens if the group has no projects?
Ugh.
The typical process for dealing with all of those different scenarios is to simply write each one, generally by doing a lot of copying and pasting. Even the most modern behavior-driven and keyword-driven tools rely upon building test cases one at a time. Sure, they may have "macro" and "module" capabilities, but they still take a serial, one-at-a-time approach to building test cases. This makes it difficult to know in advance the size of the testing job and to produce a consistent set of tests.