The following aspects should be reflected in the test report:
- Software product that underwent testing
- The difference between actual and planned test efforts
- Difference between actual work output / labor costs and planned ones
- Defects that were found
- Defects that remained unresolved after the completion of testing, and resolution on them
Test summary report does not have to contain the results of each test run, at the same time it can refer to such results if they are somewhere accumulated and archived. The possibility to collect and archive all test results is one of the advantages of using serial test management tools. If this tool puts test results into a single document, then this document can be referenced in the report. Software quality assurance services need to be used each time when a new development project starts. Yes, the earlier you find the shortcomings the less expensive will be their repair.
One way to specify which product is being tested involves using of a set of final test logs for each test cycle. This method allows you to display the results of each test run without making a step-by-step report. Another useful report can be drawn up by compiling a complete set of data on test progress.
It is important to identify deviations from the test plan by determining the extent to which an actual testing process differs from an expected one, because the test plan clearly defines the scope of testing and a number of employees who will perform it, as well as how long this work will take to complete. It is particularly important to indicate which program areas were not fully covered by testing, as these areas may present risks to the quality of the software product and cause defects to appear in various parts of this app. If the testing is performed according the plan, this fact can be simply mentioned in the report. But if there are significant deviations from the plan, it is necessary to reflect them in a special application form.
The information is useful when accounting for the resources expended, and at the same time it is design intent necessary for further test planning.
Although the defect tracking database should contain a complete set of data on defects detected during the test, a summary of the types of defects found during the system tests should be included in the report. In this case, all parties interested in the development success will not need to access the defects database to obtain information about the progress of testing and the quality of the software product.