Pictures:
Artform NO. 1

Nederlands

Process Cycle Test

Procedure for the Process Cycle Test (manually)

Use Cases Testing: The manual steps to be taken in order to arrive at a specification for a process cycle test include:

  1. Establishing path combinations.
  2. Choice for test measure: normal/in-depth?
  3. Establishing paths.
  4. Specifying test cases.
  5. Establishing the initial data set.
  6. Assembling the test script.
See also: Procedure for the Process Cycle Test (automated)

Establishing path combinations

For every decision point found, the path combinations must be determined. A path combination is a link between an action before a decision point and an action after the same decision point. When creating path combinations, it is wise to number the actions first. Sequential actions between two decision points receive a common number. All path combinations, i.e. all combinations of two consecutive actions with a decision point in between, must be written out. This is illustrated in the following example:


fig.2 Activity Diagram of the Use Case: Manage Courses

In the course administration department, modification forms come in concerning self made and/or bougth courses. The head of the department receives the modification forms and passes them on to an employee of the department. Depending on the type of modification (changing, entering or deleting) a maintenance function for the course data is started. After the modification has been performed, the next form is executed. After performing all the forms, the employee provides the head of the department with a written report of completion.

Path combinations for decision point A: (1,2); (1,3); (7,2); (7,3);
Path combinations for decision point B: (3,4) and (3,5);
Path combinations for decision point C: (2,6); (4,6); (5,6); (2,7); (4,7); (5,7);

Choice for test measure: normal/in-depth?

The test measure is used to decide to what extent dependencies between consecutive decision points are tested. in test measure n, all dependencies of actions before a decision point and after n-1 decision points are verified by including all possible combinations regarding the actions in the test paths. One works on the basis of test measure 2 with an in-depth PCT and test measure 1 with the 'normal' PCT.
A detailed description of the in-depth process cycle test (test measure 2) is given first, followed by a description of the 'normal' process cycle test (test measure 1).

Establishing path combinations for test measure 2

The path combinations must now be linked to create paths that run from the start of the use case to the end of the use case. In our example, each path starts with action 1 and ends with action 6. Each path combination must be included in at least one path, so the path combinations are: (1,2); (1,3); (7,2); (7,3); (3,4); (3,5); (2,6); (4,6); (5,6); (2,7); (4,7); (5,7).

  1. Start with the first path combination that has not yet been included in a path, in this case (1,2). Then link the first path combination that starts with a 2 and has not yet been included in a path, in this case (2,6). This creates the path (1,2,6), after which the next path can be started. The remaining path combinations are: (1,2); (1,3); (7,2); (7,3); (3,4); (3,5); (2,6); (4,6); (5,6); (2,7); (4,7); (5,7).
  2. Continue with the remaining path combinations. The first path combination that has not yet been included in a path is (1,3). The first path combination that starts with a 3 and has not yet been included in a path is (3,4). The first path combination that starts with a 4 and has not yet been included in a path is (4,6). Another path is created: (1,3,4,6).
    The remaining path combinations are: (1,2); (1,3); (7,2); (7,3); (3,4); (3,5); (2,6); (4,6); (5,6); (2,7); (4,7); (5,7).
  3. The first path combination that has not yet been included in a path is (7,2). Because this path combination does not start at the beginning of the use case, another path combination must be placed in front of it: (1,2) combined with (2,7) is selected. This makes (1,2,7,2). The (1,2) has now been used twice, but that is not a problem. Then continue with the search for the first path combination that starts with a 2 and has not yet been included in a path. Because there are no more path combinations that start with a 2 and have not yet been included, a path combination is selected that starts with a 2 but has already been included: (2,6) is chosen, which results in the path: (1,2,7,2,6).
    The remaining path combinations are: (1,2); (1,3); (7,2); (7,3); (3,4); (3,5); (2,6); (4,6); (5,6); (2,7); (4,7); (5,7).
  4. The first path combination that has not yet been included in a path is (7,3). Because this path combination does not start at the beginning of the use case, another path combination must be placed in front of it: (1,3) (3,5) and (5,7) are selected. This makes (1,3,5,7,3). Next we create a path with the last to path combinations: (4,7) and (5,6). This results in the path: (1,3,5,7,3,4,7,3,5,6).
    No remaining paths are left: (1,2); (1,3); (7,2); (7,3); (3,4); (3,5); (2,6); (4,6); (5,6); (2,7); (4,7); (5,7).
    This means that all path combinations have been included in the folowing paths:
    Pad 1: (1,2,6)
    Pad 2: (1,3,4,6)
    Pad 3: (1,2,7,2,6)
    Pad 4: (1,3,5,7,3,4,7,3,5,6).

