Test Completion Report: [Project or release name]

Test completion report for a project, release or test level. The structure follows the test completion report information item of ISO/IEC/IEEE 29119-3: summary of testing, deviations from the plan, completion evaluation, metrics, residual risks, lessons learned and a recommendation. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Summary and recommendation
2. Testing performed
3. Deviations from the test plan
4. Test completion evaluation
5. Test metrics
6. Defects
7. Residual risks
8. Test deliverables and archive
9. Lessons learned
10. Sign-off

1. Summary and recommendation

1.1 Recommendation

[Release / Release with conditions / Do not release]

Example: Release with conditions. All high-risk features passed; four of seven completion criteria are fully met, two are met with approved exceptions and one is not met (see RR-01); one severity-2 defect (BUG-3412) remains open with a documented workaround and a fix scheduled for 4.2.1 within 10 days.

1.2 Key facts

1.3 Conditions attached to the recommendation

• [Condition, for example: hotfix 4.2.1 with BUG-3412 fix released by YYYY-MM-DD.]
• [Condition, for example: support team briefed on the workaround before go-live.]

2. Testing performed

2.1 Features not tested

2.2 Test environment observations

Record availability problems, configuration differences from production and data issues that affected the results, so readers can judge how far the results carry over to production.

• Example: System test environment unavailable for 1.5 days in week 3 (database migration failure); cycle 2 extended by one day.
• Example: Payment sandbox does not simulate issuer timeouts; timeout handling tested with a stub only.
• [Observation and its effect on results.]

3. Deviations from the test plan

4. Test completion evaluation

5. Test metrics

5.1 Execution summary by feature area

5.2 Defect density

Defect density normalises defects by size so components can be compared:

$\text{Defect density} = \frac{\text{defects found}}{\text{size in KLOC changed}}$

Example interpretation: Pricing density more than doubled; the rewrite of the rule engine is the likely cause and is listed as a residual risk.

5.3 Defect trend

Defects opened and closed per week show whether the product was stabilising at the end of testing. A closing rate above the opening rate for the final two weeks is expected before release.

Example interpretation: The open count peaked in week 2, when cycle 1 results were triaged, and fell in each of the last three weeks. The closing rate exceeded the opening rate from week 3 onward, which supports the view that the product stabilised before the release decision.

5.4 Requirements coverage

Coverage shows how much of the agreed test basis has evidence behind it. It is reported separately for must-have requirements because the release decision depends on them.

Requirements not covered are listed with the reason in section 7 or in the deviation log in section 3.

5.5 Other measures

6. Defects

6.1 Summary by severity

6.2 Outstanding defects

7. Residual risks

8. Test deliverables and archive

Test environments released: [system test environment returned to platform team on YYYY-MM-DD; test data purged].

9. Lessons learned

10. Sign-off

By approving this report, the signatories confirm that the testing described has been completed or deviations accepted, and that the residual risks and outstanding defects listed above are accepted for the release decision recorded below.

Standard and licence note

Structure aligned with ISO/IEC/IEEE 29119-3, Software and systems engineering: Software testing, Part 3: Test documentation, test completion report information item. This template is original text written for this collection and reproduces no text from the standard; obtain the standard from ISO, IEC or IEEE for its normative requirements. Template licence: MIT.