# 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*.

<!--
Guidance: How to use this template
- Write the report for the people who decide on release. Lead with the
  recommendation and the evidence; put detail in the later sections.
- Compare against the completion criteria in the test plan, criterion by
  criterion. "Testing went well" is not an evaluation.
- Be explicit about residual risk: what was not tested, what is still open,
  and who accepted it.
- Numbers must reconcile: executed = passed + failed, planned = executed + blocked + not run.
-->

## Document control

<!-- Guidance: Identify the report and the plan it closes. Status moves Draft -> In review -> Approved. -->

| Field | Value |
|---|---|
| Document ID | [TCR-PROJECT-001] |
| Project / release | [Project name] [release] |
| Scope of report | [Whole project / System test level / Performance testing] |
| Test plan closed | [TP-PROJECT-001 version x.y] |
| Reporting period | YYYY-MM-DD to YYYY-MM-DD |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Author | [@test-manager] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Test manager | [@name] | [Approved] | YYYY-MM-DD |
| Product owner | [@name] | [Release / Release with conditions / Do not release] | YYYY-MM-DD |
| Engineering lead | [@name] | [Decision] | YYYY-MM-DD |
| Release manager | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: A completion report is usually issued once; record re-issues after retests. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Draft for go/no-go meeting |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Updated after retest of BUG-3412; approved |

## Contents

<!-- Guidance: Keep in sync with headings. -->

