<<Project Name & Version Here>>

Test Report
<<Date of Last Revision Here (Should match last entry below)>> <<Authors Name Here>> <<Company/Business Unit Name Here>> Test Group
When printing this document, the Comments checkbox (via Tools-Options-Print tab) is checked so that youll get the instructions that the comments contain. You should disable this option when doing the version of the Test Report the is made publicly available. Of course, you will also remove this text.

Template Revision History (Note: to be cleared out when issue a Test Report as dont need readers seeing the history for this Template version)
Re v
Date Author Dan Gawarecki Dan G. Dan G. Dan G

Change Description
Original distribution Incorporate suggestions by others, & misc. additions and corrections. Added Section 1.1 Size Measurements, Title Page, & Table of Contents. Section 4.3, item 2 changed to report Actual as well as Estimate test hours. Section 3- changed Opened to Total Opened and added new Still Open, break by severity item, Made table out of information asked for in Section 4.2 Builds Changed Header Title text from Test Plan to Test Report Implemented Test Council Recommendations: 1.1, Remove item 1 as no one using PEAQ category sizes anymore 2, added more details to original items- they are now # 1-4, and 6, added item that is now #5 3,

1.0 ?? 1.1 Feb 1998 1.2 Oct 14,

1998 1998

1.3 Nov. 2, 1.4 Nov 3, 1.5

1998 99-Sep03

Lyn B Dan G.

Test Report for <<Project Name Here>> _____________________________________________________________________________________

added at the time to item 6. 4.1, made into table adding Planned and Actual for Column Names. 4.3, for item #2, modified to be a table so Planned and Actual are easy to read. Added italic instructions to title page Revised 5 1st paragraph, added 2nd paragraph.

Document Location
/var/www/apps/conversion/tmp/scratch_6/140973979.doc

_____________________________________________________________________________________ Page ii of 6 Nov. 4, 1998

Test Report for <<Project Name Here>> _____________________________________________________________________________________

Table of Contents
1. OVERVIEW
1.1. Size Measurements

1
1

2. SYSTEM VERIFICATION TEST (SVT) TEST CASES 3. PROBLEM TRACKING REPORT (PTR) SUMMARY 4. OTHER METRICS
4.1. Dates 4.2. Software Builds 4.3. People & Time 4.4. Beta Test results / summary

1 1 2
2 2 2 2

5. GENERAL COMMENTS

_____________________________________________________________________________________ Page iii of 6 Nov. 4, 1998

Test Report for <<Project Name Here>> _____________________________________________________________________________________

1. Overview
A short paragraph telling what project, including version number, this report is for, the project number and a general comment about the testing status (passed with little difficulty, had lots of problems, etc.) Hopefully the entire report, excluding any attached charts (e.g., from Section 3) is only 1-2 pages long.

1.1. Size Measurements

Software Size Estimates vs. Actual (identify units of measure- Thousand Source Lines of Code- KSLOC, number of classes, objects, Function Points, etc).

2. System Verification Test (SVT) Test Cases

This section records the status of Test Cases for System Verification Test. This provides some sizing of the project and helps future estimates. Feel free to record any comments about Test Cases or related issues here. Ideally, youd have an S-curve to embed in the document! 1. # Test Cases Planned (i.e., written up in plan) 2. # Test Cases Executed (i.e., attempted to run) 3. # Test Cases Passed on 1st execution attempt 4. # Test Cases Failed on 1st execution attempt 5. # Executions of Test Cases (i.e., summation of the number of times executed each test casedo this because may execute a test case more than once. This metric needed to show effort and explain why a test cycle may be longer than planned. This item could be considered optional as it is something that a mature process would provide- which Im not sure we have entirely. The other 5 items should be done first and done well before attempting to provide this metric). 6. What test cases were planned but *NOT* executed (perhaps explain why?)

3. Problem Tracking Report (PTR) Summary

Similar to the previous Test Case section, this area records the status of PTRs. Again, feel free to record any comments about the PTRs you wish. You should be able to get charts for items #1, 2 and the data for items #3 & 4 from Tracker. 1. PTR Trendline2. Severity breakdown/distribution 3. #PTRs Total Opened 4. #PTRs Closed 5. #PTRs Still Open (breakdown by severity) 6. Any open issues still remaining at the time of release (e.g., explain why you might be shipping with an open Severity 2 PTR). Important to reference the actual PTR number(s) here.

_____________________________________________________________________________________ Page 1 of 6 Nov. 4, 1998

Test Report for <<Project Name Here>> _____________________________________________________________________________________

4. Other Metrics
4.1. Dates
1. 2. DATE DESCRIPTION Date testing Started: this is the first day of Entrance Testing Date Testing Ended: this is the last day of Regression Testing. PLANNED ACTUAL

4.2.

Software Builds
VERSION 1. 2. 3. First Build done Last Build done # Builds done during testing period DATE DONE

Please fill in the 5 cells in the following table:

4.3. People & Time

1. 2. List all those people involved in testing the product during this project. Record Estimated and Actual number of hours spent testing (this is time executing test cases, not playing around with the product or testing by exploration PLANNED Actual Hours Spent Test ACTUAL

4.4. Beta Test results / summary

Note if there was or was not a Beta test and if so, any results (good or bad). Refer to separate Beta Test Report if available. If there is none, mention any testing customers performed.

5. General Comments
This is a catch-all section for you to add any comments you feel important. You might reemphasize any open issues listed in section 3, major stumbling blocks in the testing process, any areas NOT tested, unique situations, etc. Mention what documents, manuals, specifications etc. that were not tested This is also your opportunity to comment on what improvements should be made (back it up with data, or at least a rationalization) that will improve product quality in future versions of this product or other products.

_____________________________________________________________________________________ Page 2 of 6 Nov. 4, 1998