QA in the Release Cycle: A Release Readiness Checklist
Where testing fits in each stage of a release, the criteria for a confident go/no-go decision, and a checklist to copy into your next release ticket.
For QA leads, release managers and engineering managers who own the decision to ship.
What Is the Release Cycle?
The release cycle is the sequence of stages a software release goes through from planning to production: plan, develop, build, test, release candidate, deploy and monitor. Release readiness is the point where the team has enough evidence to decide the release can go live.
Three terms are often used interchangeably. They describe different scales of the same flow:
| Term | What it covers | Typical timescale |
|---|---|---|
| Development cycle | Everything from idea to working software: requirements, design, build, test, release, maintain (often called the SDLC) | Weeks to months, repeated |
| Release cycle | The stages one release goes through from planning to production and monitoring | Days to weeks per release |
| Development pipeline | The automated steps that move a code change from commit to production: build, test, deploy (a CI/CD pipeline) | Minutes to hours per change |
Where QA Fits in Each Stage of the Release Cycle
Testing runs through the whole release, and each stage leaves evidence the go/no-go decision can rely on:
| Stage | QA activity | Evidence produced |
|---|---|---|
| Plan | Agree scope, identify risky areas, set the exit criteria for this release | Release scope and go/no-go criteria |
| Develop | Write test cases from the acceptance criteria while code is in progress | Reviewed test cases per story |
| Build (pipeline) | Automated unit and integration checks, a smoke test on each build | Green pipeline, smoke results |
| Test (staging) | Functional, regression and exploratory testing on a stable environment | Test run results, defects logged |
| Release candidate | Final regression on the exact build that will ship, re-test fixed defects | Signed-off run on the release candidate build |
| Deploy | Smoke test in production straight after deployment | Production smoke results |
| Monitor | Watch errors and support tickets, feed new issues back as defects | Post-release defect list |
For the testing process inside each stage, with entry and exit criteriaEntry and exit criteria are the conditions that must be true before a testing phase can start (entry) and before it can be considered finished (exit). For example, test execution may need a stable build and approved test cases to start, and no open critical defects to finish. Written in advance, they make phase transitions and release decisions objective.Full definition → per phase, see The Software Testing Life Cycle (STLC). For writing test cases early in the Develop stage, see The Three Amigos Meeting.
Go/No-Go Criteria
Agree the criteria at the Plan stage, so the decision at the end is a check rather than a debate. Adapt these examples to your product's risk level:
| Criterion | Example |
|---|---|
| Planned testing complete | Every planned scenario has a completed run on the release candidate build |
| Pass rate | At least 95% of executed cases passed, with every failure reviewed |
| Open defects | No open critical or high severity defects in the release scope |
| Known issues | Each remaining issue is documented, has an owner and a target release |
| Rollback | A rollback or feature flag plan exists and has been tried at least once |
For the coverage questions behind the first two criteria, see Test Coverage: How Much Testing Is Enough?.
The Release Readiness Checklist
Copy these items into your release ticket and tick them off as the release candidate moves toward production.
Quality
All planned test runs completed on the release candidate build
Fixed defects re-tested and closed on the same build
Regression run on the areas this release changed
No open critical or high severity defects in scope
Known issues listed with owners and workarounds
Operations
Rollback plan written and rehearsed
Database migrations tested on a copy of production data
Configuration and secrets checked for the production environment
Monitoring and alerts in place for the changed features
Feature flags set to the intended state
Communication
Release notes written and reviewed
Support team briefed on changes and known issues
Stakeholders told the release window and the decision owner
Go/no-go decision recorded with date, build and evidence
Running a 15-Minute Go/No-Go Meeting
- Attendees: the release owner, a QA lead, an engineering lead, and support or operations if the release affects them.
- QA presents the run results on the release candidate build and the open defect list.
- Engineering confirms the rollback plan and any migration or configuration steps.
- The release owner decides: go, go with documented known issues, or hold with a new date.
- Record the decision with the build number and a link to the evidence.
Release Readiness in Evaficy Smart Test
- Create a test run for the release candidate with its Environment, Browser, Operating System and Build Version, so every result is tied to the exact build.
- Let the pipeline create the run: one POST request per scenario, authenticated with a Personal Access Token, creates a run with the environment and build version filled in.
- After fixes, Re-run Failed creates a new run with only the failed cases, keeping the same build version.
- Each run has a report with a quality verdict: Excellent at 95% or more passed with no failures, Acceptable at 80% or more, Needs Attention at 60% or more, and Critical Issues below that. Export it as PDF or CSV for the release ticket.
- A Test Plan groups the release scenarios and shows coverage as the share with at least one completed run.
Evaficy Smart Test records the results; the deployment gate itself lives in your CI platform. To hold a deployment until QA signs off, use its approval feature, such as GitHub environment protection rules, GitLab manual jobs or a Jenkins input step. Setup details are in CI/CD Pipeline Integration, and the report itself is explained in Building QA Reports Clients Actually Care About.
Common Questions
What is a release cycle in software development?
A release cycle is the sequence of stages a release goes through from planning to production: plan, develop, build, test, release candidate, deploy and monitor. Teams that ship often run short release cycles of a week or two; others run longer quarterly cycles.
What is the difference between the development cycle and the release cycle?
The development cycle (SDLC) describes how software is built overall, from requirements to maintenance. The release cycle is narrower: the path one specific release takes from planning to production.
What is a development pipeline?
A development pipeline, usually called a CI/CD pipeline, is the automated sequence of steps that takes a code change from commit to production: building the code, running automated checks and deploying to each environment.
What does go/no-go mean in a release?
Go/no-go is the decision point where the team checks the release against agreed criteria and decides to ship it, ship it with documented known issues, or hold it. It is usually a short meeting with the release owner, QA and engineering.
Who makes the go/no-go decision?
A named release owner, often the product owner or engineering manager, makes the call based on the evidence QA and engineering present. Naming one owner in advance keeps the decision quick and clear.
Can you release with known bugs?
Yes, many releases ship with minor known issues. The release is ready when every known issue is documented, low in severity, has an owner and a target fix, and support knows how to handle it.
Key Takeaways
- The release cycle runs plan, develop, build, test, release candidate, deploy and monitor; QA has work in every stage.
- The development cycle is the whole SDLC, the release cycle is one release, the pipeline is the automated path for each change.
- Agree go/no-go criteria at the start of the release so the final decision is a check.
- Test the exact build that will ship, and tie every result to its build number.
- Use a checklist across quality, operations and communication, and record the decision with its evidence.
Make your next release decision on evidence
Create a free account and build the test cases for your next release. Paid plans include a 15-day free trial.
Create your free account