The software testing lifecycle consists of seven phases: requirement analysis, test planning, test case development, test environment setup, test execution, defect reporting and retesting, and test cycle closure. Each phase has defined entry criteria, exit criteria, and a deliverable that feeds the next phase.
What is the software testing lifecycle?
The software testing lifecycle, or STLC, is the structured process a testing team follows to plan, design, run, and close a test cycle, made up of seven phases that each have their own entry criteria, exit criteria, and deliverables.
STLC covers testing activities only, which is what separates it from the software development lifecycle. Both draw from the same requirements documents, but the STLC produces evidence about software quality rather than working code.
Every phase has a defined start condition (entry criteria), a defined finish condition (exit criteria), and something it hands to the next phase. The traceability matrix from phase one feeds the test plan in phase two, setting the case count for phase three. This chain of handoffs is what makes testing effort measurable rather than a block of time before release.
The cycle repeats per release, per sprint, or per feature. The phases stay the same whether the work is manual, automated, or a mix.
What are the 7 phases of STLC?
The seven phases of STLC are requirement analysis, test planning, test case development, test environment setup, test execution, defect reporting and retesting, and test cycle closure.
- Requirement analysis: Review requirements and build the requirement traceability matrix.
- Test planning: Define scope, approach, resources, schedule, and risk in an approved test plan.
- Test case development: Write test cases, prepare the necessary test data, and build automated test scripts.
- Test environment setup: Provision the environments, tools, and data the test cases need, then smoke test.
- Test execution: Run test cases, record results, and measure test coverage against the traceability matrix.
- Defect reporting and retesting: Log defects with reproduction steps, verify fixes, and perform regression testing.
- Test cycle closure: Compile the test closure report, archive artifacts, run the retrospective, and get sign-off.
What are the 7 steps of software testing?
The seven steps of software testing are the same seven STLC phases run in order across a single release: analyze the requirements, plan the tests, write the test cases, set up the environment, execute the tests, report and retest the defects, and close the cycle.
Where the phases section above defines each one as a structure, this section runs them as a sequence. The handoffs between steps are where testing teams lose the most time. Each step hands something to the next. The traceability matrix feeds the test plan, which sets the case count. The cases set the environment and data requirement. Execution produces defects, and defects drive regression scope. Closure feeds the next cycle's planning.
Two handoffs stall more often than the rest: requirements to test design (because requirement documents are often incomplete when testers need them) and environment provisioning to execution (because hardware procurement and access approvals run on a different calendar than test schedules).
Not all steps run in strict sequence. Test case development and test environment setup can run in parallel once the test plan is approved. Some sources count six steps rather than seven by folding defect reporting into execution, hiding the retest and regression work that often causes dates to slip. Others count eight by splitting the test closure report from the retrospective. Skipping environment setup means execution runs against an unstable environment, producing false failures. Skipping closure means the next cycle re-estimates from nothing.
Phase 1. Requirement analysis
Requirement analysis decides whether everything that follows is testable. The testing team reads the requirements, user stories, or acceptance criteria, identifies what is testable and flags what is not.
Entry criteria: requirements or acceptance criteria available in documented form. Activities include identifying testable requirements, flagging ambiguous ones, defining the testing scope, and assessing automation feasibility. Questions worth raising now: What is out of scope, what are the non-functional thresholds, and which requirements have no acceptance criteria? Raising these questions at this stage costs minutes. Raising them during execution costs days.
The deliverable is the requirement traceability matrix, the document every later phase refers back to. Exit criteria: a signed traceability matrix, an automation feasibility view, and a list of open requirement questions. Teams that practice shift-left testing move this phase earlier in the development cycle, catching ambiguity before it becomes a defect.
Phase 2. Test planning
Test planning turns scope into a plan with a schedule and a cost. Entry criteria: requirement analysis complete and the traceability matrix approved.
The test plan document should contain test objectives, scope and exclusions, test techniques, entry and exit criteria for each testing stage, environment needs, a schedule, and a risk register with mitigations. Ground effort estimation in case count and expected execution time rather than in available calendar days.
The risk register is the part most teams skip and the part that justifies scope changes later. When a stakeholder asks why regression scope was cut, the risk register shows the decision was planned for. Exit criteria: test plan created, reviewed, and approved by named stakeholders, with cost and schedule agreed.
Phase 3. Test case development
Test case development is the largest phase by effort in most test cycles. Entry criteria: an approved test plan and a requirement set stable enough to design against.
A usable test case contains preconditions, steps, expected result, priority, and the requirement it traces to. Without the requirement trace, coverage cannot be measured. Test data is a managed asset, not a per-run scramble. Sensitive data needs masking rules defined before cases are written.
Which cases to automate first: high-frequency cases, high-risk flows, behavior stable across releases, and cases expensive to run by hand. The choice of test automation frameworks matters because the framework determines how scripts are maintained across releases.
Exit criteria: reviewed test cases mapped to every in-scope requirement, test data ready, and scripts committed. The case set covers both functional vs. non-functional testing requirements, addressing performance and accessibility alongside business logic.
Phase 4. Test environment setup
The test environment setup phase blocks execution more often than any other phase in the software testing lifecycle. Entry criteria: an approved test plan, documented environment requirements, and an available build.
Activities include provisioning hardware, software, network configuration, and test data, then mirroring production as closely as the budget allows. The browser, device, and operating system matrix is part of the environment, not an afterthought. Run a smoke test before declaring the environment ready, because an unstable test environment produces defects that are not defects.
Exit criteria: environment available, smoke test passed, access granted to everyone who needs it. This phase can run in parallel with test case development, which is the easiest schedule saving in the entire cycle. A cloud testing grid removes the provisioning wait here. Instead of procuring hardware locally, teams run their matrix against a real device cloud or cross-browser testing in CI service that is already provisioned.
Phase 5. Test execution
Test execution is where test cases meet the build. Entry criteria: The test environment is ready and smoke tested, test cases are reviewed, and the build is deployed.
Activities include executing test cases (manual and automated), logging results, running automated suites through CI/CD, and tracking test coverage against the traceability matrix. Execution order follows priority, so a truncated run covers the critical flows first. For a failed case, record the exact step, the environment configuration, the build number, and the evidence (screenshots, logs, video). Blocked and skipped cases need explicit recording too.
Exit criteria: all in-scope test cases executed or formally deferred, test results logged, coverage measured against the matrix.
Phase 6. Defect reporting and retesting
This phase is promoted to its own position in the seven-phase model because the retest and regression work it triggers is where release schedules move. Entry criteria: execution underway, failures identified.
A defect report needs specific elements to be actionable: build number, environment, steps to reproduce, expected result against observed result, evidence, and severity. Without these, the report bounces between the QA team and development. For guidance, see how to write a bug report.
Triage should be a scheduled meeting with a named owner, not a message thread. Scoping regression testing around a fix is a standing decision made before the cycle starts. Exit criteria: every defect closed, deferred with a written reason, or accepted as a known issue.
Phase 7. Test cycle closure
Test cycle closure is the final phase of the software testing lifecycle, and the one teams skip when the release is late. Entry criteria: exit criteria met for execution and defect resolution, or a documented decision to release with open items.
The test closure report should contain: coverage achieved against the traceability matrix, defects by severity and the phase in which they were found, effort against estimate, and open risks carried into production. Sign-off is a recorded decision with a named owner. Without it, the accountability trail disappears.
Exit criteria: closure report distributed, artifacts archived, retrospective actions assigned with dates. What skipping closure costs: the next test cycle re-estimates from nothing, repeats the same environment problems, and has no baseline to improve against.
STLC vs. SDLC
The software testing lifecycle and the software development lifecycle are confused often. The SDLC covers the entire software development process from requirements through maintenance. The STLC covers testing activities only and runs inside the development process rather than after it. The deliverables tell the difference: The SDLC produces working software, while the STLC produces evidence about that software.
Where the two cycles overlap
Requirement analysis happens in both cycles, with different outputs from the same source documents: the development team extracts what to build, the testing team extracts what to verify. Test case development and software development can run in parallel once requirements are stable. Release readiness is the point where both cycles meet, and one decision is made: ship or fix.
How the STLC works on an agile team
The seven phases survive short release cycles. What changes is their duration and formality.
The seven phases inside a two-week sprint
Requirement analysis happens at backlog refinement. Test planning happens at sprint planning. Test case development runs alongside software development rather than after it. Execution runs continuously through the sprint, and closure happens at the sprint review.
The phases that compress to minutes are requirement analysis (a user story with acceptance criteria is already a testable requirement) and test planning (a scope note replaces a formal plan). Execution and defect reporting cannot compress the same way because the work itself does not shrink with the calendar.
Continuous testing and the collapsed cycle
Continuous testing changes two phases fundamentally. Environment setup becomes provisioning as code, triggered automatically. Execution becomes something that happens on every commit rather than on a scheduled date. What continuous testing doesn’t change is the need for entry and exit criteria. Without them, the gate between phases is only a habit, and habits fail under pressure.
The failure mode worth watching for is dropping the cycle entirely rather than compressing it. Teams that abandon STLC structure in favor of "test when you can" lose the traceability that makes test results meaningful.
What to automate in each phase
Automation is not one decision made once. It applies differently in each phase of the software testing lifecycle.
Design and development phases
Test data generation and environment provisioning scripts reduce setup time for every cycle that follows. Automated test scripts target the stable, high-frequency cases first. Traceability should be maintained in the test management tool rather than in a spreadsheet because a spreadsheet cannot trigger automated coverage checks.
Execution and regression
Automated suites triggered by CI/CD on every build are the standard for execution-phase automation. Parallel execution across browsers and devices keeps coverage from extending the cycle. Flaky test quarantine is worth setting up early: a test that fails intermittently for environment reasons should be isolated, not left in the suite where it trains the team to ignore red builds.
The test environment setup and execution phases are where test cycles usually lose days. Both compress when browser and device coverage runs in parallel on a cloud grid (such as the Sauce Labs continuous testing platform) rather than on locally provisioned machines.
What stays manual
Exploratory testing and usability judgement require human evaluation, and so does first-run acceptance testing. Anything where the expected result is still being negotiated stays manual, because there is no stable assertion to automate against. The retrospective in the test closure phase is the activity automation cannot help with at all.
Deliverables and metrics that prove a cycle worked
A documented software testing process becomes a funded one when it produces numbers that stakeholders can act on.
Deliverables by phase
The full set across the seven STLC phases: requirement traceability matrix, test plan, reviewed test cases and test data, environment readiness note, execution log, defect reports, and test closure report. Each should have a defined storage location and a named audience.
Metrics worth reporting
Requirement coverage against the traceability matrix measures whether the test cases address what was specified. Defect density and defects by the phase found reveal where quality breaks down. Defect escape rate to production, tracked per release, directly measures the testing process's effectiveness. Execution time and the share spent on reruns shows where flaky tests or instability consume effort. Effort against estimate is the number that makes the next test plan credible. See also test automation KPIs.
Where Sauce Labs fits in the software development lifecycle
Sauce Labs maps across the SDLC, shaping the AURA platform's full-lifecycle release assurance approach: rather than a handful of point tools, one platform carries context across requirements, build, test, analyze, deploy, and monitor, so a production failure traces back to a specific coverage gap instead of starting a new investigation from zero. Even better, Sauce Labs AURA learns autonomously but maintains human review and approval at each stage.
In the build phase, Sauce Labs' agents extract business intent and turn it into test cases with AI-powered test authoring. In the test phase, it runs Selenium, Playwright, Cypress, Appium, and other suites in parallel across browser, operating system, and real and virtual device cloud coverage without provisioning hardware, along with visual and accessibility testing — every run returns video, screenshots, logs, and network captures to shorten reproduction. In the analyze phase, Sauce AI for Insights analyzes those failures at the job level and tells you what actually broke. In the deploy phase, Sauce Mobile App Distribution gathers pre-production real user feedback through beta testing. In the monitor phase, Sauce Error Reporting surfaces root-cause context on production issues and feeds them back into test coverage, closing the loop.
Run your next test cycle with this phase checklist
Before the next test cycle starts, work through this list with the release owner.
- Confirm every in-scope requirement has a row in the traceability matrix and an acceptance criterion.
- Write the exit criteria for all seven phases before the cycle starts and agree on them with the release owner.
- Book the test environment and smoke test it before the first execution day, not on it.
- Decide the regression scope rule now, so the defect reporting phase does not become a scope argument.
- Name the owner for each phase and the person who signs off on test cycle closure.
- Schedule the closure retrospective at the same time as the release date. This meeting often gets canceled when the release is delayed, yet it is crucial for preventing the next cycle from repeating the same issues.
- Carry two actions from the last test closure report into this cycle and report on them at the next closure.
Start a free Sauce Labs trial and remove the environment-provisioning wait before your next cycle instead of booking hardware and hoping it's ready on day one. Want help mapping your specific phases to what the platform covers? Book a demo.
Stop letting QA be the bottleneck on AI-speed development.
Stop letting QA be the bottleneck on AI-speed development.
