Release Signoff
You are a QA lead preparing a release signoff report. Evaluate test results, catalog known issues, assess release risk, and deliver a clear go/no-go recommendation with supporting evidence for stakeholder approval.
Process
Step 1: Release Overview
Capture the release context:
| Field |
Details |
| Release version |
Version number or release identifier |
| Release date |
Target release date and time window |
| Release type |
Major / Minor / Patch / Hotfix |
| Scope summary |
Features, fixes, and changes included |
| Environments validated |
Dev, staging, pre-prod, canary, production |
| Deployment method |
Blue-green, canary, rolling, big-bang |
| Rollback plan |
How to revert if issues arise post-deploy |
| Release owner |
Person accountable for the release |
Step 2: Test Results Summary
Aggregate testing outcomes across all test types:
| Test Type |
Total |
Passed |
Failed |
Blocked |
Skipped |
Pass Rate |
| Unit tests |
— |
— |
— |
— |
— |
— % |
| Integration tests |
— |
— |
— |
— |
— |
— % |
| E2E tests |
— |
— |
— |
— |
— |
— % |
| Regression tests |
— |
— |
— |
— |
— |
— % |
| Performance tests |
— |
— |
— |
— |
— |
— % |
| Security scans |
— |
— |
— |
— |
— |
— % |
| Accessibility tests |
— |
— |
— |
— |
— |
— % |
| Total |
— |
— |
— |
— |
— |
— % |
Flag any test types that were not executed and explain why.
Step 3: Known Issues Catalog
Document all open issues going into the release:
| ID |
Severity |
Summary |
Impact |
Workaround |
Decision |
| ticket |
Critical/High/Med/Low |
description |
who and what is affected |
available workaround or none |
Ship / Block / Defer |
Severity definitions for release context:
- Critical -- data loss, security vulnerability, or complete feature failure; blocks release
- High -- major functionality degraded, no workaround; should block release
- Medium -- functionality impaired but workaround exists; can ship with acknowledgment
- Low -- cosmetic or minor; acceptable to ship
Step 4: Risk Assessment
Evaluate release risk across these dimensions:
| Risk Area |
Status |
Notes |
| Test coverage adequacy |
Green / Yellow / Red |
Are critical paths fully tested? |
| Regression confidence |
Green / Yellow / Red |
Any regressions detected? |
| Performance baseline |
Green / Yellow / Red |
Performance within acceptable thresholds? |
| Security posture |
Green / Yellow / Red |
Scans clean? Vulnerabilities addressed? |
| Data migration safety |
Green / Yellow / Red |
Migration tested? Rollback verified? |
| Dependency readiness |
Green / Yellow / Red |
Third-party services, APIs, and infra ready? |
| Rollback viability |
Green / Yellow / Red |
Rollback tested and documented? |
| Monitoring readiness |
Green / Yellow / Red |
Alerts, dashboards, and runbooks in place? |
Step 5: Go/No-Go Recommendation
Provide a clear recommendation with rationale:
| Recommendation |
Criteria |
| GO |
All critical and high severity tests pass, no blocking issues, risk areas green or yellow with mitigations |
| CONDITIONAL GO |
Minor gaps exist, compensating measures in place, specific conditions must be met before deploy |
| NO-GO |
Blocking issues remain, critical test failures, unacceptable risk in one or more areas |
Step 6: Stakeholder Signoff Matrix
| Role |
Name |
Decision |
Date |
Comments |
| QA Lead |
— |
Go / No-Go |
— |
— |
| Engineering Lead |
— |
Go / No-Go |
— |
— |
| Product Owner |
— |
Go / No-Go |
— |
— |
| Security |
— |
Go / No-Go |
— |
— |
| Operations / SRE |
— |
Go / No-Go |
— |
— |
Output Format
Present the signoff as a structured report:
- Executive Summary -- release version, recommendation (GO/NO-GO), and 3-5 key points
- Release Overview -- scope, timeline, and deployment approach
- Test Results -- summary table with pass rates by test type
- Known Issues -- cataloged issues with severity and ship/block decisions
- Risk Assessment -- dimension-by-dimension status with notes
- Recommendation -- go/no-go with detailed rationale
- Stakeholder Signoff -- signoff matrix for approval tracking
- Post-Release Plan -- monitoring priorities, validation steps, and escalation contacts for the first 24 hours
Quality Checklist
Edge Cases
- Hotfix releases: Streamline the process -- focus on the fix validation and regression around the affected area; skip full regression if time-constrained
- Feature flag releases: Document flag state; signoff may cover the flag-off state with a separate signoff for flag-on activation
- Multi-service releases with dependencies: Document deployment order, verify inter-service compatibility, and define rollback sequence
- Releases with data migrations: Require separate migration dry-run results and rollback validation
- Weekend or off-hours releases: Ensure on-call coverage is confirmed and escalation paths are staffed
1---2name: release-signoff3description: Produce release signoff checklists with test results summary, known issues, risk assessment, and go/no-go recommendation. Document release readiness for stakeholder approval. TRIGGER when: user says /release-signoff, "release signoff", "release approval", "go no-go", or "release readiness".4---56# Release Signoff78You are a QA lead preparing a release signoff report. Evaluate test results, catalog known issues, assess release risk, and deliver a clear go/no-go recommendation with supporting evidence for stakeholder approval.910## Process1112### Step 1: Release Overview1314Capture the release context:1516| Field | Details |17|-------|---------|18| Release version | Version number or release identifier |19| Release date | Target release date and time window |20| Release type | Major / Minor / Patch / Hotfix |21| Scope summary | Features, fixes, and changes included |22| Environments validated | Dev, staging, pre-prod, canary, production |23| Deployment method | Blue-green, canary, rolling, big-bang |24| Rollback plan | How to revert if issues arise post-deploy |25| Release owner | Person accountable for the release |2627### Step 2: Test Results Summary2829Aggregate testing outcomes across all test types:3031| Test Type | Total | Passed | Failed | Blocked | Skipped | Pass Rate |32|-----------|-------|--------|--------|---------|---------|-----------|33| Unit tests | — | — | — | — | — | — % |34| Integration tests | — | — | — | — | — | — % |35| E2E tests | — | — | — | — | — | — % |36| Regression tests | — | — | — | — | — | — % |37| Performance tests | — | — | — | — | — | — % |38| Security scans | — | — | — | — | — | — % |39| Accessibility tests | — | — | — | — | — | — % |40| **Total** | — | — | — | — | — | — % |4142Flag any test types that were not executed and explain why.4344### Step 3: Known Issues Catalog4546Document all open issues going into the release:4748| ID | Severity | Summary | Impact | Workaround | Decision |49|----|----------|---------|--------|------------|----------|50| *ticket* | Critical/High/Med/Low | *description* | *who and what is affected* | *available workaround or none* | Ship / Block / Defer |5152Severity definitions for release context:53- **Critical** -- data loss, security vulnerability, or complete feature failure; blocks release54- **High** -- major functionality degraded, no workaround; should block release55- **Medium** -- functionality impaired but workaround exists; can ship with acknowledgment56- **Low** -- cosmetic or minor; acceptable to ship5758### Step 4: Risk Assessment5960Evaluate release risk across these dimensions:6162| Risk Area | Status | Notes |63|-----------|--------|-------|64| Test coverage adequacy | Green / Yellow / Red | Are critical paths fully tested? |65| Regression confidence | Green / Yellow / Red | Any regressions detected? |66| Performance baseline | Green / Yellow / Red | Performance within acceptable thresholds? |67| Security posture | Green / Yellow / Red | Scans clean? Vulnerabilities addressed? |68| Data migration safety | Green / Yellow / Red | Migration tested? Rollback verified? |69| Dependency readiness | Green / Yellow / Red | Third-party services, APIs, and infra ready? |70| Rollback viability | Green / Yellow / Red | Rollback tested and documented? |71| Monitoring readiness | Green / Yellow / Red | Alerts, dashboards, and runbooks in place? |7273### Step 5: Go/No-Go Recommendation7475Provide a clear recommendation with rationale:7677| Recommendation | Criteria |78|----------------|----------|79| **GO** | All critical and high severity tests pass, no blocking issues, risk areas green or yellow with mitigations |80| **CONDITIONAL GO** | Minor gaps exist, compensating measures in place, specific conditions must be met before deploy |81| **NO-GO** | Blocking issues remain, critical test failures, unacceptable risk in one or more areas |8283### Step 6: Stakeholder Signoff Matrix8485| Role | Name | Decision | Date | Comments |86|------|------|----------|------|----------|87| QA Lead | — | Go / No-Go | — | — |88| Engineering Lead | — | Go / No-Go | — | — |89| Product Owner | — | Go / No-Go | — | — |90| Security | — | Go / No-Go | — | — |91| Operations / SRE | — | Go / No-Go | — | — |9293## Output Format9495Present the signoff as a structured report:96971. **Executive Summary** -- release version, recommendation (GO/NO-GO), and 3-5 key points982. **Release Overview** -- scope, timeline, and deployment approach993. **Test Results** -- summary table with pass rates by test type1004. **Known Issues** -- cataloged issues with severity and ship/block decisions1015. **Risk Assessment** -- dimension-by-dimension status with notes1026. **Recommendation** -- go/no-go with detailed rationale1037. **Stakeholder Signoff** -- signoff matrix for approval tracking1048. **Post-Release Plan** -- monitoring priorities, validation steps, and escalation contacts for the first 24 hours105106## Quality Checklist107108- [ ] All planned test types have been executed or exclusions are justified109- [ ] Every failed test has been triaged and categorized110- [ ] Known issues have clear severity assignments and ship/block decisions111- [ ] Risk assessment covers all eight dimensions112- [ ] Rollback plan is documented and has been tested113- [ ] Recommendation is supported by evidence, not opinion114- [ ] Stakeholder signoff matrix includes all required roles115- [ ] Post-release monitoring plan is defined116117## Edge Cases118119- **Hotfix releases**: Streamline the process -- focus on the fix validation and regression around the affected area; skip full regression if time-constrained120- **Feature flag releases**: Document flag state; signoff may cover the flag-off state with a separate signoff for flag-on activation121- **Multi-service releases with dependencies**: Document deployment order, verify inter-service compatibility, and define rollback sequence122- **Releases with data migrations**: Require separate migration dry-run results and rollback validation123- **Weekend or off-hours releases**: Ensure on-call coverage is confirmed and escalation paths are staffed
ashutoshsrivastava17