Process Cycle Test (PCT)

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 basic technique used in this is:

• Paths: test depth level 2

Variations on the process cycle test can be created by applying the basic technique:

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

Points of focus in the steps

In this section, the process cycle test is explained step by step, taking the generic steps (see "Introduction") as a starting point. An example is also set out, showing at each step how the technique works. In the example, a certain drawing technique is used to represent a detailed process diagram. Since no uniform agreements exist concerning the use of the technique and the use of the symbols, the meanings of the symbols are stated next to the diagram.

Example

Claim forms come into the claims handling department. After someone in the department has entered the claim details into the system, a process is begun to check the completeness of the details. In the event of incompleteness, the employee contacts the insured party, after which the details can be re-entered. When the details are complete, a process is begun to determine the claim sum and the number of claims submitted by the insured party over the previous year. If the claim sum is higher than €2,500, or if in the previous year more than 2 damages claims have been submitted, the head of the department then assesses whether or not the claim should be met. In the event of rejection by the head of department, a rejection letter is created; if it has been approved, a letter of approval is created. With 2 or fewer claims in the previous year and a damages claim of €2,500 or less, a letter of approval is always created.

Below, it is set out per step how the process cycle test is applied to this process:

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 technique described in "Paths" for the coverage type "paths".

Example
The tester has removed the information in the "claims handling" detailed process diagram that is surplus to the process cycle test, and numbered the paths. Check for yourself that application of the coverage type "paths" delivers the following test situations (path combinations) with test depth level 2: A: 1-2; 1-3; 3-2; 3-3 B: 2-4; 2-5 C: 5-6; 5-7

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" (see "Paths"). 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.

The logical test cases should then be written out. This means that for each test case a row of consecutive actions should be described, in such a way that the execution of these actions will touch on all the test situations from the test case. This activity requires inventiveness and is therefore rather difficult to describe in general terms. See the concrete terms of the example.

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.

3 - Creating physical test cases

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.

An overview of all featured Test Design Techniques can be found here.