Test Reports

A final test report should be prepared at the conclusion of each test activity. This might include

· Individual Project Test Report (e.g., a single software system)
· Integration Test Report
· System Test Report
· Acceptance Test Report


The test reports are designed to document the results of testing as defined in the test plan. Without a well-developed test plan, which has been executed in accordance with its criteria, it is difficult to develop a meaningful test report.

It is designed to accomplish three objectives:
· Define the scope of testing - normally a brief recap of the test plan;
· Present the results of testing; and
· Draw conclusions and make recommendations based on those results

The test report may be a combination of electronic data and hard copy. For example, if the function test matrix is maintained electronically, there is no reason to print that, as the paper report will summarize that data, draws the appropriate conclusions, and present recommendations.

The test report has one immediate and three long-term purposes. The immediate purpose is to provide information to the customers of the software system so that they can determine whether the system is ready for production: and if so, to assess the potential consequences and initiate appropriate actions to minimize those consequences.

The first of the three long-term uses is for the project to trace problems in the event the application malfunctions in production. Knowing which functions have been correctly tested and which ones still contain defects can assist in taking corrective action.

The second long-term purpose is to use the data to analyze the rework process for making changes to prevent defects from occurring in the future. Accumulating the results of many test reports to identify which components of the rework process are detect-prone does this. These defect-prone components identify tasks/steps that, if improved, could eliminate or minimize the occurrence of high-frequency defects.

The third long-term purpose is to show what was accomplished.

Individual Project Test Report

These reports focus on individual projects (e.g., software system). When different testers test individual projects, they should prepare a report on their results.

Integration Test Report

Integration testing tests the interfaces between individual projects. A good test plan will identify the interfaces and institute test conditions that will validate interfaces. Given this, the interface report follows the same format as the individual Project Test report, except that the conditions tested are the interfaces.

System Test Report

A system test plan standard that identified the objectives of testing, what was to be tested, how it was to be tested and when tests should occur. The System Test report should present the results of executing that test plan. If this is maintained electronically, it need only be referenced, not included in the report.

Acceptance Test Report

There are two primary objectives for testing. The first is to ensure that the system as implemented meets the real operating needs of the user or customer. If the defined requirements are those true needs, the testing should have accomplished this objective. The second objective is to ensure that the software system can operate in the real-world user environment, which includes people skills and attitudes, time pressures, changing business conditions, and so forth.


Eight Interim Reports:

1. Functional Testing Status
2. Functions Working Timeline
3. Expected verses Actual Defects Detected Timeline
4. Defects Detected verses Corrected Gap Timeline
5. Average Age of Detected Defects by Type
6. Defect Distribution
7. Relative Defect Distribution
8. Testing Action
Functional Testing Status Report

This report will show percentages of the functions, which have been:

· Fully Tested
· Tested With Open Defects
· Not Tested

Functions Working Timeline report

This report will show the actual plan to have all functions working verses the current status of functions working. An ideal format could be a line graph.

Expected verses Actual Defects Detected report

This report will provide an analysis between the number of defects being generated against the expected number of defects expected from the planning stage

Defects Detected verses Corrected Gap report

This report, ideally in a line graph format, will show the number of defects uncovered verses the number of defects being corrected and accepted by the testing group. If the gap grows too large, the project may not be ready when originally planned.





Average Age Detected Defects by Type report

This report will show the average outstanding defects by type (severity 1, severity 2, etc.). In the planning stage, it is benefic determine the acceptable open days by defect type.

Defect Distribution report

This report will show the defect distribution by function or module. It can also include items such as numbers of tests completed.

Relative Defect Distribution report

This report will take the previous report (Defect Distribution) and normalize the level of defects. An example would be one application might be more in depth than another, and would probably have a higher level of defects. However, when normalized over the number of functions or lines of code, would show a more accurate level of defects.

Testing action report

This report can show many different things, including possible shortfalls in testing. Examples of data to show might be number of severity defects, tests that are behind schedule, and other information that would present an accurate testing picture