Software Testing Life Cycle (STLC)

What the STLC is — and what it is not

The STLC is a model of test work, not a calendar. In a sequential project each phase may take weeks and they run largely in order; in a two-week sprint all six happen for every story, often within days, and several overlap. The phases are logically ordered — you cannot execute a test that has not been designed — but in practice they are iterative and overlapping. CTFL v4.0 makes the same point about its test activities: they often run iteratively or in parallel, and the way they are carried out is tailored to the context.

The cycle also nests. A release has a test cycle; within it, each test level (component integration, system, acceptance) can have its own; and every defect fix starts a small cycle of confirmation testing and regression testing. What makes it a lifecycle is that every cycle closes: someone checks the exit criteria, records what was and was not tested, and hands over.

• Not a phase after development — requirement analysis starts as soon as requirements exist.
• Not only execution — analysis, design and preparation decide whether execution finds anything worth finding.
• Not a documentation exercise — the amount written down follows the context: a regulated system needs formal records, a small product team may need a one-page plan.
• Not owned by testers alone — developers run component tests, product owners accept, operations supports environments.

STLC phases mapped to the ISTQB test process

“STLC” is an industry term; ISTQB does not define it. The CTFL v4.0 syllabus describes a test process of seven activity groups, and ISO/IEC/IEEE 29119-2 describes test management processes (test strategy and planning, test monitoring and control, test completion) and dynamic test processes. The table maps the three vocabularies so you can move between a job description, an ISTQB exam and a standards-based quality system.

• Monitoring and control has no STLC phase: it runs from planning to completion, comparing actual progress with the plan and taking corrective action.
• ISTQB separates test analysis (what to test — test conditions, prioritised) from test design (how to test — test cases, coverage items, test data requirements, environment design).
• ISTQB test implementation covers everything needed to run: test data, test procedures, manual and automated scripts, test suites, the execution schedule, and a test environment built and verified. The STLC splits the environment out as its own phase.
• Test analysis also evaluates the test basis itself for defects — the same idea as the STLC’s requirement analysis.

Industry STLC phase      | ISTQB CTFL v4.0 test activity             | ISO/IEC/IEEE 29119-2 process
-------------------------|-------------------------------------------|------------------------------------------
Requirement analysis     | Test analysis ("what to test")            | Test design & implementation (first steps)
Test planning            | Test planning                             | Test strategy & planning
(runs throughout)        | Test monitoring and test control          | Test monitoring & control
Test case development    | Test design ("how to test")               | Test design & implementation
                         | Test implementation (testware ready)      |
Test environment set-up  | Test implementation (environment ready)   | Test environment & data management
Test execution           | Test execution                            | Test execution; test incident reporting
Test cycle closure       | Test completion                           | Test completion

Phase 1 — Requirement analysis (test analysis)

The tester reads the test basis — user stories, specifications, designs, API contracts, applicable regulations — and answers two questions: what can be tested here, and what is wrong or missing in the basis itself. The output is a list of test conditions prioritised by risk, and a list of questions and defects in the requirements.

For example, from “Customers can cancel an order before it ships” a tester derives the conditions: cancel a pending order; attempt to cancel a shipped order; cancel a partially shipped order; the refund amount and method; the notification sent; and a customer trying to cancel someone else’s order. Two of these are not answered by the story, so they become questions before any test case is written.

• Tasks — define in-scope and out-of-scope features; derive test conditions; flag untestable statements; surface implicit non-functional needs (performance, security, accessibility, Arabic and RTL); start the requirements traceability matrix; assess product risk as likelihood × impact.
• Entry criteria — requirements or backlog items for the scope are available; the product owner or analyst can answer questions.
• Exit criteria — every in-scope requirement has test conditions or a logged open question; ambiguities are answered or accepted as risks; the traceability matrix is started.
• Typical defects — “REQ-14: refund ‘within a reasonable time’ has no number”; “REQ-22 and REQ-31 contradict each other on whether guest users can cancel”.

Try it: AI Requirement Ambiguity Detector Try it: Requirements → Test Scenarios

Phase 2 — Test planning

