QA Review and Sign-Off Working Skill

What this skill is for

The QA Review and Sign-Off is the quality gate that determines whether a release is approved to proceed to deployment or UAT. It is not a generic checklist tick; it is a structured review of test coverage, defect status, documentation completeness, and accepted risk. This skill helps the QA lead or project manager assemble evidence, evaluate it against predefined criteria, and produce a QA Sign-Off Memo that is credible to the steering committee, auditors, and deployment team. The memo is the official record of the quality decision at a point in time.

When to use this skill

• Testing is complete and the release requires a formal quality gate before deployment.
• The steering committee or CAB needs a documented recommendation on whether to approve the release.
• Regulatory or contractual requirements mandate a QA sign-off before go-live.
• Defects remain open and the project lead wants to know whether the risk is acceptable.
• Test coverage is partial and the team needs a formal record of what was not tested and why.
• An audit or retrospective requires evidence that the release was reviewed and signed off by QA.

Real work situations

SAP transport release: QA gate before production move

A set of transports containing custom code and configuration changes is ready to move from the quality system to production. The QA lead must verify: all test cases in the regression plan were executed, defect triage is complete with no critical defects open, the transport documentation lists every object, the rollback plan is documented, and the business owner has accepted the known open minor defects. Without a structured QA review, the transport is approved verbally and a critical defect is found in production because the last test case was skipped.

UAT completion sign-off: business readiness for go-live

UAT has finished for a new sales order workflow. The business testers reported five defects, all of which are minor or have workarounds. The QA lead must verify: every UAT scenario was executed, the test evidence is complete and traceable, the defect log shows all items are closed or accepted, the business owner has signed the UAT completion form, and the training documentation is updated. Without a structured QA review, the business owner assumes UAT was thorough and discovers a missing scenario after go-live that blocks a critical customer segment.

Data migration release: quality gate for production load

A master data migration is scheduled for the weekend. The QA lead must verify: the migration was tested in the quality system with a full data set, the reconciliation report matches the source and target counts, the error log is empty or all errors are explained and accepted, the rollback script is tested and available, and the business owner has accepted the migration timing and data scope. Without a structured QA review, the migration runs with an untested rollback script and a partial data set, leading to a 12-hour recovery window.

Inputs required

• Test execution report showing which test cases passed, failed, skipped, or blocked, with evidence links.
• Defect Triage Log with current status of all defects, including open items and accepted risks.
• Regression Test Plan or Test Case Document showing the scope of testing and any exclusions.
• Traceability matrix showing requirements mapped to test cases and defects.
• Release documentation: change description, transport list, deployment steps, and rollback plan.
• Quality gate criteria from the project plan or QA policy: thresholds for defect counts, coverage levels, and documentation completeness.
• UAT sign-off or business acceptance record (if applicable).
• Risk acceptance register showing which risks are accepted, by whom, and with what mitigation.

Questions to ask

• What percentage of planned test cases were executed, and what percentage passed?
• How many critical and major defects are open, and what is the business impact of each?
• Which requirements have no test coverage, and why?
• Is the rollback plan documented, tested, and accessible to the deployment team?
• Has the business owner or requirement owner accepted the open defects and untested areas?
• Are all transport objects, configuration changes, and data loads documented in the release notes?
• Does the test evidence match the test cases, or are there gaps in the execution record?
• What would happen if the release proceeds and the worst open defect occurs in production?

Working method

1. Assemble the evidence package. Collect all inputs: test execution reports, defect logs, traceability matrices, release documentation, and risk registers. Organize them in a single location or sharepoint.
2. Verify test coverage completeness. Compare the executed test cases to the planned test cases. Calculate coverage percentage. Identify skipped or blocked cases and determine whether they are required for the quality gate. Document gaps.
3. Verify defect status against gate criteria. Count open defects by severity. Compare to the quality gate thresholds (e.g., zero critical, no more than two major). If thresholds are exceeded, mark the gate as failed and list the defects.
4. Review traceability. Verify that every requirement has at least one executed test case or a documented exclusion with acceptance. Verify that every defect traces to a requirement and a test case. Orphan defects or untested requirements are red flags.
5. Review release documentation. Confirm that the change description, transport list, deployment steps, and rollback plan are complete and reviewed by the technical team. Confirm that the rollback plan has been tested or at least validated in a non-production environment.
6. Confirm risk acceptance. Verify that all open defects, untested areas, and known issues have been accepted by a named stakeholder with a dated record. Unaccepted risks block the gate.
7. Classify the gate outcome. Use three outcomes: Go (all criteria met, no significant open risks), Conditional Go (criteria mostly met, minor open risks accepted with mitigation), No-Go (criteria not met, significant risks remain). Do not use ambiguous language like "almost ready."
8. Write the QA Sign-Off Memo. Use the template below. Include the evidence summary, criteria evaluation, open risks, gate outcome, and conditions for a Conditional Go.
9. Review with stakeholders. Walk through the memo with the project lead, QA lead, and business owner. Confirm that the evidence is accurate and the conclusion is shared.
10. Obtain signatures or electronic approval. Store the signed memo in the project records. The memo is the official record of the quality decision.

