# Software Testing Life Cycle (STLC): 6 Phases Explained

Written by Bartek Krzyzanowski
Reviewed by Mariusz Wójcik
Published: 2026-08-25
Updated: 2026-08-27

\[TABLE\_OF\_CONTENTS\]

The software testing life cycle (STLC) is usually taught as six phases: requirement analysis, test planning, test case development, test environment setup, test execution, and test cycle closure. That model is a teaching aid, not a standard — the current ISTQB Foundation Level syllabus describes seven test activities instead, and says they are often carried out iteratively or in parallel rather than in sequence. Here is what happens in each phase, and how the two models line up.

## STLC vs SDLC: what's the difference?

SDLC covers building the software. STLC covers testing it.

|   | SDLC | STLC |
| --- | --- | --- |
| What it covers | building the software | testing the software |
| Starts when | requirements are gathered | requirements are testable |
| Owned by | development team | QA team |
| Ends with | product release | test cycle closure report |
| Number of phases | 6–7, varies by model | 6 in the common model |
| How often it runs | once per release | inside every SDLC iteration |

The two are not sequential. STLC does not begin after SDLC finishes — testing starts as soon as there is something to analyse, which in most teams means as soon as requirements exist. In waterfall projects the overlap is small. In agile teams the two run almost entirely in parallel.

## What is the software testing life cycle?

The software testing life cycle is the sequence of activities a testing team performs for a release, from analysing what needs testing to reporting what was tested and closing the cycle. Each phase has a trigger that starts it and a condition that marks it finished.

Its purpose is not bureaucratic. Without defined phases, two things go wrong repeatedly: testing begins before the environment is ready, and testing is declared finished because time ran out rather than because coverage was met.

## Software testing life cycle diagram

The common six-phase STLC is usually drawn as a straight line:

**Requirement analysis → Test planning → Test case development → Test environment setup → Test execution → Test cycle closure**

That diagram is useful for learning the names, but it is misleading if you read the arrows as a schedule. In a real project, environment setup can run beside test case development, failed execution can send the team back to design, and planning is adjusted as risks change. A better visual would show a forward flow with feedback loops rather than six sealed boxes.

## Software testing life cycle phases: the 6-step STLC model

The model below is the one taught in most courses and used in most job interviews. Treat it as a map, not as a rigid rule — real teams merge phases, skip some, and loop back constantly.

### 1\. Requirement analysis

The team reads the requirements and decides what can be tested and how. Ambiguous requirements are raised as questions now, because a requirement nobody can verify will produce a test nobody can write.

Output: a list of testable conditions, a requirements traceability matrix, and a list of questions for the business.

The most useful thing done in this phase is refusing to accept requirements written as opinions. "The page should load quickly" is not testable. "The page should load in under two seconds on a 3G connection" is.

### 2\. Test planning