Planning decides scope, approach, resources, schedule and the criteria that will end the cycle. The structure of the test plan document is covered in the test plan guide and the organisation-wide approach in the test strategy guide; what matters here is what planning must settle before design starts.

Estimates should come from a stated technique, not a guess. CTFL v4.0 names four: estimation based on ratios, extrapolation, Wideband Delphi and three-point estimation. Project risks (a late build, an unavailable sandbox, a tester on leave) belong in the plan with a contingency, next to the product risks that drive test priorities.

• The plan settles — scope and exclusions; test levels and types; approach per risk level; entry and exit criteria; environments and test data; roles; schedule and estimates; tools; risks and contingencies; reporting cadence.
• Entry criteria — scope is known well enough to estimate; the test strategy or policy is available; team and timeline are known.
• Exit criteria — the plan is reviewed and approved by the stakeholders who will act on it; entry and exit criteria for later phases are agreed; environment and data requests are raised.

Try it: Risk-Based Test Generator

Phase 3 — Test case development (test design and implementation)

Test conditions become test cases through test design techniques: equivalence partitioning, boundary value analysis, decision tables and state transition testing for specification-based design; error guessing, exploratory and checklist-based testing for experience-based design. How to write a single good test case is covered in the test case guide. Implementation then organises the cases into procedures and suites, creates the test data, writes the automated scripts and sets the execution order. Traceability is kept from requirement to condition to case.

• Entry criteria — the plan is approved; the test basis for the scope is stable enough to design against; design techniques are agreed.
• Exit criteria — every high-risk condition has at least one test case; cases are peer-reviewed; test data is prepared; automated checks are committed; the traceability matrix shows no uncovered in-scope requirement; suites and execution order are defined.

REQ-07  Order can be cancelled before shipment
  TC-07-01  Cancel order in status PENDING      -> status CANCELLED, full refund        (EP valid)
  TC-07-02  Cancel order in status SHIPPED      -> 409 "Order already shipped"          (EP invalid)
  TC-07-03  Cancel another customer's order     -> 403, no state change                 (security)
  TC-07-04  Two cancel requests in parallel     -> one refund only                      (concurrency)
  TC-07-05  Refund for totals SAR 0.01 and 99,999.99 -> exact amounts refunded           (BVA)

Try it: Requirements → Test Cases Try it: Boundary Value Analysis Try it: Test Data Factory

Phase 4 — Test environment set-up

A test environment is everything a test runs on: servers or devices, the build under test, configuration, network, databases and their data, test accounts, third-party sandboxes or mocks, and the tools to observe results. It is usually prepared in parallel with test case development, and it is checked with a short smoke test before execution starts. An environment that differs from production in a way that matters produces false passes and false failures.

• Readiness checklist — the version under test is deployed and recorded; configuration matches production where it affects behaviour (feature flags, locale, time zone); the data baseline is loaded and can be restored; third parties are sandboxed or mocked, including their failures; there is a test account for every role; testers can read logs.
• Entry criteria — environment requirements are in the plan; access to infrastructure, sandboxes and test accounts has been requested. A deployable build is needed to finish this phase, not to start it.
• Exit criteria — the smoke test passes; the readiness checklist is signed off; the data baseline can be restored on demand.
• Typical defect — “Staging runs in UTC while production uses Asia/Riyadh; the ‘today’s orders’ filter shifts by three hours.”

Try it: API Health Checker Try it: Mock API Response Generator

Phase 5 — Test execution and defect management

Execution runs the tests in the planned order, compares actual with expected results and logs each outcome as passed, failed, blocked or not run. Every failure is analysed — product defect, test defect, environment or data problem — and product defects are reported with reproducible steps and evidence, a severity and a priority. Fixed defects are retested (confirmation testing) and the areas around the change are re-checked (regression testing).

Monitoring and control happen daily during execution: progress is compared with the plan, and the test lead acts on the gaps — re-prioritising, adding an exploratory session on an unstable area, or escalating a blocker. Defect reports then move through the defect lifecycle and triage described in their own guides; the bug report guide covers how to write one.