Decision rules

• If any critical defect is open, the gate outcome is No-Go unless the critical defect is accepted by the executive sponsor with a documented mitigation plan.
• If test coverage is below the threshold (e.g., less than 90% of planned cases executed), the outcome is No-Go or Conditional Go depending on whether the uncovered areas are high-risk.
• If the rollback plan is missing or untested, the outcome is No-Go regardless of test results.
• If a requirement has no test case and no documented acceptance, the outcome is No-Go until the gap is addressed or accepted.
• If all criteria are met and only trivial defects remain, the outcome is Go.
• If criteria are met but minor defects or untested areas are accepted, the outcome is Conditional Go with a dated follow-up condition.
• If the QA lead and project lead disagree on the outcome, escalate to the steering committee with both positions documented.

Deliverables

• QA Sign-Off Memo — Per release or per quality gate. Contains evidence summary, criteria evaluation, open risks, gate outcome, and conditions. See template below.
• Evidence Package Index — List of all documents reviewed, with locations and versions.
• Risk Acceptance Record — Documented confirmation of accepted risks by named stakeholders.

Templates

QA Sign-Off Memo (compact)

---
artifact: QA Sign-Off Memo
release: <Release name or version>
gate: <Gate name, e.g., QA Gate before Production>
date: <YYYY-MM-DD>
---

## Evidence summary
- Test cases planned: <count>
- Test cases executed: <count> (<percentage>%)
- Test cases passed: <count>
- Critical defects open: <count>
- Major defects open: <count>
- Minor defects open: <count>
- Untested requirements: <count> with documented acceptance

## Criteria evaluation
| Criterion | Threshold | Actual | Status |
|-----------|-----------|--------|--------|
| Test coverage | ≥ 90% | 94% | Met |
| Critical defects open | 0 | 0 | Met |
| Major defects open | ≤ 2 | 1 | Met |
| Rollback plan tested | Yes | Yes | Met |
| Business acceptance | Signed | Signed | Met |

## Open risks and conditions
| Risk | Impact | Mitigation | Accepted by | Date |
|------|--------|------------|-------------|------|
| DEF-004 label typo | Low | Fix in first patch | Business Owner | 2026-06-12 |
| TC-103 not executed | Medium | Run within 48h of go-live | QA Lead | 2026-06-12 |

## Gate outcome
- **Recommendation:** Go / Conditional Go / No-Go
- **Rationale:** <One paragraph explaining the decision>
- **Conditions for Conditional Go:** <List if applicable>

## Signatures
- QA Lead: ___________________ Date: _________
- Project Lead: ___________________ Date: _________
- Business Owner: ___________________ Date: _________

Quality checklist

• All evidence is assembled and versioned before the review begins.
• Test coverage is calculated and compared to the threshold.
• Defect counts by severity are compared to the gate criteria.
• Every untested requirement or open defect has a documented acceptance with a named stakeholder and date.
• The rollback plan is present and validated.
• The gate outcome is one of three clear categories: Go, Conditional Go, or No-Go.
• The memo includes a rationale that explains the decision in one paragraph.
• Conditional Go items have specific, dated conditions.
• The memo is signed or electronically approved by QA lead, project lead, and business owner.

Common mistakes

• Approving a release without reviewing evidence. Consequence: the sign-off is a formality. A critical defect or missing test case is discovered in production, and the QA memo is cited as evidence that the release was approved, which damages QA credibility.
• Using ambiguous outcomes like "almost ready." Consequence: the deployment team does not know whether to proceed. The steering committee makes an uninformed decision. The memo does not serve as a clear record.
• Missing documented risk acceptance. Consequence: when an open defect hits production, there is no record that the business owner accepted it. Blame shifts to QA, and the sign-off is questioned.
• Ignoring the rollback plan. Consequence: the release fails and the team does not know how to revert. Downtime extends while the rollback steps are reconstructed from memory.
• Reviewing only the test pass rate. Consequence: the review misses that the test cases themselves were weak, that defects were closed without retest, or that requirements were not traced. The pass rate is a necessary but not sufficient condition.

