Directions for using template:
Read the Guidance (Arial blue font in brackets) to understand the information that should be placed in each section of this template. Then delete the Guidance and replace the placeholder within <<Begin text here>> with your response. There may be additional Guidance in the Appendix of some documents, which should also be deleted once it has been used.
Some templates have four levels of headings. They are not indented, but can be differentiated by font type and size:
You may elect to indent sections for readability.
|
Author |
|
|
Author Position |
|
|
Date |
|
Version: 1.0
Ó 2002 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft and Visual Basic are either registered trademarks or trademarks of Microsoft in the United States and/or other countries.
Change Record
|
Date |
Author |
Version |
Change Reference |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reviewers
|
Name |
Version Approved |
Position |
Date |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Distribution
|
Name |
Position |
|
|
|
|
|
|
|
|
|
|
|
|
Document Properties
|
Item |
Details |
|
Document Title |
Test Specification and Test Cases |
|
Author |
|
|
Creation Date |
|
|
Last Updated |
|
Special Procedural Requirements
[Introduction to the template
Description: 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.}]
[Description: This section provides an overall summary of the contents of this document.
Justification: Many readers, especially the less technical project stakeholders, want only a general knowledge and understanding of the methods and tools a team employs to test a product, and this summary meets that need. The summary also serves as an overview of the entire document.]
<<Begin text here>>
[Description: 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.
Justification: 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.]
<<Begin text here>>
[Description: 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.
Justification: 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.]
<<Begin text here>>
[Description: 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.
Justification: 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.]
<<Begin text here>>
[Description: 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.
Justification: Teams apply testing methods within prescribed testing procedures that may be unique to test cases.]
<<Begin text here>>
[Description: 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.
Justification: 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.]
<<Begin text here>>
[Description: 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.
Justification: 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.]
[Description: The Test Case Item - 1 section identifies the testing item that is the subject of the test case.]
<<Begin text here>>
[Description: The Feature A section briefly describes the overall feature and its design.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: Use the Additional Notes/Issues section for any additional information that is not specified in the prior sections.]
<<Begin text here>>
[Description: The Feature B section briefly describes the overall feature and its design.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: Use the Additional Notes/Issues section for any additional information that is not specified in the prior sections.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: The Test Case 2 section identifies the testing item that is the subject of the test case.]
<<Begin text here>>
[Description: The Feature A section briefly describes the overall feature and its design.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: Use the Additional Notes/Issues section for any additional information that is not specified in the prior sections.]
<<Begin text here>>
[Description: The Feature B section briefly describes the overall feature and its design.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: 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.]
<<Begin text here>>
[Description: Use the Additional Notes/Issues section for any additional information that is not specified in the prior sections.]
<<Begin text here>>
[Description: The Test Case 2 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.]
<<Begin text here>>