Test Specification
Test SpecificationProject Name
Test Specification
The Test Specification is the technical outline for conducting the testing process. It defines the input, output, environment, and procedural guidelines at the solution level as well as for each test case.
The paragraphs written in the “Comment” style are for the benefit of the person writing the document and should be removed before the document is finalized.
September 11, 1998
Revision Chart
This chart contains a history of this document’s revisions. The entries below are provided solely for purposes of illustration. Entries should be deleted until the revision they refer to has actually been created.
The document itself should be stored in revision control, and a brief description of each version should be entered in the revision control system. That brief description can be repeated in this section.
Version / Primary Author(s) / Description of Version / Date CompletedDraft / TBD / Initial draft created for distribution and review comments / TBD
Preliminary / TBD / Second draft incorporating initial review comments, distributed for final review / TBD
Final / TBD / First complete draft, which is placed under change control / TBD
Revision 1 / TBD / Revised draft, revised according to the change control process and maintained under change control / TBD
etc. / TBD / TBD / TBD
Preface
The preface contains an introduction to the document. It is optional and can be deleted if desired.
Introduction
This Test Specification is the technical outline for conducting the testing process. It defines the input, output, environment, and procedural guidelines at the solution level as well as for each test case. The Test Specification is developed using the framework of the Test Plan (created during the Planning Phase) and the contents of the functional specifications.
Justification
Test specifications and test cases help to ensure that project teams test the functions, features, and performance of solutions rigorously and completely with a minimum of ambiguity. Test specifications and test cases become the basis for regression testing and evaluation when teams make changes necessary to correct errors, improve performance, and meet new requirements.
Team Role Primary
Test is responsible for the creation and delivery of the Test Specification and Test Case documents during the Development phase. Development is instrumental in the review of the Test Specification and Test Case document to ensure testing covers all design elements.
Team Role Secondary
Program Management assists in removing barriers for Test to complete all the objectives defined in the test plans, and continues to manage delivery in accordance to the schedule. Product Management needs to be aware of test results to communicate the build status to external stakeholders. Release Management should be cognizant of test results that indicate any operational, support and deployment environmental concerns that could jeopardize final delivery. User Experience should be aware of test results to ensure that user experience requirements are being adequately addressed throughout the test process.
Contents
New paragraphs formatted as Heading 1, Heading 2, and Heading 3 will be added to the table automatically. To update this table of contents in Microsoft Word, put the cursor anywhere in the table and press F9. If you want the table to be easy to maintain, do not change it manually.
1.Introduction......
1.1Test Specification Summary......
1.2Definitions, Acronyms, and Abbreviations......
1.3References......
2.Input Specifications......
3.Output Specifications......
4.Test Environment......
5.Special Procedural Requirements......
6.Inter-case Dependencies......
7.Test Cases......
7.1Test Case Item – 1......
7.1.1Feature A......
7.1.2Feature B......
7.1.3Test Case 1 References......
7.2Test Case Item – 2......
7.2.1Feature A......
7.2.2Feature B......
7.2.3Test Case 2 References......
8.Index......
9.Appendices......
List of Figures
New figures that are given captions using the Caption paragraph style will be added to the table automatically. To update this table of contents in Microsoft Word, put the cursor anywhere in the table and press F9. If you want the table to be easy to maintain, do not change it manually.
This section can be deleted if the document contains no figures or if otherwise desired.
Error! No table of figures entries found.
1.Introduction
This section should provide an overview of the entire document. No text is necessary between the heading above and the heading below unless otherwise desired.
1.1Test Specification Summary
This section provides an overall summary of the contents of this document.
Some project participants may need to know only the highlights of the review, and summarizing creates that user view. It also enables the full reader to know the essence of the document before they examine the details.
1.2Definitions, Acronyms, and Abbreviations
Provide definitions or references to all the definitions of the special terms, acronyms and abbreviations used within this document.
1.3References
List all the documents and other materials referenced in this document. This section is like the bibliography in a published book.
2.Input Specifications
The Input Specifications section specifies the inputs needed to execute all the test cases for the solution. This may include keyboard, mouse, data files, or other computer or user activities. The input should be described not only by name but also include attributes such as definitions, values, ranges, data structures, protocols, interfaces, memory layout, databases, or files.
Teams test and evaluate solutions in an orderly manner, employing specific test cases to test the correctness of functions and to evaluate performance of all kinds. Test cases consist of a well-defined input set that will produce corresponding sets of expected output.
3.Output Specifications
The Output Specifications section specifies the expected outputs from this test. The output set should include data, timing information, screen messages, logs, databases, memory structures, files, screens, etc. In those cases in which an actual test output can differ slightly from an expected output, include the range of acceptability for the differences for each output.
For each test input set, the project team has defined a corresponding set of expected output. Defining, inspecting, and approving the output set prior to a test enables the team to examine actual test results and quickly determine if a test was successful and in many cases to determine the cause of incorrect output.
4.Test Environment
The Test Environment section describes the test environment’s characteristics and configuration. This description should include hardware, software, tools, other applications, etc. This description should be sufficiently complete so that the test environment will produce results that ensure the solution will be successful in its operational environment.
Testing requires a test environment that will produce the expected results. In many cases tests require special test environments, and in other cases tests can be conducted in operational environments. Repeating tests requires keeping as many test parameters, such as a test environment, constant. Software inspections and project reviews always examine test environments. Documenting the test environment makes this possible.
5.Special Procedural Requirements
The Special Procedural Requirements section describes any special requirements to ensure that the test has integrity. This may include setup processes, restoring the environment to known baseline before and after test, and logging or monitoring requirements.
Teams apply testing methods within prescribed testing procedures that may be unique to test cases.
6.Inter-case Dependencies
The Inter-case Dependencies section identifies the dependencies that exist among the test cases, showing which test cases must be performed first and which follow.
Many functions depend upon input data produced as output from other functions previously tested. This section lists those test cases and identifies the test input data each earlier test case provides to this test case.
7.Test Cases
The Test Cases section identifies every unique test case that will be conducted. These may be organized by functions, features, and performance items to be tested.
Teams test each function, each feature, and each performance requirement defined by requirements and functional specifications. This section lists the test items described in detail below.
7.1Test Case Item – 1
The Test Case Item - 1 section identifies the testing item that is the subject of the test case.
7.1.1Feature A
The Feature A section briefly describes the overall feature and its design.
7.1.1.1Expected Behavior
The Expected Behavior section describes the feature’s expected behavior as intended by the requirements and design specifications. It also provides a definition of the range of acceptable differences between the expected and actual behavior.
7.1.1.2Expected Performance
The Expected Performance section describes the feature’s expected performance as intended by the requirements and design specifications. It also provides a definition of the range of acceptable differences between the expected and actual performance.
7.1.1.3Expected Reliability
The Expected Reliability section describes the feature’s expected reliability as intended by the requirements and design specifications. It also provides a definition of the range of acceptable differences between the expected and actual performance.
7.1.1.4Additional Notes/Issues
Use the Additional Notes/Issues section for any additional information that is not specified in the prior sections.
7.1.2Feature B
7.1.2.1Expected Behavior
The Expected Behavior section describes the feature’s expected behavior as intended by the requirements and design specifications. It also provides a definition of the range of acceptable differences between the expected and actual behavior.
7.1.2.2Expected Performance
The Expected Performance section describes the feature’s expected performance as intended by the requirements and design specifications. It also provides a definition of the range of acceptable differences between the expected and actual performance.
7.1.2.3Expected Reliability
The Expected Reliability section describes the feature’s expected reliability as intended by the requirements and design specifications. It also provides a definition of the range of acceptable differences between the expected and actual performance.
7.1.2.4Additional Notes/Issues
Use the Additional Notes/Issues section for any additional information that is not specified in the prior sections.
7.1.3Test Case 1 References
The Test Case 1 References section provides a traceability mechanism from the requirements documents, functional specifications, and other documents (user guides, operations guides, and installation guides) that were used to develop the test case.
7.2Test Case Item – 2
The Test Case Item - 1 section identifies the testing item that is the subject of the test case.
7.2.1Feature A
The Feature A section briefly describes the overall feature and its design.
7.2.1.1Expected Behavior
The Expected Behavior section describes the feature’s expected behavior as intended by the requirements and design specifications. It also provides a definition of the range of acceptable differences between the expected and actual behavior.
7.2.1.2Expected Performance
The Expected Performance section describes the feature’s expected performance as intended by the requirements and design specifications. It also provides a definition of the range of acceptable differences between the expected and actual performance.
7.2.1.3Expected Reliability
The Expected Reliability section describes the feature’s expected reliability as intended by the requirements and design specifications. It also provides a definition of the range of acceptable differences between the expected and actual performance.
7.2.1.4Additional Notes/Issues
Use the Additional Notes/Issues section for any additional information that is not specified in the prior sections.
7.2.2Feature B
7.2.2.1Expected Behavior
The Expected Behavior section describes the feature’s expected behavior as intended by the requirements and design specifications. It also provides a definition of the range of acceptable differences between the expected and actual behavior.
7.2.2.2Expected Performance
The Expected Performance section describes the feature’s expected performance as intended by the requirements and design specifications. It also provides a definition of the range of acceptable differences between the expected and actual performance.
7.2.2.3Expected Reliability
The Expected Reliability section describes the feature’s expected reliability as intended by the requirements and design specifications. It also provides a definition of the range of acceptable differences between the expected and actual performance.
7.2.2.4Additional Notes/Issues
Use the Additional Notes/Issues section for any additional information that is not specified in the prior sections.
7.2.3Test Case 2 References
The Test Case 1 References section provides a traceability mechanism from the requirements documents, functional specifications, and other documents (user guides, operations guides, and installation guides) that were used to develop the test case.
8.Index
The index is optional according to the IEEE standard. If the document is made available in electronic form, readers can search for terms electronically.
9.Appendices
Include supporting detail that would be too distracting to include in the main body of the document.
Test_Specification.doc (06/19/03)Page 1