Vishwakarma Institute of Technology, Pune-37.

<Organization>

<
System Testing Document

<mm

<Version

Approvals Signature Block

Project Responsibility Signature Date

Project Guide (Internal)
Project Guide (External)
Documentation Leader

Department of Computer Engineering

 System Testing Document

The document in this file is for System Testing Documentation Specifications, which
conforms to the requirements specified in System Requirements Specification.

Items that are intended to stay in as part of your document are in bold; blue italic text is
used for explanatory information that should be removed when the template is used.

2 v. 1.0 2006
 System Testing Document

Table of Contents
1. General Information4
1.1 VERSION CONTROL..................................................................................................................... 4
1.2 INFORMATION DETAILS................................................................................................................ 4
2. Testing Process 4
3. definitions in Testing Process 6
4. Test Plan 9
5. Test Case Specification 11
6. Test Procedure Specification 12

1. GENERAL INFORMATION
Fill in the following details to keep trace of Project Phases and Iterations.

3 v. 1.0 2006
 System Testing Document

Informational Item Information

Document Title System Testing Document
Version 1.0
Author Vit
Project Name Project Name
Project Phase Phase 1
Project Iteration 1

1.1 VERSION CONTROL

Fill in the following details to keep trace of Versioning Details.

Date Version Description Author

Feb-26-2007 1.0 Created

1.2 INFORMATION DETAILS

Fill in the following details to keep trace of information that you are generating.

Informational Item Information

Filename /conversion/tmp/scratch/447093887.doc
Last Saved On Tuesday, February 27, 2007, 8:41:00 AM
Last Saved By Vit
Number of Pages 12

2. TESTING PROCESS
The test plan prescribes the scope, approach, resources, and schedule of the testing activities. It
identifies the items to be tested, the features to be tested, the testing tasks to be performed, the
personnel responsible for each task, and the risks associated with the plan.
Three document types cover test Specification:
 A test design specification refines the test approach and identifies the features to be
covered by the design and its associated tests. It also identifies the test cases and test
procedures, if any, required to accomplish the testing and specifies the feature pass/fail
criteria.
 A test case specification documents the actual values used for input along with the
anticipated outputs. A test case also identifies constraints on the test procedures resulting
from use of that specific test case. Test cases are separated from test designs to allow for
use in more than one design and to allow for reuse in other situations.
 A test procedure specification identifies all steps required to operate the system and exercise
the specified test cases in order to implement the associated test design. Test procedures are
separated from test design specifications as they are intended to be followed step by step
and should not have extraneous detail.

Four document types cover test reporting:

4 v. 1.0 2006
 System Testing Document

 A test item transmittal report identifies the test items being transmitted for testing in the
event that separate development and test groups are involved or in the event that a formal
beginning of test execution is desired.
 A test log is used by the test team to record what occurred during test execution.
 A test incident report describes any event that occurs during the test execution which
requires further investigation.
 A test summary report summarizes the testing activities associated with one or more test
design specifications.

Figure 1 shows the relationships of these documents to one another as they are developed and
to the testing process they document.

Figure 1—Relationship of test documents to testing process

5 v. 1.0 2006
 System Testing Document

3. DEFINITIONS IN TESTING PROCESS

Acceptance criteria: The criteria that a system or component must satisfy in order to be
accepted by a user, customer, or other authorized entity.

Acceptance testing: (1) Formal testing conducted to determine whether a system satisfies its
acceptance criteria and enables the customer to determine whether to accept the system. (2)
Formal testing conducted to enable a user, customer, or other authorized entity to determine
whether to accept a system or component.

Computer Software Configuration Item (CSCI): An aggregation of software that is designated

for configuration management and treated as a single entity in the configuration management
process. Contrast with: Hardware configuration item See also: Configuration item

Configuration item (CI): An aggregation of hardware, software, or both, that is designated for
configuration management and treated as a single entity in the configuration management
process. See also: Hardware configuration item; Computer software configuration item.

Development testing: Formal or informal testing conducted during the development of a

system or component, usually in the development environment by the developer.

Functional testing: (1) Testing that ignores the internal mechanism of a system or component
and focuses solely on the outputs generated in response to selected inputs and execution
conditions. Contrast with: Structural testing. (2) Testing conducted to evaluate the compliance
of a system or component with specified functional requirements. See also: Performance
testing.

Hardware Configuration Item: Hardware items that include disks, disk drives, display screens,
keyboards, printers, boards, and chips.

Independent Verification and Validation (IV&V): Verification and validation performed by an

organization that is technically, managerially, and financially independent of the development
organization.

Installation and checkout phase: The period of time in the software life cycle during which a
software product is integrated into its operational environment and tested in this environment to
ensure that it performs as required.

Integration testing: Testing in which software components, hardware components, or both are
combined and tested to evaluate the interaction between them. See also: System testing; Unit
testing.

Load testing: Testing that studies the behavior of the program when it is working at its limits.
See also: Stress Testing.

Operational testing: Testing conducted to evaluate a system or component in its operational

environment.