The QA lead decides scope, approach, resources, schedule and risk. This is where the [test plan](https://bugbug.io/blog/software-testing/how-to-create-a-test-plan/) is written and estimates are made. The plan sits underneath the broader [QA strategy](https://bugbug.io/blog/software-testing/qa-strategy/), which covers how the team thinks about quality across releases rather than only inside one test cycle.

Output: test plan, effort estimate, risk register, tool decisions.

### 3\. Test case development

Testers write the test cases, scripts and data. Each test case traces back to a requirement, which is what makes the traceability matrix from phase one useful rather than ceremonial.

Output: test cases, test scripts, test data, updated traceability matrix.

This is also where [test design techniques](https://bugbug.io/blog/software-testing/test-design/) do the heavy lifting. Boundary value analysis and equivalence partitioning exist to stop teams writing forty test cases where six would find the same defects.

### 4\. Test environment setup

Hardware, software, network and test data are prepared. This phase runs in parallel with phase three in most teams, because there is no reason to wait.

Output: a ready environment, smoke test results confirming it works. For frequently deployed web applications, an [automated smoke test](https://bugbug.io/blog/software-testing/automated-smoke-testing/) can make that environment check repeatable.

Environment setup is the phase that fails most often and gets planned least. A test environment that differs from production in configuration will produce defects that do not exist and hide defects that do.

### 5\. Test execution

Tests are run, results are recorded, defects are logged and retested. Progress is tracked against the plan from phase two.

Output: test logs, defect reports, updated traceability matrix, test execution status. Larger suites are usually grouped into a [test suite](https://bugbug.io/blog/software-testing/test-suite/) so execution can be repeated and reported consistently.

Teams usually split execution in two: checks that run on every build, and checks a person walks through by hand. The first group is where automation pays off — recording a [regression suite](https://bugbug.io/blog/software-testing/best-regression-testing-tools/) once and re-running it per commit removes the repetitive part of this phase without touching the exploratory one.

Defects found here follow their own path, described in our guide to the [bug life cycle](https://bugbug.io/blog/software-testing/bug-life-cycle/).

### 6\. Test cycle closure

The team reports what was tested, what was found, what was left, and what should change next time.

Output: test closure report, [test coverage](https://bugbug.io/blog/software-testing/test-coverage/) summary, lessons learned, archived testware. If results come from several environments or automation runs, [test reporting tools](https://bugbug.io/blog/software-testing/test-reporting-tools/) help keep the final status tied to the evidence rather than to a manually assembled recap.

This phase is skipped more often than any other, which is why the same environment problem appears in three consecutive releases.

## STLC example: testing a checkout change

Suppose an ecommerce team is changing the checkout flow.

*   **Requirement analysis:** QA turns the change into testable conditions: card payment, guest checkout, logged-in checkout, validation errors and the supported browsers.
*   **Test planning:** the team decides which paths are release blockers, what will be automated and what still needs exploratory testing.
*   **Test case development:** testers create cases for the main journeys, boundaries and failure states, plus the data needed for each.
*   **Environment setup:** the release candidate is deployed with the required payment sandbox, accounts and seeded products. A smoke test confirms the environment is usable.
*   **Test execution:** the team runs the planned suite, logs defects, retests fixes and records anything that blocks release.
*   **Test cycle closure:** QA reports what ran, what passed, which risks remain and which tests should move into the permanent regression suite.

That is the six-phase model in one release. In a CI/CD team, several of those steps may happen on the same day or inside the same pull request.

## Does ISTQB define the six-phase STLC?

No — and this is worth knowing before an interview, because the two models are frequently confused.

> **Does ISTQB define STLC entry and exit criteria for six phases?** No. ISTQB defines entry and exit criteria for testing activities and test levels. The familiar six-phase STLC is a commonly used explanatory model, not an ISTQB standard.

The current [ISTQB Certified Tester Foundation Level syllabus v4.0.1, published 15 September 2024](https://istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf), describes the test process as seven groups of activities. It also states explicitly that although these activities may appear as a logical sequence, they are often performed iteratively or in parallel.

Here is how the two line up:

| Popular STLC phase | Closest ISTQB activity | Typical entry signal | Typical exit signal | ISTQB work products |
| --- | --- | --- | --- | --- |
| Requirement analysis | Test analysis | requirements available and stable enough to read | testable conditions identified and prioritised | prioritised test conditions, defects found in the test basis |
| Test planning | Test planning | objectives agreed, scope known | test plan approved, estimate accepted | test plan, test schedule, risk register, entry and exit criteria |
| Test case development | Test design | test conditions agreed | test cases reviewed and approved | test cases, charters, coverage items, test data and environment requirements |
| Test environment setup | Test implementation | environment requirements defined | environment verified with a smoke test | procedures, scripts, suites, test data, execution schedule, environment items |
| Test execution | Test execution | environment ready, testware approved | planned tests run, exit criteria met | test logs, defect reports |
| Test cycle closure | Test completion | testing stopped by decision or by criteria | report issued, testware archived | completion report, improvement actions, lessons learned, change requests |
| — | Test monitoring and control | runs continuously across all of the above | — | progress reports, control directives, risk information |

The seventh ISTQB activity has no equivalent in the six-phase model, because monitoring and control is not a phase — it runs across all of them. That is the single biggest thing the six-phase diagram gets wrong.

## Entry and exit criteria for every phase

Entry criteria are the conditions that must be true before a phase starts. Exit criteria are the conditions that must be true before it can be called finished.

ISTQB defines these for testing activities and test levels rather than for six named phases, and describes them in general terms. Typical entry criteria concern the availability of people, tools, environments, data and testware, plus an adequate initial quality level in the object under test. Typical exit criteria concern coverage achieved, unresolved defects, failed tests, and whether planned tests were actually run.

| Phase | Entry criteria | Exit criteria |
| --- | --- | --- |
| Requirement analysis | requirements documented, business available for questions | testable conditions listed, traceability started, open questions logged |
| Test planning | scope and conditions known, team allocated | plan approved, estimate signed off, risks recorded |
| Test case development | conditions approved, design techniques chosen | cases reviewed, data prepared, traceability complete |
| Environment setup | environment requirements defined, access granted | smoke test passes, test data loaded |
| Test execution | environment verified, testware approved, build deployed | planned tests run, defects logged and triaged, exit criteria met or waived |
| Cycle closure | execution stopped | report issued, metrics recorded, testware archived, retrospective held |

## STLC in agile and CI/CD

The six-phase model was written for projects with a beginning and an end. Most teams no longer work that way, and the phases behave differently in a two-week sprint.

1.  **They compress rather than disappear.** Requirement analysis happens in refinement, often in the same meeting where the story is estimated. Test planning happens once per quarter at team level rather than once per release.
2.  **Boundaries blur between three and five.** Writing a test and running it are frequently the same act — a tester automates the acceptance criteria, runs it against the build, and iterates. The phases still exist logically; they no longer exist as calendar blocks.
3.  **Environment setup moves into the pipeline.** Where the phase used to mean requisitioning a server, it now means a container definition living beside the code. When it fails, it fails for everyone at once.
4.  **Entry and exit criteria become Definition of Ready and Definition of Done.** This is the cleanest mapping of the four. A story is ready when its entry criteria are met, and done when its exit criteria are met. Same idea, different vocabulary, and one the whole team owns rather than only QA.
5.  **Cycle closure becomes the retrospective.** Which means the lessons-learned step happens more often, but the metrics step usually stops happening at all — nobody archives testware at the end of a sprint. This is a genuine loss and worth deliberately keeping.

Continuous delivery pushes this further: with several releases a day there is no cycle to close, so closure becomes a periodic review rather than a release gate.

## Common STLC mistakes

*   **Treating the phases as a schedule.** They are a logical order, not a Gantt chart. Environment setup running in parallel with test case development is normal, not a process failure.
*   **Skipping cycle closure.** The phase with no visible deliverable for the next release is the phase that stops the same problem recurring in it.
*   **Writing untestable requirements and discovering it in phase five.** Every hour spent in requirement analysis saves several in execution.
*   **Confusing exit criteria with running out of time.** "We stopped because the release date arrived" is a legitimate decision, but it should be recorded as a waiver, not as criteria met.
*   **Quoting the six phases as an ISTQB standard in an interview.** ISTQB describes seven activities and says they are often iterative. Knowing the difference is a cheap way to sound like someone who has read the syllabus rather than a summary of it.