Test Report
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (66.27 KB, 2 trang )
1 Test Report
A Test Report is a document that is prepared once the testing of a software product is complete and the
delivery is to be made to the customer. This document would contain a summary of the entire project
and would have to be presented in a way that any person who has not worked on the project would also
get a good overview of the testing effort.
Contents of a Test Report
The contents of a test report are as follows:
Executive Summary
Overview
Application Overview
Testing Scope
Test Details
Test Approach
Types of testing conducted
Test Environment
Tools Used
Metrics
Test Results
Test Deliverables
Recommendations
These sections are explained as follows:
1.1 Executive Summary
This section would comprise of general information regarding the project, the client, the
application, tools and people involved in such a way that it can be taken as a summary of the
Test Report itself (i.e.) all the topics mentioned here would be elaborated in the various sections
of the report.
1. Overview
This comprises of 2 sections – Application Overview and Testing Scope.
Application Overview – This would include detailed information on the application under test,
the end users and a brief outline of the functionality as well.
Testing Scope – This would clearly outline the areas of the application that would / would not
be tested by the QA team. This is done so that there would not be any misunderstandings
between customer and QA as regards what needs to be tested and what does not need to be
tested.
This section would also contain information of Operating System / Browser combinations if
Compatibility testing is included in the testing effort.
2. Test Details
This section would contain the Test Approach, Types of Testing conducted, Test Environment
and Tools Used.
Test Approach – This would discuss the strategy followed for executing the project. This could
include information on how coordination was achieved between Onsite and Offshore teams,
any innovative methods used for automation or for reducing repetitive workload on the testers,
how information and daily / weekly deliverables were delivered to the client etc.
Types of testing conducted – This section would mention any specific types of testing
performed (i.e.) Functional, Compatibility, Performance, Usability etc along with related
specifications.
Test Environment – This would contain information on the Hardware and Software
requirements for the project (i.e.) server configuration, client machine configuration, specific
software installations required etc.
Tools used – This section would include information on any tools that were used for testing the
project. They could be functional or performance testing automation tools, defect management
tools, project tracking tools or any other tools which made the testing work easier.
3. Metrics
This section would include details on total number of test cases executed in the course of the
project, number of defects found etc. Calculations like defects found per test case or number of
test cases executed per day per person etc would also be entered in this section. This can be
used in calculating the efficiency of the testing effort.
4. Test Results
This section is similar to the Metrics section, but is more for showcasing the salient features of
the testing effort. Incase many defects have been logged for the project, graphs can be
generated accordingly and depicted in this section. The graphs can be for Defects per build,
Defects based on severity, Defects based on Status (i.e.) how many were fixed and how many
rejected etc.
5. Test Deliverables
This section would include links to the various documents prepared in the course of the testing
project (i.e.) Test Plan, Test Procedures, Test Logs, Release Report etc.
6. Recommendations
This section would include any recommendations from the QA team to the client on the product
tested. It could also mention the list of known defects which have been logged by QA but not
yet fixed by the development team so that they can be taken care of in the next release of the
application.
