This item is scheduled for review.   Received comments are at the end of this page.

Please send any comments you have on the example using the Feedback Form.

Margaret Edney           d3.0.2                   01/04/03

1. Introduction

This example describes a test of the procedure used for handling personnel transfers in a large organization. The purpose of the testing is to verify valid routes through the system, ensure that there are checks in place to identify lost cases and confirm that there are no invalid routes through the system.

2. Requirements/Specification of the System under Test

All personnel eligible for transfer were identified on a system produced candidate list. This was reviewed manually and potential candidates were identified. Skill lists showing potential candidates were produced, by the system, and manually considered against available postings. Three weeks were allowed for this process. Reminders were sent out after 2 weeks. Candidates matching individual postings were input to the system, which then produced interview invitations. Candidates could reject the interview and be considered for other postings. Candidates were allowed 2 weeks to respond before a reminder was issued. If there was no response within a further week, the candidate was assumed to have rejected the interview and was reconsidered for other postings. Following the interview, results were input to the system. Results were “success”, “reconsider” or “reject”. Successful candidates were notified. Candidates labeled “reconsider” were eligible for other postings. Candidates labeled “reject” were no longer considered during this round of selection. All unsuccessful candidates, whether for reconsideration or rejection, were notified.

The system as initially specified did not place any limits on the number of times a candidate could reject, or ignore, an interview invitation. This was later changed to a maximum of 3 invitations. The candidate then had to wait for the next selection round.

Analysis of Requirements

A major consideration in Procedure Testing is identifying areas where cases can be lost (“black holes”) or delayed by users. Test cases were designed to exercise the steps of the procedure with emphasis placed on ensuring that all inputs and outputs are reconciled.

Inspections and reviews (Software Inspection: Gilb, T. and Graham, D., Addison Wesley, 1993) of the procedure requirements were used to identify all transitions and any possible “black holes” or “pending trays”.

Flowcharting techniques were used to describe the procedure flow.

3. Test Design

1. Control Flow Testing  (BS 7925-2) was used.

All branches was chosen as suitable coverage criteria.

The different paths through the process were identified from the flowchart.

The Inputs to the system are:

To achieve branch coverage, the paths through the process are:

2. State Transition Testing (BS 7925-2) was used.

This exercised each transition between automated and manual states. Sequences of transitions were also used.

Chow’s coverage measures were used. “0-switch” which covers each transition, was used as a minimum, giving 100% transition coverage. In addition, “n-switch” to cover possible n+1 long sequences of transitions was used to detect possible transition errors, missing or extra states.

Each transition is between the automated state and the manual state.

Or between the manual state and the automated state.

Each stage in the process can be considered as a sequence of transitions between a “waiting” state, a “listed” state and a “decided” state as shown in the diagram:

From the state transition diagram, a state transition table was produced.

A full state transition diagram for the system shows each step in the process and the input that triggers each transition.

3. Use Case Modeling

Use case modeling can be used to identify use cases.

This diagram is very simplified. Additional use case models would include candidates who failed to respond to invitations or who refused the interview, candidates who were rejected at the beginning of the process and candidates who were to be reconsidered for other postings.

An additional Use Case is the Placement officer as shown in the following diagram:

4. Equivalence partitioning (BS 7925-2) was used to select cases from the database.

The partitions include:

4. Actual Test Cases

1. Control Flow Testing

Case 1 – A candidate selected for interview; all responses received on time; candidate accepts offer.

Case 2 – A candidate selected for interview, both responses require reminders, candidate accepts offer.

Case 3 – Candidate rejects interview. Candidate on new list

Case 4 – Candidate marked for reconsideration following interview. Candidate on new list

Case 5 – Candidate rejected at interview.

Case 6 – Candidate rejects offer. Candidate on new list.

Case 7 – Candidate rejected at consideration stage.

2. State Transition Testing

Test cases were selected to cover each single transition, for example receipt of candidate selections:

In practice, many cases would be required to cover all transitions identified.

3. Use Case Modeling

Case 1 – A successful candidate

Case 2 – A candidate where responses are not received

Case 3 – A candidate who rejects the interview

Case 4 – A candidate who rejects the offer

Case 5 – A candidate rejected at interview

Case 6 – A candidate who rejects the offer

Case 7 – A candidate who is rejected at the consideration stage.

Case 8 – A Placement officer who fails to return their selection lists.

4. Equivalence partitioning