The software testing life cycle (STLC) is the sequence of six phases a testing effort moves through: requirement analysis, test planning, test case development, environment setup, test execution, and test closure. Each phase has an entry criteria that has to hold before it starts and an exit criteria that has to hold before the next one is allowed to begin, and each leaves behind a specific artifact. Naming the six phases is the easy half. Stating a gate for each one that can be checked yes or no, instead of asserted, is the half every ranking page skips.
Ask a candidate to name the STLC in an interview and you get six words back, in the right order, and then silence. That's also where most write-ups on this topic stop. Nobody follows up with the question that actually matters once you're on the job: what proves phase one is actually done and phase two is allowed to start? A six-item list with no gate attached to it is a glossary entry, not a process.
This is for the person who needs the vocabulary settled cold: the QA engineer prepping for that interview question, the SDET writing the internal process doc a new hire will read in their first week, or the auditor checking whether a gate was actually verified rather than assumed. It is not for the QA lead assembling a suite-design budget across techniques, which is what our test plan template and test planning workflow posts already cover, and it is not for a team wondering whether their AI-generated tests exercise anything real. Just the six phases, gated, one at a time.
Requirement analysis
Requirement analysis is where the test team reads the functional and non-functional requirements and works out which of them are actually testable as written. A requirement that says a page should "load quickly" isn't testable until someone attaches a number to "quickly," and finding that gap is the whole point of this phase. It's usually done jointly by a QA lead and a business analyst, sometimes with a developer in the room to flag technical ambiguity early rather than three phases later.
The artifact is a requirement analysis document, and it's frequently the first draft of something bigger: the row-by-row mapping that becomes a requirements traceability matrix once test cases exist to link back to it. Nothing downstream can start cleanly until this phase produces requirements that are specific enough to test against.
Test planning
Test planning takes the analyzed requirements and turns them into scope, strategy, schedule, and resourcing. This is where someone decides which requirements get automated versus tested manually, what environments and data the effort needs, and, critically, what the entry and exit criteria for every phase after this one will actually be. A test lead or test manager typically owns this phase, because it's a scheduling and resourcing decision as much as a technical one.
The artifact is the test plan itself, the document every later phase gets checked against. If you're building one from scratch, that's a separate exercise with its own structure, which is what our test plan template post walks through in full.
Test case development
Test case development is where the plan turns into individual test cases: specific inputs, specific steps, and a specific expected result for each requirement the plan committed to covering. This is the phase where a test design technique actually gets applied, whether that's a straightforward positive-and-negative case per requirement or something more structured. Test engineers own this phase, and its output is graded directly against the plan's coverage commitment, not against effort spent.
The artifacts are the test cases themselves, along with any test data sets they need to run. A test case with no linked requirement ID is a sign this phase didn't finish cleanly, which is exactly the gap a traceability matrix is built to catch.
Environment setup
Environment setup is the phase everyone underestimates until it's the reason a test run gets thrown out. It covers provisioning the hardware or infrastructure, installing the application build under test, configuring it to resemble production closely enough that a pass means something, and loading the test data the case development phase specified. This is usually a shared responsibility between QA and whoever owns infrastructure or DevOps.
The artifact is less a document than a state: a working, configured environment, usually confirmed with a smoke test before anyone commits to running the full suite against it. An environment that "mostly" matches production is the single most common reason a passing test suite still misses a production bug.
Test execution
Test execution is the phase most people picture when they hear "testing": running the developed test cases against the prepared environment and recording what happens. Testers or an automation suite execute the cases, log the actual result against the expected one, and file a defect for every mismatch that isn't explained by a bad test case.
The artifacts are the execution log and the defect reports it generates. This phase doesn't get to declare itself finished; whether it's actually done is a question the next phase answers.
Test closure
Test closure is where someone steps back from the individual pass/fail results and asks whether the testing effort as a whole met the criteria the planning phase set. That means checking coverage against what was planned, reviewing which defects are fixed, which are deferred, and which exit criteria were waived and why, then signing off (or not) on the release.
The artifact is a test closure report, and the waiver-rationale field inside it is the one an auditor actually reads. We cover what a properly filled closure report looks like, waivers and all, in a dedicated post; this phase is where that document gets written, not where its contents get re-derived.
The 6 STLC phases and their entry and exit gates
Here's the same six software testing life cycle phases with a gate attached to each one. An entry gate is what has to be true before the phase is allowed to start; an exit gate is what has to be true before the next phase is allowed to start; the artifact is the thing the phase leaves behind as proof it happened. Read down the entry and exit columns and every gate is something you can check against a real document or a real environment, not an adjective like "thorough" or "ready." For the general argument about what makes a criterion measurable rather than aspirational, we've made that case separately in test entry and exit criteria; what follows here is that argument applied phase by phase.
| Phase | Entry gate | Exit gate | Artifact produced |
|---|---|---|---|
| Requirement analysis | Requirements doc is reviewed and baselined | Every requirement has a unique ID | Requirement analysis doc |
| Test planning | Requirement IDs and priorities exist | Plan approved, entry/exit criteria defined | Test plan |
| Test case development | Test plan is signed off | Every requirement ID maps to a case | Test cases, test data |
| Environment setup | Test cases and data are finalized | Smoke test passes against the build | Confirmed test environment |
| Test execution | Environment smoke test signed off | Every planned case run, no open blockers | Execution log, defect reports |
| Test closure | Execution log has zero open blockers | Exit criteria met or waived with rationale | Test closure report |
How Autonoma compresses the middle phases
The two most expensive phases to run by hand were always test case development and environment setup. Someone had to sit down and write a test case against every requirement the plan committed to, and someone else had to provision and configure an environment that matched what those cases assumed before a single one could run. Both phases exist as separate, sequential steps because authoring and provisioning used to be the bottleneck, not because the ordering itself was the valuable part.
Autonoma's Planner agent reads the routes, components, and flows already present in a codebase and derives test cases directly from what it finds there, rather than starting from a requirements document that a person has to translate into steps by hand. It also generates the endpoints a given test needs to put the database into the correct starting state, which is normally its own slice of environment-setup work done separately from writing the case itself. Execution then runs against a live preview environment rather than one a person configured and validated ahead of time, which folds the environment-setup gate into the same motion as running the test instead of a phase that has to clear on its own first.
Put next to the gate table above: the entry gate for test case development, an approved test plan, still has to hold. What changes is that the artifact it produces is derived from the codebase rather than authored line by line, and the exit gate for environment setup, a build that matches what the tests expect, gets checked against the same preview the tests run in rather than proven separately beforehand. Neither gate disappears. Both get cheaper to clear.
STLC in Agile and continuous delivery
Ask whether the STLC "still applies" in Agile and most answers wave at daily standups and move on. Here's the specific claim, phase by phase: in a team deploying to production daily, four of the six phases stop being sequential activities that happen once per release and become gates that run on every pull request instead. Test planning, test case development, environment setup, and test execution all collapse into the same per-PR loop, because each one is now scoped to a diff rather than to an entire release, and the cost of running that loop again on the next PR is close to zero.
Requirement analysis and test closure are the two that don't collapse the same way, and the reason is structural rather than technical. Requirement analysis depends on a human decision (a product owner or business analyst deciding what a new requirement actually means), and that decision doesn't happen more often just because deploys do. Test closure depends on a human judgment too: whether an exit criterion that wasn't met should be waived, and what the residual risk actually is, which is exactly the kind of call a policy engine can enforce but shouldn't be left to make alone. Both phases survive on a human cadence, sprint, release, or compliance calendar, while the middle four run continuously underneath them.
To be precise about what's actually claimed here: this is a statement about cadence, not about the phases disappearing. Every gate in the table above still gets checked; four of them just get checked once per PR instead of once per release. What actually enforces that per-PR cadence, which check blocks a merge versus a deploy versus only reports, is its own topic, and we've written the gating policy up separately in our QAOps post rather than repeating it here.
Where this sits next to the SDLC
The STLC doesn't run instead of the software development life cycle (SDLC); it runs alongside it, as a second clock with its own phases and its own gates, synchronized to the same releases. Where exactly the two overlap, and where testing used to lag development by days or weeks before both cycles compressed into the same per-PR loop, is worth a diagram of its own rather than a single paragraph here; we've drawn that timeline in a dedicated STLC vs SDLC comparison. The gate vocabulary this piece uses, entry criteria, exit criteria, closure, isn't something we invented; it's the same test-process vocabulary the ISTQB Foundation Level syllabus treats as the standard reference for the term itself.
Six phases, six gates, and a claim about which parts of the software testing life cycle changed shape rather than disappeared. That's the version worth carrying into the interview, the process doc, or the audit: not the six-word list, the gated version, with the artifact each phase actually has to produce. If you're standing up that process today and most of your releases already ship daily, the honest starting point is the continuous-delivery version above, not the six-phases-per-release version the glossary entry implies. Autonoma is where the middle four gates and the test maintenance underneath them tend to live for teams already on that cadence: a Diffs Agent revisits the affected test cases against the code diff on every pull request, so the suite tracks changes to the codebase without someone manually re-deriving cases each cycle. That's a narrower claim than replacing the STLC. It's the mechanism that keeps the per-PR version of it from quietly drifting out of sync with what the application actually does.
Frequently Asked Questions
The software testing life cycle (STLC) is a sequence of six defined phases that a testing effort moves through: requirement analysis, test planning, test case development, environment setup, test execution, and test closure. Each phase has an entry criteria that must be met before it starts, an exit criteria that must be met before the next phase can begin, and an artifact it produces as proof of completion. It runs alongside, not instead of, the broader software development life cycle.
The six phases are requirement analysis (identifying which requirements are testable), test planning (defining scope, strategy, and criteria), test case development (writing the actual test cases and test data), environment setup (provisioning and configuring the test environment), test execution (running the cases and logging results), and test closure (evaluating completion against the exit criteria and producing a closure report).
Entry criteria are the conditions that must be true before a phase is allowed to start, and exit criteria are the conditions that must be true before the next phase is allowed to begin. For example, test case development's entry criteria is typically a signed-off test plan, and its exit criteria is that every requirement ID in scope maps to at least one test case. Criteria that can't be checked as true or false, rather than judged as a matter of opinion, aren't functioning as gates.
Yes, but the six phases don't stay sequential in a team deploying continuously. Requirement analysis and test closure tend to survive as activities on a human cadence, tied to when a product owner defines new scope or a release needs sign-off. Test planning, test case development, environment setup, and test execution collapse into a single loop that runs on every pull request rather than once per release. The phases don't disappear; how often each one runs changes.
The STLC is the full six-phase process; the test plan is a single artifact produced by one phase inside it, test planning. The test plan documents scope, strategy, schedule, and the entry and exit criteria for every other phase, but it doesn't cover requirement analysis, execution, or closure directly, those are separate phases with their own artifacts that the test plan sets expectations for rather than performs itself.
By taking the authoring and provisioning work out of them. Autonoma's agents read the routes, components, and flows already present in a codebase and derive test cases from what they find there, so test case development starts from the application itself rather than from a document someone has to translate into steps by hand. They also generate the endpoints a given test needs to put the database into the right starting state, and execution runs against a live preview environment, which folds most of environment setup into the same motion as running the test. Its Diffs Agent then revisits the affected cases on every pull request, so the suite keeps pace with the codebase across cycles. Every gate in the phase table still gets checked, and requirement analysis and test closure stay with the people who own scope and sign-off.
