Short answer
STLC, the software testing life cycle, is the sequence of six phases a testing effort follows: requirements analysis, test planning, test case development, test environment setup, test execution, and test cycle closure. Each phase has entry criteria that say when it may start and exit criteria that say when it is finished. Some guides count seven phases by splitting one of these in two; the work is the same.
The software testing life cycle (STLC) 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 syllabus (CTFL 4.0.1, section 1.4.1) points out that these activities may look sequential but are often carried out iteratively or in parallel, so read the order as a guide, not a rule.
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. For reference, CTFL 4.0.1 (section 1.4.1) calls this the test process and lists seven groups of activities: test planning, test monitoring and control, test analysis, test design, test implementation, test execution and test completion. Its test completion is what this article calls cycle closure. 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.
What are the stages of software testing?
The stages of software testing are the six STLC phases: requirements analysis, test planning, test case development, test environment setup, test execution and test cycle closure. People also use "stages" for the four testing levels, which are unit, integration, system and acceptance testing. The phases describe how testing is run; the levels describe what gets tested.
Both answers are correct, and most confusion comes from mixing them. A list that reads "planning, unit testing, execution, UAT" has merged two different ideas. Keep them apart and both become easier to use: the phases give you a process with start and stop conditions, and the levels tell you which part of the system each test is aimed at.
| STLC phases | Testing levels | |
|---|---|---|
| What they describe | The order of testing work | The size of the thing under test |
| The list | Requirements analysis, planning, case development, environment setup, execution, closure | Unit, integration, system, acceptance |
| Who usually owns it | The QA lead | Developers for unit, QA for integration and system, the business for acceptance |
| How they connect | Every level goes through the phases. System testing, for example, has its own planning, cases, environment, execution and closure. | |
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.
The four levels of software testing
Each level tests a larger piece of the product than the one before it, and each one catches defects the level below cannot see.
- Unit testing. One function, class or component tested on its own, usually by the developer who wrote it and usually automated. Fast and cheap, but blind to how parts behave together. More in unit testing and component testing.
- Integration testing. Two or more parts tested together: a service and its database, the front end and the API, your system and a payment provider. This is where mismatched assumptions surface. See integration testing.
- System testing. The whole application, assembled and deployed, tested against its requirements. Functional and non-functional checks such as performance and security happen here. See system testing.
- Acceptance testing. The people who asked for the software confirm it does what they need. User acceptance testing is the common form; contractual and regulatory acceptance exist too. See acceptance testing and UAT in five steps.
Some lists add a fifth stage. It is usually regression testing, which repeats earlier tests after a change and can happen at any level, or end-to-end testing, which follows a user journey across systems and sits between system and acceptance testing. Neither is wrong, they are just counted differently. Test levels are counted differently too: CTFL 4.0.1 (section 2.2.1) names five, component (unit), component integration, system, system integration and acceptance testing, where the four above treat integration as one level.
How the phases and levels run together in one release
The sprint walk-through below shows the phases compressed. Here is the same idea seen through the levels, for a release that adds a new payment method. Requirements analysis and planning happen once, at the start, and cover every level. Developers write unit tests while they build. As soon as the payment service talks to the provider's sandbox, QA runs integration tests. When the build is on staging and a smoke test passes, system testing starts, followed by a regression pass. The product owner runs acceptance checks on the finished feature, and closure records what was found at which level. Knowing the level of each defect is useful: a pile of bugs found in system testing that a unit test could have caught tells you where to invest next sprint.
How we run the stages at BetterQA
We run this cycle as an embedded QA team: our engineers join the client's standups, Jira and sprint ceremonies and work only on that project. In the first week we read the code, the existing tests and the pipeline, so we know which levels already have tests and which have none. Exit criteria go into the test plan, cases and bugs live in BugBoard, our own test management tool, and for regulated teams each release gets a BugBoard report of what was tested and what passed. We only test, we never build, so the people running system and acceptance checks did not write the code. If you want a team to own those stages for you, QA outsourcing is the usual way to start.
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.
One STLC cycle on our own homepage FAQ
In October 2026 we rewrote the FAQ on betterqa.co. It is a small change, so it shows the six phases without a big project hiding them.
What do buyers actually ask?
We read five recorded sales calls and listed the questions people asked, ranked by how often they came up. Price, a trial, start date and lock-in topped the list. That list was the requirement.
5 calls, 14 questions, 8 keptWhat does done mean?
Eight questions live, the structured data Google reads listing the same eight, every answer opening and closing, and nothing scrolling sideways on a phone.
4 exit criteria, written firstOne check per exit criterion.
Count the questions on the page. Count them in the structured data. Open each one. Measure the page width at 390px with all of them open.
4 checks, all repeatableThe live site, read twice.
Our CDN can serve an old page for up to ten minutes. So every check ran once around the cache and once through it, the way a visitor gets it.
2 reads per checkRun it and write down the numbers.
8 of 8 questions on the page, 8 of 8 in the structured data, every answer opening and closing, and the page exactly 390px wide on a 390px phone.
all 4 passedLeave a trail someone else can follow.
A changelog entry saying what changed and why, the change saved in the repository, and the task closed with a screenshot as proof.
closed with proofTested and written by the BetterQA team, reviewed by Tudor Brad, founder. October 2026.
Stages of software testing FAQ
Requirements analysis, test planning, test case development, test environment setup, test execution and test cycle closure. These are the phases of the software testing life cycle. Some sources count five or seven by merging or splitting phases, but the work is the same.
Unit testing, integration testing, system testing and acceptance testing. Each level tests a bigger part of the product, from a single function up to the whole system in the hands of its users.
It depends which split you mean. The most common is functional testing, which checks what the software does, and non-functional testing, which checks how well it does it, such as speed, security and usability. Another common split is manual versus automated testing, and a third is static testing, which reviews documents and code without running them, versus dynamic testing, which runs the software.
It is an old planning rule of thumb: roughly 40 percent of the effort goes to requirements and design, 20 percent to writing code and 40 percent to testing and fixing. It is a heuristic, not a standard, and modern teams that test continuously rarely split their time that cleanly. Its useful point is that testing is a large share of the work and should be planned that way.
Yes, but they shrink and overlap. In a sprint, planning might take twenty minutes and execution starts while cases for the next story are still being written. The sequence is a guide, the activities overlap, and the exit criteria still hold; the duration is what changes. See agile testing for more.
It varies by project, but the cheapest bugs are found earliest. Requirements analysis catches ambiguity before any code exists, and unit tests catch logic errors minutes after they are written. A defect that reaches system or acceptance testing costs more to fix, because more work has been built on top of it.
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
