Process Cycle Test (PCT)

Coverage type Paths - usually test depth level 2

Description

The process cycle test is a technique that is applied in particular to the testing of the quality characteristic of Suitability (integration between the administrative organisation and the automated information system). The test basis should contain structured information on the required system behaviour in the form of paths and decision points. The process cycle test digresses on a number of points from most other test design techniques:

  • The process cycle test is not a design test, but a structure test: the test cases issue from the structure of the procedure flow and not from the design specifications.

  • The predicted result in the process cycle test is simple: the physical test case should be executable. This checks implicitly that the individual actions can be carried out. In contrast to other test design techniques, no explicit prediction is made of the result, and so this does not have to be checked.

The process cycle test focuses on the coverage of the variations in the processing. The coverage type used in this is:

  • Paths: test depth level 2.

Variations on the process cycle test can be created by applyingvariations of the coverage type:

  • Paths: test depth level 1, test depth level 3 and higher
    With this, paths can be tested in respectively less or more depth.

Points of focus in the five general steps

1- Identifying test situations

In order to apply the process cycle test, a process diagram is required. This diagram should contain, besides a start and end point, decision points and paths. If the test basis already contains a diagram, then for the sake of clarity it is often useful to ‘undress’ it, so that it only contains the above-mentioned aspects. If there is no diagram present in the test basis, the tester will have to distil the decision points and paths from the test basis himself in order to create a diagram. Subsequently, the test situations are derived from the diagram in accordance with the coverage type “paths”.

2- Creating logical test cases

The creation of the logical test cases is divided into two activities:

  • Creating a set of logical test cases

  • Describing the consecutive actions per logical test case.

In the creation of the set of logical test cases, all the test situations should be covered. A test case is defined by going through the process in a certain way from “Start” to “End”. The tester is free to choose the way in which the process is followed, as long as all the test situations are covered at least once.

If necessary, it can be shown with the aid of a cross-reference matrix that all the test situations are covered with the chosen set of test cases. In principle, there are two ways of arriving at a covering set of test cases:

  • Working from the process chart, define a test case by running through the process in a particular way from “Start” to “End”. The tester is in principle free to choose the exact way of going through the process. Cross out of the list of path combinations every combination that occurs in this test case. Repeat this process until the list of path combinations is completely crossed out.

  • Working from the list of path combinations, start with a path combination that begins at “Start”. Seek a subsequent path combination that starts with the path with which the previous one ends – like setting down domino tiles, in fact. Continue seeking a subsequent path combination until “End” has been reached. Obviously, previously unused path combinations should be used as much as possible.

3- Creating physical test cases

Besides the previously mentioned differences from the other test design techniques, there is another difference to note. With the test execution, there is more required in the process cycle test than just the technical test infrastructure on which the automated part of the information system runs. The manual procedures mainly have to be carried out by various types of employees, which means that several testers are required to play particular roles in the test execution. It is of course also possible to have the test executed by one tester who possesses several user IDs, repeatedly logging in and out during the test execution. In addition, the required data are only partly present in the database of the automated part of the information system, and the rest is outside the system, for example in the form of completed forms.

That, too, is different from the other test design techniques.

In the creation of the physical test cases, a physical formulation of the logical test cases is supplied. With this, the actions described serve as a starting point.

4- Establishing the starting point

No remarks.

5- Creating the test script

Often not done, since the physical test cases already consist of full scenario’s.