1. [Summary and recommendation](#1-summary-and-recommendation)
2. [Testing performed](#2-testing-performed)
3. [Deviations from the test plan](#3-deviations-from-the-test-plan)
4. [Test completion evaluation](#4-test-completion-evaluation)
5. [Test metrics](#5-test-metrics)
6. [Defects](#6-defects)
7. [Residual risks](#7-residual-risks)
8. [Test deliverables and archive](#8-test-deliverables-and-archive)
9. [Lessons learned](#9-lessons-learned)
10. [Sign-off](#10-sign-off)

## 1. Summary and recommendation

<!-- Guidance: Half a page at most. State the recommendation, the two or three facts that support it, and any conditions. Decision makers may read only this section. -->

### 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

| Item | Value |
|---|---|
| Test cases planned / executed | [412 / 398] |
| Passed / failed / blocked | [389 / 9 / 6] |
| Must-have requirements covered by a passed test | [97 of 98 (99%)] |
| Defects found / fixed / rejected / open | [86 / 68 / 11 / 7] |
| Open by severity (S1 / S2 / S3 / S4) | [0 / 1 / 4 / 2] |
| Escaped defects from previous release found during this cycle | [2] |

### 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

<!-- Guidance: Summarise what was tested, at which levels, on which builds and environments. Point to the detailed test logs. -->

| Test sub-process | Builds tested | Environment | Period | Result |
|---|---|---|---|---|
| Unit and integration | All merges to `release/4.2` | CI | YYYY-MM-DD to YYYY-MM-DD | 3,412 automated tests, 100% pass on final build |
| System test cycle 1 | 4.2.0-rc1 | System test | YYYY-MM-DD to YYYY-MM-DD | 61 defects raised |
| System test cycle 2 | 4.2.0-rc3 | System test | YYYY-MM-DD to YYYY-MM-DD | Exit criteria met with exceptions |
| Performance | 4.2.0-rc3 | Performance | YYYY-MM-DD to YYYY-MM-DD | p95 within SLA at 120% forecast peak |
| UAT | 4.2.0-rc3 | UAT | YYYY-MM-DD to YYYY-MM-DD | Signed off by finance and operations |
| [Sub-process] | [Build] | [Env] | [Period] | [Result] |

### 2.1 Features not tested

| Feature or requirement | Reason | Consequence | Covered elsewhere |
|---|---|---|---|
| *Example:* Bulk export (SRS-FR-118) | Storage emulator unavailable in system test | Not verified end to end | Unit tests only; see RR-01 |
| *Example:* Legacy coupon import | Unchanged since 4.0, low risk | No regression run this cycle | Nightly automated suite |
| [Feature] | [Reason] | [Consequence] | [Where] |

### 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

<!-- Guidance: Every difference from the plan: scope cut, schedule slip, technique changed, environment substituted. Give the reason and the effect on confidence. -->

| ID | Planned | Actual | Reason | Effect on confidence | Approved by |
|---|---|---|---|---|---|
| DV-01 | *Example:* Soak test 8 hours | Soak test 4 hours | Environment shared with another release | Memory leaks with slow growth may be missed; production memory alert added | [@pm] |
| DV-02 | *Example:* Device lab covers 12 devices | 9 devices | Three devices failed | Android 12 low-end coverage reduced; beta channel monitoring extended | [@test-manager] |
| [DV-nn] | [Planned] | [Actual] | [Reason] | [Effect] | [@name] |

## 4. Test completion evaluation

<!-- Guidance: One row per completion criterion from the test plan. Use Met / Not met / Met with exception, and justify every exception. -->

| Criterion (from plan) | Target | Actual | Status | Comment |
|---|---|---|---|---|
| High-risk test cases executed | 100% | 100% | Met | |
| All planned test cases executed | >= 95% | 96.6% | Met | 14 low-priority cases not run |
| Pass rate of executed tests | >= 98% | 97.7% | Met with exception | 9 failures linked to 7 open S3/S4 defects |
| Open S1 defects | 0 | 0 | Met | |
| Open S2 defects | 0 or approved workaround | 1 with workaround | Met with exception | BUG-3412, see 6.2 |
| Must-have requirements covered by passed test | 100% | 99% | Not met | SRS-FR-118 blocked by environment, see 7 |
| Performance targets at forecast peak | Met | Met | Met | |

## 5. Test metrics

<!-- Guidance: Show the numbers behind the evaluation. Explain any trend that a reader could misread. -->

### 5.1 Execution summary by feature area

| Feature area | Planned | Executed | Passed | Failed | Blocked | Not run |
|---|---|---|---|---|---|---|
| *Example:* Checkout | 120 | 120 | 117 | 3 | 0 | 0 |
| *Example:* Promotions | 64 | 64 | 63 | 1 | 0 | 0 |
| *Example:* Account | 88 | 82 | 78 | 2 | 2 | 4 |
| *Example:* Warehouse | 140 | 132 | 131 | 3 | 4 | 4 |
| **Total** | **412** | **398** | **389** | **9** | **6** | **8** |

### 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}}$$

| Component | Defects found | KLOC changed | Density | Previous release |
|---|---|---|---|---|
| *Example:* Checkout UI | 31 | 12.4 | 2.5 | 1.8 |
| *Example:* Pricing service | 18 | 4.1 | 4.4 | 2.0 |
| *Example:* Orders API | 22 | 9.7 | 2.3 | 2.6 |
| [Component] | [n] | [KLOC] | [d] | [d] |

*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.

| Week | Opened | Closed | Open at end of week |
|---|---|---|---|
| W1 | 24 | 6 | 18 |
| W2 | 31 | 20 | 29 |
| W3 | 19 | 27 | 21 |
| W4 | 8 | 19 | 10 |
| W5 | 4 | 7 | 7 |

*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.

| Requirement class | Total | Covered by a passed test | Covered, test failed | Not covered | Coverage |
|---|---|---|---|---|---|
| Must-have | 98 | 97 | 0 | 1 | 99% |
| Should-have | 54 | 49 | 2 | 3 | 91% |
| Could-have | 21 | 15 | 0 | 6 | 71% |
| [Class] | [n] | [n] | [n] | [n] | [%] |

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

### 5.5 Other measures

| Measure | Value | Comment |
|---|---|---|
| Automated regression suite duration | [38 min] | Within 45-minute budget |
| Flaky tests quarantined | [3] | All tickets assigned |
| Defect detection percentage (previous release, 90 days) | [91%] | Target 90% |
| Test effort planned / actual (person-days) | [69 / 74] | Overrun from third retest cycle |

## 6. Defects

<!-- Guidance: List every open defect at release with the decision taken. Fixed defects are summarised by count only. -->

### 6.1 Summary by severity

| Severity | Found | Fixed and verified | Rejected or duplicate | Open |
|---|---|---|---|---|
| S1 Critical | 3 | 3 | 0 | 0 |
| S2 Major | 14 | 12 | 1 | 1 |
| S3 Minor | 41 | 33 | 4 | 4 |
| S4 Cosmetic | 28 | 20 | 6 | 2 |

### 6.2 Outstanding defects

| ID | Title | Severity | Priority | Workaround | Decision | Target fix |
|---|---|---|---|---|---|---|
| BUG-3412 | *Example:* Gift card plus promotion code shows wrong total until page refresh | S2 | P1 | Refresh summary page; charged amount is correct | Accept for release; fix in 4.2.1 | YYYY-MM-DD |
| BUG-3420 | *Example:* Sort by date ignores time zone on order history | S3 | P3 | None needed | Accept; backlog | 4.3 |
| [ID] | [Title] | [S] | [P] | [Workaround] | [Decision] | [Release or date] |

## 7. Residual risks

<!-- Guidance: What could still go wrong in production, given what was and was not tested. Each residual risk needs an owner who accepts it. -->

| ID | Residual risk | Source | Mitigation in production | Accepted by |
|---|---|---|---|---|
| RR-01 | *Example:* SRS-FR-118 (bulk export) not verified end to end | Blocked by environment | Feature flag off at launch; enable after verification in staging | [@product-owner] |
| RR-02 | *Example:* Slow memory growth beyond 4 hours not observed | DV-01 | Memory alert at 80%; automatic restart policy | [@sre-lead] |
| RR-03 | *Example:* Pricing engine defect density high | 5.2 | Extra monitoring of discount totals for 14 days | [@engineering-lead] |
| [RR-nn] | [Risk] | [Source] | [Mitigation] | [@name] |

## 8. Test deliverables and archive

<!-- Guidance: Where the evidence lives, so an auditor or the next team can find it. -->

| Deliverable | Location | Retention |
|---|---|---|
| Test plan and design specifications | [Repository path or wiki link] | [Two years] |
| Test runs and logs | [Test management tool project] | [Two years] |
| Defect reports | [Issue tracker filter] | [Indefinite] |
| Performance results | [Results bucket or report link] | [One year] |
| UAT sign-off | [Document link] | [Regulatory period] |

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

## 9. Lessons learned

<!-- Guidance: What to keep, what to change, with an owner and an action. Without actions, lessons are not learned. -->

| ID | Observation | Effect | Action | Owner | Due |
|---|---|---|---|---|---|
| LL-01 | *Example:* Contract tests caught 11 API breaking changes before system test | Saved roughly one test cycle | Extend contract testing to warehouse APIs | [@name] | YYYY-MM-DD |
| LL-02 | *Example:* Shared performance environment caused DV-01 | Reduced soak coverage | Book environment at release planning | [@name] | YYYY-MM-DD |
| LL-03 | *Example:* UAT testers had no training on defect reporting | 20% of UAT reports needed rework | Add 1-hour onboarding to UAT plan | [@name] | YYYY-MM-DD |
| [LL-nn] | [Observation] | [Effect] | [Action] | [@name] | YYYY-MM-DD |

## 10. Sign-off

<!-- Guidance: Signatures confirm the decision-makers read the report and accept the residual risks in section 7. -->

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.

| Decision | [Release / Release with conditions / Do not release] |
|---|---|
| Decision date | YYYY-MM-DD |
| Recorded in | [Go/no-go meeting minutes link] |

| Role | Name | Signature or approval reference | Date |
|---|---|---|---|
| Test manager | [@name] | [Reference] | YYYY-MM-DD |
| Product owner | [@name] | [Reference] | YYYY-MM-DD |
| Release manager | [@name] | [Reference] | YYYY-MM-DD |

## 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.