The software testing life cycle is the sequence a test effort runs through, from reading the requirement to signing off the release. It exists so that testing is a process with defined start and stop conditions rather than a period of time that ends when someone runs out of patience.
Most teams already do a version of it informally. Writing it down as phases matters for one reason: each phase has an entry condition that says whether you are allowed to start, and an exit condition that says whether you are allowed to stop. Without those two, "testing is done" means "the sprint ended", which is not the same claim.
What STLC means
STLC stands for software testing life cycle. It covers the testing activity only. The software development life cycle, SDLC, covers building the product; the STLC sits inside it and runs against whatever the SDLC produces.
The phases are not a schedule. In a sequential project they run once, end to end. In a two-week sprint they run every sprint, compressed, with several of them overlapping. The order holds even when the durations collapse to hours.
Six phases or seven?
Search for this and you will get both numbers, which is the first thing that confuses people. Both are correct, and the difference is one boundary.
The six-phase version treats test environment setup as its own phase. The seven-phase version splits requirements analysis into two, separating the study of the requirement from the decision about what is feasible to test, and some sources instead split execution into execution and defect reporting. A few merge environment setup into test case development and get five.
None of this changes the work. The activities are identical; only the lines drawn between them move. If you are answering an exam question, use the numbering in the syllabus you were taught. If you are running a project, the number is irrelevant and the entry and exit criteria are the whole point. This article uses six because the environment is where projects most often stall, and a phase that has no name gets no owner.
The six phases, with entry and exit criteria
The table is the part worth keeping. A phase without a stated exit condition tends to end when the next phase's deadline arrives.
1. Requirements analysis
The testers read the requirement and work out what can be tested and how. This is also the cheapest defect detection in the whole cycle, because ambiguity found here costs a conversation and the same ambiguity found in execution costs a rebuild.
The question that earns its keep: "how would I prove this is wrong?" A requirement nobody can fail is not a requirement, it is a hope. "The page should load fast" fails that test. "The product listing renders within 2 seconds at the 95th percentile on a throttled 4G connection" passes it.
| Entry | Requirements, user stories or specs exist in some reviewable form |
| Exit | Every requirement is marked testable, untestable or needs clarification, and the open questions are logged against a named person |
| Deliverables | Requirement traceability matrix, list of open questions, automation feasibility note |
2. Test planning
The lead decides scope, approach, effort, environments, tools and risk. In a sprint this is twenty minutes and a paragraph in the ticket. On a regulated project it is a controlled document under ISO/IEC/IEEE 29119.
The plan is where the exit criteria for the whole cycle get written, and they should be written as numbers you can check rather than adjectives. "All critical and high defects closed, no more than 3 medium defects open with documented workarounds, 100% of priority-1 test cases executed, 95% passed" is checkable. "Quality is acceptable" is not.
| Entry | Requirements analysis complete, scope of the release known |
| Exit | Plan reviewed and agreed by dev lead and product owner, effort estimated, risks named with owners |
| Deliverables | Test plan, effort estimate, risk register |
3. Test case development
Cases get written, reviewed and linked back to requirements. Test data gets prepared, which is the step teams skip and then lose two days to.
A case with an expected result of "works correctly" is not a case. The expected result has to be specific enough that two different testers reach the same verdict on the same screen. Review matters here for the same reason code review does: the author is the worst-placed person to spot their own missing branch.
| Entry | Test plan approved |
| Exit | Cases peer reviewed and approved, every priority-1 requirement has at least one case, test data prepared and loaded |
| Deliverables | Test cases, test scripts, test data sets, updated traceability matrix |
4. Test environment setup
Hardware, software, network, test data and access, in a state that matches production closely enough for results to mean something. This phase runs in parallel with case development, and it is the one that most often silently fails.
Setup is not finished when the environment exists. It is finished when a smoke check passes against it, run by someone who did not build it. A one-line health check in CI is enough to catch the usual failures, which are a stale build, a missing seed and a service that is up but pointing at the wrong database:
curl -fsS -o /dev/null -w '%{http_code}\n' https://staging.example.com/health \
&& curl -fsS https://staging.example.com/api/version | jq -r '.build, .commit'
If the returned commit is not the one you meant to test, everything after this point is a measurement of the wrong artefact. That failure mode is common and it is very hard to spot from test results alone, because the tests pass or fail plausibly either way.
| Entry | Architecture and environment requirements known, build available |
| Exit | Smoke test passes, build version confirmed against the intended commit, all testers have access |
| Deliverables | Environment ready confirmation, smoke test results, build version record |
5. Test execution
Cases are run, results recorded, defects raised, fixes retested, and a regression pass confirms the fixes broke nothing else.
Two records matter more than the pass rate. The first is the build each result belongs to, because a pass on yesterday's build is not evidence about today's. The second is blocked versus failed: a blocked case was never run, and rolling blocked cases into "not passed" hides the fact that a chunk of the suite has no result at all.
| Entry | Environment ready, cases approved, build deployed and version confirmed |
| Exit | Planned cases executed or formally deferred, defects logged and triaged, exit criteria from the test plan met |
| Deliverables | Execution results per build, defect reports, retest and regression results |
6. Test cycle closure
The cycle ends with a record of what was tested, what was found, what is still open and what the team would do differently. Closure is the phase that gets dropped when a release runs late, which is why the same environment problem shows up in three consecutive releases.
Useful closure numbers are defect density per module, defect leakage (defects found in production divided by total defects found, which tells you what the cycle missed), the ratio of blocked to executed cases, and the average time a defect sat between raised and fixed. One page is enough. Nobody reads twelve.
| Entry | Execution complete, exit criteria met or exceptions signed off |
| Exit | Closure report circulated, metrics recorded, lessons logged as actions with owners |
| Deliverables | Test closure report, metrics, updated reusable assets |
STLC vs SDLC
The two are often confused because the phase names rhyme. The distinction is simple: SDLC builds the product, STLC checks it, and STLC phases are triggered by SDLC outputs.
| SDLC phase | What STLC does at the same time |
|---|---|
| Requirements | Requirements analysis, feasibility, traceability matrix started |
| Design | Test planning, approach and environment requirements agreed |
| Development | Test case development, test data preparation, environment setup |
| Testing | Test execution, defect reporting, retest and regression |
| Deployment and maintenance | Cycle closure, production defect tracking, suite maintenance |
The practical consequence is that testing starts at the requirements phase, not after development finishes. A team that begins its STLC when the build lands has already skipped the two phases where defects are cheapest to remove.
What the STLC looks like in a two-week sprint
The formal description reads as though each phase takes weeks. In practice it compresses hard, and it is worth seeing the compressed version because that is the one most teams are actually running.
A feature enters refinement. The tester reads the story and asks the questions that requirements analysis exists to produce, usually two or three of them, usually about error states nobody specified. Those answers change the acceptance criteria before a line of code is written.
While the developer builds, the tester writes the cases against the agreed criteria and prepares the data. Planning here is a paragraph, not a document: what is in scope, what is deliberately out, which environment, and what would make this story not shippable.
The build lands. Environment setup means confirming the deployed commit matches the one in the ticket, then running the smoke check. Execution follows, defects are raised with the build number attached, fixes come back, the tester retests and runs the regression subset around the touched area.
The story closes when the exit criteria in the ticket are met, not when the sprint ends. If they are not met, the honest outcome is that the story does not ship, and the closure note records why. That last sentence is the one that makes the whole cycle worth having.
Where the STLC breaks down
Most of it comes down to the same handful of failures, and they are process problems wearing a technical costume.
The first is environments that drift from production. Different data volumes, different configuration, different versions of a dependency. The result is defects that reproduce in one place and not the other, and a team that slowly stops trusting its own test results.
The second is requirements that move after cases are written and nobody updates the traceability matrix. The suite keeps passing while testing something the product no longer does. This is invisible from the pass rate, which is exactly why it survives.
The third is time. When a release runs late, execution gets cut, and it gets cut from the end, which is where the regression pass lives. The alternative is to cut scope rather than coverage: ship fewer features fully tested rather than all of them partially. That decision belongs to the product owner, and the test plan's exit criteria are what makes it a decision instead of an accident.
Sources
The ISTQB glossary defines the terms used here, and ISO/IEC/IEEE 29119 is the international standard for software testing documentation, including test plans and the content of a test completion report.
If you want the structured version of the planning phase, our guide on how to write a test plan covers the document section by section with a worked example. For the execution phase, how to write bug reports covers the expected-result problem in more detail.
BetterQA runs this cycle as an embedded QA team for clients who would rather not build the process from scratch. If your testing currently ends when the sprint ends, the entry and exit criteria above are the cheapest place to start.
Built by BetterQA
Need help with software testing?
BetterQA provides independent QA services across manual testing, automation, security audits, and performance testing. ISO 27001, 9001, 14001 and 13485 certified.
