A testcase has three stages

Each test case that you record should have the following three stages.

• It drives the application from the initial state to the state you want to test.
• It verifies that the actual state matches the expected (correct) state. (Your QA
department might use the term baseline to refer to this expected state.) This stage is
the heart of the testcase.
• It cleans up the application, in preparation for the next testcase, by undoing the
steps performed in stage I.

Each testcase is independent

Each testcase you record should perform its own setup in stage 1, and should undo
this setup in stage 3, so that the testcase can be executed independently of every
other testcase. In other words, the testcase should not rely upon the successful or
unsuccessful completion of another testcase, and the order in which it is executed
should have no bearing on its outcome. If a testcase relies on a prior testcase to
perform some setup actions, and an error causes the setup to fail or, worse yet, the
application to crash, all subsequent testcases will fail because they cannot achieve
the state where the test is designed to begin.

A testcase has a single purpose.

Each testcase you record should verify a single aspect of the application in stage 2.
When a testcase designed in this manner passes or fails, it's easy to determine
specifically what aspect of the target application is either working or not working. If a
testcase contains more than one objective, many outcomes are possible. Therefore, an
exception may not point specifically to a single failure in the software under test but
rather to several related functions points. This makes debugging more difficult and
time-consuming and leads to confusion in interpreting and quantifying results. The
net result is an overall lack of confidence in any statistics that might be generated.

Note but there are techniques you can use to do more than one verification in a
testcase.

A testcase starts from a base state

In order 'or a testcase to be able to function properly, the application must be in a

stable state when the testcase begins to execute. This stable state is called the base
stale. The recovery system is responsible for maintaining the base state in the event
the application fails or crashes either during a testcases execution or between
testcases.
Default BaseState To restore the application to the base state, the recovery system
contains a routine called DefaultBaseState that makes sure that
• The application is running and is not minimized
• All other windows (for example, dialogs) are closed
• The main window of the application is active