Guidelines:
Test Model

Test Model |
The
test model is a
representation of what will be tested and how it will be tested. It is a
view of the design and implementation models and includes the collection of
the test cases, test procedures, and test scripts, and their
relationship. |
Topics
A test model is a model of what is to be tested in a target-of-test (be it
the system or a part of the system). It is a view of the design and
implementation models that include additional notation specific to test,
including the test cases, test procedures, and test scripts. The
test model communicates what is to be tested and how to test it.
For each iteration in the development lifecycle, you develop a new version of
the test model. The new version should contain old tests (as regression tests),
and new tests that take new functionality into account.
At the least detailed level of the test model, you will see the design and /
or implementation model and notations reflecting the test cases. Test cases
define a collection of inputs, execution conditions and expected results. The
majority of the test cases are derived from use-case scenarios, or use-case
realizations, and correspond to an execution of a use case as it traverses the
test target. If the target-of-test is the whole system, the test case will
correspond to a complete execution of a use case. If the target-of-test is a
subsystem, the test case will correspond to the part of the use case that
traverses the subsystem.
An example of a system test case for an ATM machine would be to verify that a
customer can withdraw $100, provided the card is valid and enough funds are in
the specified account. Another test case would be to verify that the ATM
software behaves as expected when a customer enters the wrong PIN for an
otherwise valid card.
In earlier iterations, there might not be any complete use-case descriptions
yet, only scenarios. Therefore, in the first iteration of test, only a test case
to verify the ability to withdraw cash is implemented, but not the ability to
handle the wrong PIN code.
The most detailed of test models will depict the relationships between the
test cases, test procedures, and the test scripts that are generated to execute
the tests.
Not all requirements on a system are manifested in use cases. This type of
requirement is referred to as non-functional or technical requirements. Examples
are load requirements and application platform requirements.

A test case is derived from and traceable to a use case
or scenario, a use-case realization, or a requirement.
In organizations where traceability from original system requirements to the
details of the implementation is important (or required), a traceability link
from a test case to its corresponding system requirement(s) should be
maintained.
Note: if you do not have tools that efficiently help you maintain these
traceability links, it may become very costly to administer. In that case
knowing what use case, use-case scenario, or use-case realization a test case is
derived from may be sufficient.
At the highest level, your test cases should be grouped according to what the
target for test is: system, subsystem, or component. At the next level, you
might choose to group according to what use case or requirement the test cases
are derived from.
In a simple implementation, a test case is implemented as one test procedure.
The test procedure physically manifests itself as a textual instruction on how
to perform the test case (manual test), or as a test script to be executed
within the context of a test automation tool. In a more complex implementation,
a test case may correspond to one-to-many test procedures, as well as one test
procedure being part of implementing one-to-many test cases. Similarly, the test
procedures may be implemented by one-to-many test scripts.
See Artifacts: "Test Case",
"Test Procedure", or "Test
Script" for more information.

The relationship between test cases, test procedures, and
test scripts.
A test case is implemented by one-to-many test procedures.
A test procedure may implement (the whole or parts of) one-to-many test
cases.
When manual testing is to be executed, there is a one-to-one relationship
with the test procedures.
When testing is automated (test scripts implemented), a test procedure may be
implemented by many test scripts, or a test script may implement many test
procedures (or parts of test procedures).
Copyright
© 1987 - 2001 Rational Software Corporation
|