Weak output vs Strong output

Weak output

A generic email: "The QA team has reviewed the release and everything looks good. We found a few minor issues but they are not blockers. The team is ready to go live. Please approve." No evidence summary, no criteria, no defect counts, no coverage percentage, no open risks, no rollback check, no signatures.

Why it fails: It cannot be audited. It provides no record of what was reviewed. It cannot be used in a retrospective to understand what went wrong. It is not a quality gate; it is a request for trust.

Strong output

---
artifact: QA Sign-Off Memo
release: S/4 2026.06 Wave 2
gate: QA Gate before Production
date: 2026-06-12
---

## Evidence summary
- Test cases planned: 45
- Test cases executed: 45 (100%)
- Test cases passed: 43
- Critical defects open: 0
- Major defects open: 1
- Minor defects open: 2
- Untested requirements: 0

## Criteria evaluation
| Criterion | Threshold | Actual | Status |
|-----------|-----------|--------|--------|
| Test coverage | ≥ 90% | 100% | Met |
| Critical defects open | 0 | 0 | Met |
| Major defects open | ≤ 2 | 1 | Met |
| Rollback plan tested | Yes | Yes | Met |
| Business acceptance | Signed | Signed | Met |

## Open risks
| Risk | Impact | Mitigation | Accepted by | Date |
|------|--------|------------|-------------|------|
| DEF-004 label typo | Low | Fix in first patch | Business Owner | 2026-06-12 |

## Gate outcome
- **Recommendation:** Go
- **Rationale:** All criteria are met. One major defect is open but has a tested workaround accepted by the business owner. The rollback plan was executed successfully in the QA environment. Test coverage is complete.

## Signatures
- QA Lead: D. Kharlanau, 2026-06-12
- Project Lead: [Name], 2026-06-12
- Business Owner: [Name], 2026-06-12

Agent instructions

AI Prompt Pattern

Role: QA lead performing a quality gate review for an enterprise SAP release.

Context: You have test execution reports, a defect log, a traceability matrix, release documentation, and quality gate criteria. You need to produce a QA Sign-Off Memo that evaluates the evidence and gives a clear recommendation.

Task: Calculate coverage, compare defect counts to thresholds, verify traceability, check the rollback plan, confirm risk acceptance, and produce a memo with a Go, Conditional Go, or No-Go outcome.

Output format: QA Sign-Off Memo in Markdown, using the compact template, including an evidence summary table and a criteria evaluation table.

• Never produce a sign-off memo without reviewing the actual evidence. If inputs are missing, state the gaps and recommend No-Go until they are provided.
• Always use a clear three-outcome classification. Do not use ambiguous language. Go means all criteria met. Conditional Go means criteria met with minor accepted risks and dated conditions. No-Go means criteria not met or significant risks remain.
• Always require documented risk acceptance for any open defect or untested area. Name the stakeholder, the date, and the mitigation. Unaccepted risks block the gate.
• Always verify the rollback plan. A missing or untested rollback plan is a No-Go criterion regardless of how good the test results are.
• Do not invent test results, defect counts, or stakeholder signatures. Use the evidence provided. If evidence is inconsistent, flag the inconsistency.
• Link to Atlas diagnostics when open defects touch SAP processes. Reference the relevant diagnostic page to add context to the risk assessment.

Related skills

• Test Evidence Review — Verifies that test execution evidence is complete before the QA review.
• Defect Triage and Classification — Produces the defect log that the QA review evaluates.
• Deployment Readiness Checklist — Confirms deployment prerequisites after QA sign-off.
• Release Risk Review — Assesses final risk for the go/no-go decision.

Related Atlas pages

• SAP Background Job Diagnostics — Context for reviewing scheduled job test coverage.
• SAP IDoc Status Diagnostics — Reference for integration test coverage in the QA review.

Verification status and limitations

This skill is a public working interpretation of QA gate review practices. It is not official ISTQB, BABOK, or SAP documentation. It focuses on enterprise release quality gates where documented evidence and stakeholder acceptance are required.

Known limitations: the skill assumes that quality gate criteria are predefined. It does not cover continuous deployment pipelines where every commit is automatically released. It does not address formal safety or medical device certification (FDA, IEC 62304), which require specialized quality gate frameworks. The rollback plan validation assumes a separate environment; in some organizations, rollback is only testable in production-like systems that may not be available.