Activity

[Work on own experiences/completions]

Quality Assurance, Test, Usability

A-61 Produce/Define test cases

Define the concrete test cases on basis of the test plan or update the existing test cases.

Activity has to be run in Construction Phase (Accompanied Activity)
Activity has to be run in Transition Phase (Accompanied Activity)


Check on basis of the Test plan the existing test cases and update them if necessary or define new test cases. Describe the concrete test activities/flows with ther necessary test data (input) and their results (output). Each test case has a flow description. The descriptions can summarize several independent single tests.

Each Testcase has a description that any testing person is able to run the test. Define the single steps of the written test case as check boxes to use the description as a test protocol, too.

General requirements on test cases:

Test cases for tests of a subsystem
The specification of the subsystem interfaces (incl. type model and constraints), the subsystem model, the requirements specification, and already existing test cases are used to prepare the test case definition.

You have to define tests to validate and proof the correctness of the subsystem interface. You have to consider the pre- and post-conditions as well as the invariants and constraints resultingfrom the type model. At least, the possible exceptions of the subsystem interfaces have to be tested. Therefore you have to activate the exceptions.

The test case are defined using the use cases and additional requirements. If possible, test for non-functional requirements have to be defined, too.

As far as possible, tests should be programmed that they can be done anytime. The programming of automated tests should be done in a way that conclusions can be done either about the conformance with a requirement or about the non-conformance.

You have to validate only the external behavior. The internal behavior is not part of the subsystem test.

Once you have found errors, failures, inconsistences or anything else in the specification or requirements, the correction has to be done. Any correction must be documented.


Reasons:

Trigger:

Precondition:

Documents:

E-95 Test plan
E-161 Test concept
E-63 Interface specification
E-38 Activity Diagram
E-6 Essence of Use Cases

Countercondition:

Results:

E-59 Testcase
E-60 Test data

Special tools:




Responsible person:

.Project Quality Manager

Involved persons:

.Test Originator
.Test accomplisher

Postcondition:

A-151 Realize and Test the Data Base Mapping (persistancy)
A-51 Test the sub system
A-70 Develop and Test Reports and Evaluations
A-134 Realize and test a domain related class
A-48 Develop and test an adapter for external interfaces
A-59 Realize and Test batch-programs
A-153 Run the User Test
A-175 Test enumerations (key values)
A-293 Autmatical System Test

OEP - Object Engineering Process, v3.0, 06.11.2006 11:08:02, Copyright © 2006 by oose Innovative Informatik eG