In the next “cross reference”, the path combinations have been set out against the paths. It is wise to make such a cross-reference table: by doing so, it becomes clear that each path combination has been included in a path at least once.


Als a cross reference can be use to check for double paths. In this example path 1 can be deleted.


Establishing path combinations for test measure 1

The test paths are the various possibilities for the Use Case (activity diagram) to be run. The following rules apply:

  • A test path always starts at a starting point and continues to an end point.
  • All seperate activities must occur at least once in a test path.
  • The aim is to have as few test paths as possible, but to include all possible activities.

When determining the test paths, the starting point is the start symbol of the first process. Then the first decision point is found. A decision point is indicated in the Use Case with a rhombus. A decision point indicates an intersection, where the Use Case is split into several paths. From the decision point, a path must be chosen. Because the aim is to have as few test paths as possible, a returning path is chosen the first time it is reached. When no "loops" occur, the easiest way is to first choose the shortest possible path.
The path is followed through the subsequent decision points until an end symbol is reached. The entire sequence of following the paths from the starting symbol to the end symbol constitutes the first test path.
The next test path takes the same path as the first test path until the last dicision point. A different direction is chosen at this point. The determination of the test paths is continued from the last decision point until all paths after the decision point have been included in a test path. The same is done from the second to last decision point. This procedure is followed until all possible paths from all decision points have been dealt with.
By working your way back from the last decision point, the test paths are determined in a structured way and the completeness of the test can be ensured. If a different direction is taken at the first decision point, we could possibly end up with fewer test paths, but ensurig completeness would be a much more complex activity, with the risk that a path was overlooked.
The procedure is applied to the Use Case that has previously been displayed schematically with the description of the process cycle on the test basis of test measure 2. Starting from the starting symbol and consistently choosing the path in the direction of the activities who are not in the path yet, creates the test path: (1,3,4,7,2,7,3,5,6).
In this example all activities are included in ust one test path:
Path 1: (1, 2,7,3,4,7, 3,5,6).

The number of test paths has now been reduced fro 3 with the PCT with test measure 2 to 1 with the PCT with test measure 1. Obviously, this means a lower degree of coverage with the PCT with test measure 1, but this was a conscious choice in the test strategy.
Wheb determining the test paths, one must take a note of the activities that have already been dealt with. The simplest technique for this is to tick off the paths on the Use Cases.

Specifying test cases

The paths through the Use Case (activity diagram) must be provided with a definite content in this step. As we have said before, this means that for each path, a sequence of actions must be described in such a way that the correct path is taken when these actions are executed. This is an activity that requires a certain amount of inventiveness and is therefore quite difficult to describe in general terms. We will restrict ourselves to giving an example: The actual content of path 2 = (1,2,7,2,6) may look like this:

P2.1 The head of the department passes the modification forms on to an employee of the department; get the first form; this form contains the data of a new course (1,2)
P2.2 Perform the data entry of the new course and go back to the selection screen (2,7)
P2.3 Get the next form (again a new course) and perfotm the data entry (7,2)
P2.4 Close the screen and report to the head of the department (2,6)

Establishing the initial data set

See the TMap®-book.

Assembling the testscript

See the TMap®-book.

Testuitvoering en beoordeling

See the TMap®-book.