Path testing (coverage): Testing that is designed to execute all or selected paths through a
computer program.

Pass/Fail criteria: Decision rules used to determine whether a software item or software feature
passes or fails a test.

Performance testing: Testing conducted to evaluate the compliance of a system or component

with specified performance requirements. See also: Functional testing.

6 v. 1.0 2006
 System Testing Document

Quality Assurance (QA): (1) The process of evaluating overall project performance on a regular
basis to provide confidence that the project will satisfy the relevant quality standards. (2) The
organizational unit that is assigned responsibility for quality assurance.

Quality Control (QC): (1) The process of monitoring specific project results to determine if they
comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory
performance. (2) The organizational unit that is assigned responsibility for quality control.

Quality Management (QM): The processes required to ensure that the project would satisfy the
needs for which it was undertaken.

Regression testing: Selective retesting of a system or component to verify that modifications

have not caused unintended effects and that the system or component still complies with its
specified requirements.

Scenario: (1) A description of a series of events that could be expected to occur simultaneously
or sequentially. (2) An account or synopsis of a projected course of events or actions.

Software item: Source code, object code, job control code, control data, or a collection of items.

Stress testing: Testing conducted to evaluate a system or component at or beyond the limits of
its specified requirements. See also: Load testing.

Structural testing: Testing that takes into account the internal mechanism of a system or
component. Types include branch testing, path testing, statement testing. Contrast with:
Functional testing.

System testing: Testing conducted on a complete, integrated system to evaluate the system’s
compliance with its specified requirements. See also: Integration testing; Unit testing.

Test: An activity in which a system or component is executed under specified conditions, the
results are observed or recorded, and an evaluation is made of some aspect of the system or
component.

Test case specification: A document specifying inputs, predicted results, and a set of execution
conditions for a test item.

Test design specification: Documentation specifying the details of the test approach for a
software feature or combination of software features and identifying the associated tests.

Test Incident Report (TIR): A document reporting on any event that occurs during the testing
process that requires investigation.

Test item: A software item that is an object of testing.

Test log: A chronological record of relevant details about the execution tests.

Test phase: The period of time in the life cycle during which components of a system are
integrated, and the product is evaluated to determine whether or not requirements have been
satisfied.

Test plan: A document describing the scope, approach, resources, and schedule of intended
testing activities. It identifies test items, the features to be tested, the testing tasks, who will do
each task, and any risks requiring contingency planning.

7 v. 1.0 2006
 System Testing Document

Test procedure: (1) Detailed instructions for the set-up, execution, and evaluation of results for
a given test case. (2) A document containing a set of associated instructions as in (1). (3)
Documentation specifying a sequence of actions for the execution of a test.

Test Readiness Review (TRR): A review conducted to evaluate preliminary test results for one
or more configuration items and verify that the test procedures for each configuration item are
complete, comply with test plans and descriptions, and satisfy test requirements. Verify that a
project is prepared to proceed to formal testing of the configuration item.

Test summary report: A document summarizing testing activities and results. It also contains an
evaluation of the corresponding test items.

Testability: (1) The degree to which a system or component facilitates the establishment of test
criteria and the performance of tests to determine whether those criteria have been met. (2) The
degree to which a requirement is stated in terms that permit establishment of test criteria and
performance of tests to determine whether those criteria have been met.

Testing: (1) The process of operating a system or component under specified conditions,
observing or recording the results, and making an evaluation of some aspect of the system or
component. (2)The process of analyzing a software item to detect the differences between
existing and required conditions (i.e., bugs) and to evaluate the features of the software items.
See also: Acceptance testing; Development testing; Integration testing; Operational
testing; Performance testing; Regression testing; System testing; Unit testing.

Unit Testing: The testing of individual hardware or software units or groups of related units (i.e.,
component, modules). See also: Integration testing; System testing.
 

4. TEST PLAN

8 v. 1.0 2006
 System Testing Document

4.1 Purpose

To prescribe the scope, approach, resources, and schedule of the testing activities. To identify
the items being tested, the features to be tested, the testing tasks to be performed.

4.2 Outline
A test plan shall have the following structure:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;

Details on the content of each section are contained in the following subclauses.

4.2.1 Test plan identifier

Specify the unique identifier assigned to this test plan.

4.2.2 Introduction
Summarize the software items and software features to be tested. The need for each item and its
history may be included.
References to the following documents, when they exist, are required in the highest level test
plan:
a) Project authorization;
b) Project plan;

4.2.3 Test items

Identify the test items including their version/revision level. Also specify characteristics of their
transmittal media that impact hardware requirements or indicate the need for logical or physical
transformations before testing can begin (e.g., programs must be transferred from tape to disk).
Supply references to the following test item documentation, if it exists:
Reference any incident reports relating to the test items.
Items that are to be specifically excluded from testing may be identified.

4.2.4 Features to be tested

Identify all software features and combinations of software features to be tested. Identify the test
design specification associated with each feature and each combination of features.

4.2.5 Features not to be tested

Identify all features and significant combinations of features that will not be tested and the
reasons.

