Information Technology Reference
In-Depth Information
Table 3.1 Problem repository
No.
Tester
Problem description
Error category
Patch date
Status
- Open
- Analysed
- Work in progress
- To be delivered
- Dispatched
- Re-tested.
Prioritisation is important. Contrary to the subjective feeling of a tester the
review meetings should come to objective assessments, which problems accepted
as errors are to be classified in the following way:
Production prohibiting: die function produces wrong results, breaks down,
follows a logic, which is unusable etc. (Prio 1)
Production prohibiting, but can be used on a temporary basis by employing a
workaround (the duration of the workaround until the error to be fixed has to be
agreed upon) (Prio 2)
All other errors (Prio 3).
If test sequences make it necessary a fall-back schedule should be prepared.
Such an eventuality makes sense, when it is to be expected that the test environment
may become unstable (data overruns, table overruns, other system failures) and has
to be re-initialised. The time available in our example covering only 3 weeks, limits
this possibility significantly.
The acceptance protocol should contain the following elements:
Date
Acceptance object, if necessary reference to an order
Functions in detail (mention—not full description)
Configuration for the acceptance tests
Types of test data
Persons responsible (sub-project leaders)
Names of the testers
Results per function (accepted y/n or conditionally)
Remaining errors and mutually agreed correction dates
General recommendation.
