QA’s Role in Release Management
Release management is the process of planning, scheduling, and controlling software releases. QA is central to this process — not as a gatekeeper who blocks releases, but as a quality advisor who provides data-driven recommendations.
Release Checklist
Pre-Release
- All automated tests pass (unit, integration, E2E)
- Code coverage meets minimum threshold (e.g., 80%)
- No critical or high-severity bugs open
- Performance tests show no regression from baseline
- Security scan completed with zero critical vulnerabilities
- Database migrations tested and reversible
- Feature flags configured correctly
- Release notes reviewed and accurate
- Rollback plan documented and tested
- On-call engineer identified and available
- Monitoring dashboards and alerts verified
During Release
- Deployment started during low-traffic window (if applicable)
- Health checks passing on all new instances
- Smoke tests executed against production
- Key metrics within normal ranges (error rate, latency, throughput)
- No increase in error logs
Post-Release
- Full smoke test suite passed
- Business metrics within expected ranges (conversion, revenue)
- User-facing monitoring shows normal patterns
- Synthetic monitoring all green
- Release marked as successful or rollback initiated
- Post-release review scheduled
Go/No-Go Criteria
Quantitative Criteria
| Metric | Go Threshold | No-Go Threshold |
|---|---|---|
| Test pass rate | ≥ 99% | < 95% |
| Critical bugs | 0 | > 0 |
| High-severity bugs | ≤ 2 (with workarounds) | > 5 |
| Code coverage | ≥ 80% | < 70% |
| Performance regression | < 5% | > 15% |
| Security critical vulns | 0 | > 0 |
Qualitative Criteria
- All stakeholders reviewed and approved release scope
- Risk assessment completed for high-impact changes
- Customer communication prepared (if needed)
- Support team briefed on changes
Rollback Plans
Every release must have a rollback plan. The plan should answer:
- When to rollback: Specific criteria (error rate > 2%, conversion drop > 10%)
- How to rollback: Exact steps (redeploy previous version, revert database migration)
- Who decides: Clear ownership (on-call engineer + QA lead)
- Communication: Who to notify and how
- Verification: How to confirm rollback was successful
Rollback Types
| Type | Speed | When to Use |
|---|---|---|
| Feature flag toggle | Seconds | Feature-flagged changes |
| Container rollback | Minutes | Kubernetes/Docker deployments |
| Blue-green switch | Seconds | Blue-green deployments |
| Database revert | Minutes-hours | Schema changes (if reversible) |
| Full redeploy | 10-30 minutes | Last resort |
Exercise: Create a Release Checklist
Your team is releasing a major update that includes: new payment provider integration, redesigned checkout flow, and database schema migration. Create a comprehensive release checklist.
Solution
T-7 Days (One Week Before)
- Feature freeze — no new features after this date
- Full regression suite executed in staging
- Payment provider sandbox testing completed (all card types, failure scenarios)
- Database migration tested on staging with production-size dataset
- Rollback of database migration verified
- Performance baseline established for checkout flow
- Load test: 2x normal checkout traffic with new payment provider
- Security review of payment integration completed
T-1 Day (Day Before)
- Go/no-go meeting with all stakeholders
- All test results reviewed: 100% pass rate, no critical bugs
- Release notes finalized and approved
- On-call rotation confirmed for release window + 48 hours
- Support team briefed on new checkout flow
- Monitoring dashboards updated with new payment metrics
Release Day
- Deploy during maintenance window (2 AM - 4 AM)
- Database migration executed
- Application deployed with feature flags OFF for new checkout
- Health checks verified on all instances
- Smoke tests: old checkout flow works
- Enable new checkout for 1% of users (canary)
- Monitor for 30 minutes: error rate, payment success, latency
- If green: increase to 10%, monitor 1 hour
- If green: increase to 50%, monitor 2 hours
- If green: enable for 100%
Post-Release (48 Hours)
- Full smoke test suite passed
- Payment success rate ≥ 99.5%
- Checkout conversion rate within 5% of baseline
- Zero payment-related errors in logs
- Customer support: no unusual complaint volume
- Mark release as successful
- Schedule post-release retrospective
Key Takeaways
- Release checklists prevent human error — do not rely on memory during high-stress deployments
- Go/no-go criteria must be predefined and measurable — remove subjectivity from release decisions
- Every release needs a rollback plan — tested before the release, not improvised during an incident
- Post-release validation is mandatory — production behavior may differ from staging
- QA is a quality advisor, not a blocker — provide data, recommend actions, enable safe releases