Early defect detection
There is another reason for assessing or evaluating the test basis, apart from establishing its testability.
Evaluation activities can reveal potentially expensive defects at an early stage of the development and test processes.
The test basis forms the blueprint for the new system to be built. Anything that is not mentioned in the test basis is
left to the development team to solve. The development team goes to work on developing the new information system on
the basis of the system documentation, which may contain mistakes. If these are not found in time, it can lead to a lot
of (often expensive) corrective work. The sooner a mistake is found in a development process, the simpler (and cheaper)
it can be reworked [Boehm, 1981]. If, for example, a defect in a specification or requirement is not discovered until
the execution of the acceptance test, the reworking costs are high. Not only must the software be amended, but also,
for example, the technical and functional designs. In general, it appears that early defect detection makes savings of
50%-80% possible.
By assessing the test basis and detecting defects early, the quality of the test basis will increase.
Context
While both the (definition of the) test basis and the agreed test strategy are specified in the test plan, the test
basis is often not yet available at the time of creating the test plan. In the Preparation phase, it has to be
investigated whether the test basis delivered corresponds with, and is usable for, the previously established
agreements in the plan. If this does not appear to be the case, it may be necessary to adjust the plan, which can have
both a negative and a positive infl uence on one or all of the money, time and quality aspects.
Negative influences are, for example:
-
the lack of a definitive test basis
-
a qualitatively inadequate test basis
-
a test basis with more complex algorithms than expected.
Positive influences are, for example:
-
a test basis with less complex algorithms than expected
-
a test basis that anticipates the making of logical test cases (see Tips - Prepare (AST)).
Amending the plan is a task from the Control (AST) and is
further explained there.
Preconditions
The Preparation phase starts as early as possible following the consolidation of the test plan and after the
consolidated test basis is made available (see In More Details - Prepare (AST)).
Method of operation
Once the test basis has been put at the disposal of the test team, a start is made on its testability review.
It is first examined whether the summarised information, of which the test basis consists, is still correct. If
necessary, it is brought up to date in consultation with the client. During this examination, it may appear that all of
the information is not yet available for the tester, or perhaps will not be arriving at all. In such a situation, a way
must be found of obtaining the missing information.
When the test basis is clear, this is assessed from the testing perspective for e.g. consistency, understandability and
completeness. Subsequently, on the basis of checklists, an assessment is made as to the extent to which the established
test strategy and associated test (design) techniques are applicable. The conclusions are documented in a testability
review report and discussed with the client. The results of this report may give rise to adjustments to the test basis,
the test strategy and the test techniques to be employed.
Roles / responsibilities
The testability review report is created by the test manager or test coordinator. All the other activities can be
carried out by any of the test team members. The report is intended for the commissioner of the test (the
client).
Activities
The Preparation phase consists of the following activities:
-
Collection of the test basis
-
Creating checklists
-
Assessing the test basis
-
Creating the testability review report.
The diagram below depicts the sequence and dependencies between the various activities (figure 1):
Figure 1: Preparation phase
|
