Test Summary Report


Test summary report is a formal document that summarizes the results of all testing efforts for a particular testing cycle of a project / module or a sub module. Generally, test leads or test managers prepare this document at the end of testing cycle. Some test managers prepares it at the end of project. 

I would recommend to prepare it after completion of each test cycle so that correct summary of the entire testing effort & more importantly health of application can be presented to relevant stakeholders. and at the end f project, you should publish a test closure report...very similar to project closure report.
Test Summary Report
  • All relevant stakeholders of the Project will be able to see the health of AUT (application under test). 
  • It will help them to take necessary steps proactively, if required.
  • It will to justify the testing effort that testing team is putting in the project.
  • It will help in building more mature process
  • It should be published after every test run cycle
  • It should have relevant metrics like Cost of finding a defect in testing, Test Case Adequacy, Test Case Effectiveness, Test Efficiency, Effort Variance, Schedule Variance, Schedule Slippage, Rework Effort Ratio, Review Effort Ratio, Weighted Defect Density
  • Mention all testing activities
  • All reports should be maintained in a document repository system
Contents of a Test summary report:

  • Name of project
  • Release No.
  • Reference documents: <Reference can be given of test planning document or test strategy document or project plan>
  • Target Audience: <Who all will be the recipients of this report>
  • Test Cycle:
Testing Type / Level: <Mention testing type / level like unit testing or system testing or integration testing or it may be a functional testing or performance testing etc>

Test Suite Data:
  • Number of test suites planned.
  • No of test suites executed
  • No of test suites could not be executed <Categorize it in two types: Due to some show stopper or due to some other reasons>
Test Case Data:
  • Number of test cases planned.
  • Number and percentage of test cases implemented.
  • Number and percentage of test cases executed.
  • Number and percentage of test cases passed.
  • Number and percentage of test cases failed (total and by severity).
Defect Data:
  • Total open bugs
  • New bugs found
  • Open bugs of previous release
  • Reopened bugs
  • Bugs marked as "Not a Bug"
  • Bugs marked as "Deferred"
Risks / open issues / support required: <Mention here all potential risks and current open issues with assignment of action items to specific stakeholder. Mention the details of support required, if any.>

Deviations from signed off test plan: <if any>

Some other information can be part of test summary report:
  • Testing team details.
  • Testing dates
  • Test team locations (if working from different remote locations)
  • Traceability matrix can also be attached in test summary report
  • Mention the test tracking tool used, test results location etc.
Remember to appreciate the good work done by development team and their support. 

No comments:

Post a Comment