Guidelines: Test Model
Topics
Explanation 
A test model is a model of what is to be tested in a target for test (be it the system or a part of the system). The role of the test model is to communicate what is to be tested and how to test it.
Use
For each iteration in the development lifecycle, you develop a new version of the test model. The new version contain old tests (as regression tests), and new tests that take new functionality into account.
At the highest level of the test model, you will see a collection of test cases. Test cases define a collection of inputs, execution conditions and expected results. The majority of the test cases are derived from use cases, scenarios, or use-case realizations, and correspond to an execution of a use case as it traverses the test target. If the target for test is the whole system, the test case will correspond to a complete execution of a use case. If the target for 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 detail depicted in the test model is that which identifies 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 requirements 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, 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).