4.2.6 Approach
Describe the overall approach to testing. For each major group of features or feature
combinations, specify the approach that will ensure that these feature groups are adequately
tested. Specify the major activities, techniques, and tools that are used to test the designated
groups of features.
Specify the minimum degree of comprehensiveness desired. Identify the techniques that will be
used to judge the comprehensiveness of the testing effort (e.g., determining which statements
have been executed at least once). Specify any additional completion criteria (e.g., error
frequency). The techniques to be used to trace requirements should be specified.

9 v. 1.0 2006
 System Testing Document

Identify significant constraints on testing such as test item availability, testing resource
availability, and deadlines.

4.2.7 Item pass/fail criteria

Specify the criteria to be used to determine whether each test item has passed or failed testing.

4.2.8 Suspension criteria and resumption requirements

Specify the criteria used to suspend all or a portion of the testing activity on the test items
associated with this plan. Specify the testing activities that must be repeated, when testing is
resumed.

4.2.9 Test deliverables

Identify the deliverable documents. The following documents should be included:
Test input data and test output data should be identified as deliverables. Test tools (e.g., module
drivers and stubs) may also be included.

4.2.10 Testing tasks

Identify the set of tasks necessary to prepare for and perform testing. Identify all inter-task
dependencies and any special skills required.

4.2.11 Environmental needs

Specify both the necessary and desired properties of the test environment. This specifications
should contain the physical characteristics of the facilities including the hardware, the
communications and system software, the mode of usage (e.g., stand-alone), and any other
software or supplies needed to support the test. Also specify the level of security that must be
provided for the test facilities, system software, and proprietary components such as software,
data, and hardware.

5. TEST CASE SPECIFICATION

5.1 Test case specification identifier
Specify the unique identifier assigned to this test case specification.

10 v. 1.0 2006
 System Testing Document

5.2 Test items

Identify and briefly describe the items and features to be exercised by this test case. For each
item, consider supplying references to the following test item documentation:

5.3 Input specifications

Specify each input required to execute the test case. Some of the inputs will be specified by
value (with tolerances where appropriate), while others, such as constant tables or transaction
files, will be specified by name. Identify all appropriate databases, files, terminal messages,
memory resident areas, and values passed by the operating system.
Specify all required relationships between inputs (e.g., timing).

5.4 Output specifications

Specify all of the outputs and features (e.g., response time) required of the test items. Provide
the exact value (with tolerances where appropriate) for each required output or feature.

5.5 Environmental needs

5.5.1 Hardware
Specify the characteristics and configurations of the hardware required to execute this test case.

5.5.2 Software
Specify the system and application software required to execute this test case. This may include
system software such as operating systems, compilers, simulators, and test tools. In addition, the
test item may interact with application software.

5.5.3 Other
Specify any other requirements such as unique facility needs or specially trained personnel.

5.6 Special procedural requirements

Describe any special constraints on the test procedures that execute this test case. These
constraints may involve special set up, operator intervention, output determination procedures,
and special wrap up.

5.7 Intercase dependencies

List the identifiers of test cases that must be executed prior to this test case. Summarize the
nature of the dependencies.

6. TEST PROCEDURE SPECIFICATION

6.1 Test procedure specification identifier
Specify the unique identifier assigned to this test procedure specification.

11 v. 1.0 2006
 System Testing Document

6.2 Purpose
Describe the purpose of this procedure. If this procedure executes any test cases, provide a
reference for each of them.

6.3. Test Procedure

Use the appropriate field as applicable.
6.3.1. Start
Describe the actions necessary to begin execution of the procedure.
6.3.2. Proceed
Describe any actions necessary during execution of the procedure.
6.3.3. Measure
Describe how the test measurements will be made (e.g., describe how remote terminal response
time is to be measured using a network simulator).
6.3.4. Shut down
Describe the actions necessary to suspend testing, when unscheduled events dictate.
6.3.5. Restart
Identify any procedural restart points and describe the actions necessary to restart the procedure
at each of these points.
6.3.6. Stop
Describe the actions necessary to bring execution to an orderly halt.
6.3.7. Wrap up
Describe the actions necessary to restore the environment.
6.3.8. Contingencies
Describe the actions necessary to deal with anomalous events that may occur during execution.

6.4. Procedure results

For each execution, record the visually observable results (e.g., error messages generated,
aborts, and requests for operator action). Also record the location of any output (e.g., reel
number). Record the successful or unsuccessful execution of the test.

6.5. Anomalous events

Record what happened before and after an unexpected event occurred (e.g., A summary display
was requested and the correct screen displayed, but response seemed unusually long. A
repetition produced the same prolonged response). Record circumstances surrounding the
inability to begin execution of a test procedure or failure to complete a test procedure (e.g., a
power failure or system software problem).

6.6. Variances
Report any variances of the test items from their design specifications. Indicate any variances
from the test plan, test designs, or test procedures. Specify the reason for each variance.

6.7. Summary of results

Summarize the results of testing. Identify all resolved incidents and summarize their resolutions.
Identify all unresolved incidents.

12 v. 1.0 2006