• Entry criteria — the environment exit criteria are met and the smoke test passed; test cases and data are ready; the build under test has release notes.
• Exit criteria — planned tests are executed or descoped by an explicit decision; all failures are analysed and defects logged; no open blocker or critical defects (or a recorded risk acceptance); the regression suite is green.

Cycle: Release 3.8 — system test, day 6 of 10
Executed: 205 / 260 (79%)   Passed: 188   Failed: 17   Blocked: 7   Not run: 48
Open defects: Blocker 0 · Critical 2 · Major 6 · Minor 9
High-risk requirements with a passed test: 41 / 44
Blocked by: DEF-311 payment sandbox returns 503 for all card types
Actions: refunds exploratory session moved to day 7; retest DEF-298 and DEF-301 today

Try it: AI Bug Description Generator Try it: AI Bug Severity Suggestion Try it: Regression Scenario Generator

Phase 6 — Test cycle closure (test completion)

Closure happens when the exit criteria are met or when stakeholders decide to stop. CTFL v4.0 lists the tasks of test completion: make sure unresolved defects become change requests or backlog items, identify testware worth keeping and archive or hand it over, shut the environment down to an agreed state, analyse the test activities for lessons learned, and produce and communicate the test completion report.

• Completion report contents — testing done against the plan and any deviations; quality assessed against the exit criteria; open defects and the risk they carry; residual risks; key measures (requirement coverage, defects by severity, defects that escaped the previous release); a recommendation, while the release decision itself stays with the stakeholders.
• Entry criteria — execution is complete or stopped by decision; exit criteria have been evaluated.
• Exit criteria — the report is issued; testware is archived; the regression suite includes the new tests and every escaped defect; improvement actions from the retrospective have owners.

Try it: AI Test Coverage Analyzer

Entry and exit criteria per phase at a glance

Criteria only work if they are measurable and if skipping one is a visible decision rather than a quiet omission. In agile teams the same idea appears as the Definition of Ready (entry for a story) and the Definition of Done (exit).

Phase                  | Entry criteria (example)                          | Exit criteria (example)
-----------------------|---------------------------------------------------|------------------------------------------------
Requirement analysis   | Stories/specs available for the scope;            | Every in-scope requirement has test conditions
                       | product owner reachable for questions             | or a logged open question
Test planning          | Scope and timeline known; strategy available      | Plan approved; entry/exit criteria agreed;
                       |                                                   | environment and data requested
Test case development  | Plan approved; test basis stable for the scope    | High-risk conditions covered; cases reviewed;
                       |                                                   | data and automated checks ready; RTM updated
Environment set-up     | Environment spec in plan; access requested        | Smoke test passes; data baseline restorable;
                       |                                                   | third parties sandboxed or mocked
Test execution         | Smoke passed; cases, data, release notes ready    | Planned tests run or descoped by decision;
                       |                                                   | 0 open Blocker/Critical; regression green
Test cycle closure     | Execution complete or stopped by decision         | Completion report issued; testware archived;
                       |                                                   | lessons learned have owners

The STLC in a sprint, in a pipeline, and the usual mistakes

In Scrum the cycle runs per story and per sprint: backlog refinement is requirement analysis and the Definition of Ready its exit; sprint planning includes test planning at sprint scale; design and automation happen during the sprint; the pipeline provisions the environment; execution is continuous; the sprint review and retrospective carry the closure. In a CI/CD setup the pipeline automates environment set-up and much of execution on every change, and human effort moves to analysis, design, exploratory testing and reading production signals.

• Designing tests before the analysis questions are answered — the cases are rewritten when the answers arrive.
• Exit criteria written but ignored under deadline pressure — releasing with an open risk is legitimate only when it is an explicit, recorded decision.
• No traceability — nobody can say which requirements are untested.
• Environment set-up left until the build arrives — the execution window shrinks by exactly the set-up time.
• Skipping closure — escaped defects never enter the regression suite and the same lessons are learned again.
• Counting executed test cases as progress instead of risk covered.

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021The test process model: organisational, test management and dynamic test processes, with their activities and outcomes.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021Templates and content for test documentation — test policy, strategy, plan, status and completion reports, incident reports.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024ISTQB's advanced syllabus on managing testing: test planning and estimation, risk-based testing, monitoring, metrics and reporting.