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:

  1. Open a web browser to the TAME home page.
  2. Click the Log in link to bring up the Log in page.
  3. On the Log in page enter a good manager's user ID and password, then click the Log in button.
  4. Verify that you're now on the My Projects page.
  5. Verify that the My Projects page shows the manager's current projects, both those that he manages and others to which he merely belongs.
  6. Click the "Create a New Project" link.
  7. Enter a name and description, then click "Create New Project."
  8. Verify that the new project appears on the "My Projects" page.
  9. Click the Log out button to return to the TAME home page.
  10. 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

you need to divide this into specific steps such as

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:


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.