CSC 307 Standard Operating Procedures,
Volume 2: Testing Design and Implementation

Introduction

The purpose of thorough requirements testing is to ensure that the publicly accessible documents we produce are of high quality. Since the requirements cannot be executed in the conventional programming sense, testing of requirements is done by careful human inspection.

Members of each team will inspect the functional requirements work of one other fellow team member. It can be helpful if the work being inspected is related to the work being done by the inspector, but that is not required.

The assignment of inspection test duties for each team should be determined by the middle of week 4, and entered in the following table, a copy of which is stored in the project repository, in the administration subdirectory, in the file named inspection-roster.html:

Team Member	Initials	Requirements Section Number and Title
member a
member b
member c
member d
member e
member f

The second column of the table has the name of the team member who is doing the inspection for the requirements section listed in the third column. The third column shows the two- or three-letter initials for the inspector, which will be used in the inspection test record described below.

It is the responsibility of the inspector to enforce the inspection testing standards described below. This enforcement should be performed before the functional requirements are publicly released. Details of the public release procedure are covered in SOP Volume 1.

Standards for Inspection of Functional Requirements

The standards described here apply to Section 2 of the 307 requirements specification document -- the Functional Requirements. Since this section of the document is written in HTML-formatted English prose and pictures, the inspection test procedure is defined in terms of the HTML document elements that organize the prose and pictures. Specifically, the functional requirements are subdivided into components denoted as follows:

HTML Tag	Denotation	Required Inspection
<Hn>	For any level n>=2, a section of functional requirements is denoted by the Dewey-decimal style numbering for that section. Since all functional requirements are contained in Section 2 of the requirements specification document, the denotation of all functional requirement sections begins with "2.", followed by subsection numbers. For example, "2.2.1" is the denotation of the first <H3> subsubsection of the second <H2> subsection of the second <H1> section of the document.	spelling, grammar, presentation style
<P>	Each paragraph in a (sub)section is numbered "Pn", with n starting at 1. For example, "2.2.1 P3" is the denotation of the third paragraph in Section 2.2.1.	spelling, grammar, presentation style
<IMG>	Each image in a (sub)section is numbered "In", with n starting at 1. For example, "2.2.1 I3" is the denotation of the third image in Section 2.2.1.	existence of image file, spelling, grammar, presentation style, image quality, aesthetics (in consultation with team artist as necessary)
<A>	Each anchor in a (sub)section is numbered "An", with n starting at 1. For example, "2.2.1 A3" is the denotation of the third anchor point in Section 2.2.1.	existence of anchor target

Inspection Test Plan and Record

A functional requirements inspection test plan is a five-column table consisting of a row for each component of the requirements, i.e., section, paragraph, image, and anchor. The five columns are:

1. requirement component denotation, e.g., 2.2.1 I3

2. three-letter inspector initials, as specified in the inspection-roster file

3. the date of the inspection

4. status, which is one of "DONE" or "FIX", where DONE means the component passes inspection or FIX means the component requires fixing of some form; a blank status entry means no inspection has been performed on the corresponding requirement component

5. remarks describing what fix(es) need to be made

A functional requirements inspection test record is a completed or partially completed plan. For example, the following is the beginning of a typical inspection test record:

Component	Inspector	Date	Status	Remarks
2.1	GLF	21oct09	DONE
2.1P1	GLF	21oct09	DONE
2.1I1	GLF	21oct09	FIX	image quality is poor due to small size; rescan from original into larger GIF format
2.1A1	GLF	21oct09	FIX	the anchor target is not found; check file existence and protection
2.1.1	GLF	21oct09	DONE
2.1.1P1	GLF	21oct09	DONE
2.1.1I1	GLF	21oct09	DONE
2.1.1P2	GLF	21oct09	FIX	grammatical error in sentence 1: "number" => "numbers"
2.1.1P3	GLF	21oct09	DONE
. . .	. . .	. . .	. . .

Requirements inspection test plans are stored in project subdirectory

testing/requirements/

requirements/ui-overview.html

testing/requirements/ui-overview-test.html

Procedural Details

It is the job of the assigned inspector to identify problems, not correct them. The inspector is responsible for writing the test plans for the html file, per the guidelines presented above. The inspector is then responsible for performing the tests and filling in the results in the test- plan file. These filled-in test plan files are the official record of the inspection testing, and when completed are checked into the project repository.

The specific time-line for inspection testing goes like this:

1. Each member checks in work to the repository.

2. All team members update their working directory from the repository.

3. The inspectors perform the inspection of all assigned files.

4. The the inspectors check in the inspection test record.

5. The librarian updates the projects/work release directory.

6. At a subsequent team meeting, the inspectors outline the results of the inspection testing to the rest of the team, and inform specific individuals of corrections that need to be made.