SDLC and STLC Explained

SDLC and STLC: what each term means

The SDLC describes how software is built and maintained. Its phases carry different names in different organisations and models, but the work is the same everywhere: agree what to build (requirements), decide how to build it (architecture and design), write it (implementation), put the pieces together (integration), make it available to users (release and deployment), and run, monitor and change it (operation and maintenance). The SDLC does not end at the first release; it ends when the product is retired.

The STLC describes how the testing inside that effort is organised. The version taught in most training material has six phases: requirement analysis, test planning, test case development, test environment set-up, test execution and test cycle closure. Each phase has inputs, outputs and criteria that say when it may start and when it is finished.

One precision matters. “STLC” is an industry term used in courses, interviews and job descriptions; it is not a term defined by ISTQB. The ISTQB Certified Tester Foundation Level (CTFL) v4.0 syllabus describes a test process made of seven groups of activities: test planning, test monitoring and test control, test analysis, test design, test implementation, test execution and test completion. ISO/IEC/IEEE 29119-2 describes test processes at the organisational, test management and dynamic test levels. The substance is the same; the names and the boundaries between steps differ. In short:

• Requirement analysis ≈ test analysis — deciding what to test (test conditions) and finding defects in the test basis.
• Test planning ≈ test planning — plus test monitoring and test control, which have no STLC phase of their own and run from planning to completion.
• Test case development ≈ test design (how to test: test cases, coverage items, data needs) and most of test implementation (procedures, scripts, suites, data).
• Test environment set-up ≈ the environment part of test implementation; ISO/IEC/IEEE 29119-2 treats it as a separate process.
• Test execution ≈ test execution, including defect reporting, confirmation testing and regression testing.
• Test cycle closure ≈ test completion.

How the development and testing lifecycles relate

The simplest accurate picture is two parallel tracks with links between them. Every development work product feeds the test work in its phase. Requirements, designs and API contracts are the test basis that test analysis and design read: a requirement is what test analysis reads, an API contract is what integration tests are derived from. A build, and later the running system, is the test object: the thing test execution runs against. And every test output feeds back into development: a review comment changes a requirement, a defect report changes the code, a test completion report informs the release decision.

CTFL v4.0 states this as good practice for any lifecycle model: for every development activity there is a corresponding test activity; each test level has its own specific objectives; test analysis and design for a given test level begin during the corresponding development phase; and testers take part in reviewing work products as soon as drafts are available. A team that follows these four rules has, in effect, aligned its STLC with its SDLC whatever names it uses.

• Scope — the SDLC covers the whole product from idea to retirement; the STLC covers the verification and validation work inside it.
• Output — the SDLC produces working software and its documentation; the STLC produces testware (test conditions, cases, data, scripts, results, defect reports, status and completion reports) and an assessment of quality and residual risk.
• Ownership — the SDLC belongs to the whole team, led by product and engineering; the STLC is usually led by test roles, but developers own component tests and product owners own acceptance.
• Frequency — a product has one SDLC with many iterations; the STLC repeats for every release, sprint and test level, and every defect fix triggers a small cycle of confirmation and regression testing.
• Success measure — for the SDLC, value delivered to users; for the STLC, how much justified confidence the evidence gives and how few defects escape to production.

Where QA takes part in each SDLC phase

Testers who join only when a build is ready can find failures but cannot prevent defects. The list below is what a tester does in each development phase, and the kind of problem that phase is best placed to catch.

• Requirements — review stories and specifications for ambiguity, contradictions, missing error paths and testability; propose acceptance criteria; list product risks. Typical findings: “refund within a reasonable time” has no number; nothing says what happens to a partially shipped order.
• Design — review architecture, API contracts and UI designs for testability: can the service run with a mocked payment provider, are errors logged with a request id, can the time zone and locale be configured? Derive integration test conditions from interface contracts and ask for numeric non-functional targets (response time, accessibility level, right-to-left layout).
• Implementation — prepare test cases, test data and automated checks while the feature is built; pair with developers on component tests; make sure static analysis and code review run in the pipeline. The tester’s aim here is that the first build handed over already passes the obvious checks.
• Integration — run component integration and system integration tests: API contracts, data flowing across services, handling of third-party timeouts and error responses; run the smoke and regression suites on every integrated build.
• Release — system and acceptance testing, full regression on the release candidate, evaluation of exit criteria, input to the go/no-go decision, and verification right after deployment that the release works in the target environment.
• Operation — review production signals (errors, latency, user reports), test hot-fixes, run maintenance testing when the platform, a dependency or the data change, and turn every escaped defect into a regression test.

Try it: AI Requirement Ambiguity Detector Try it: AI Requirement Gap Analyzer Try it: Acceptance Criteria Generator

The SDLC ↔ STLC mapping

The table pairs each development phase with the test activities that run during it, the test work products they produce and the test level they prepare or execute. Read it row by row: the test activity in a row starts when the development output in the same row exists, not when the whole project reaches that row.

SDLC phase      | Development output          | Test activities (STLC ~ ISTQB)              | Test work products                 | Test level
----------------|-----------------------------|---------------------------------------------|------------------------------------|---------------------------
Requirements    | Stories, specs, NFRs        | Requirement analysis ~ test analysis;       | Review findings, test conditions,  | Acceptance (planned)
                |                             | test planning starts                        | risk list, draft test plan         |
Design          | Architecture, API contracts,| Analysis and design for integration and     | Integration test conditions,       | Integration, system
                | UI designs                  | system levels; environment needs identified | environment requirements           | (planned)
Implementation  | Code, unit tests, builds    | Test design and implementation; test data;  | Test cases, scripts, data,         | Component (developers)
                |                             | environment set-up; automated checks;       | automated checks                   |
                |                             | static analysis in CI                       |                                    |
Integration     | Integrated build            | Deploy to test env; smoke and integration   | Test logs, defect reports          | Component integration,
                |                             | test execution                              |                                    | system integration
Release         | Release candidate, then     | System, regression and acceptance           | Results, defects, status reports;  | System, acceptance;
                | deployed version            | execution; monitoring and control;          | go/no-go input, completion report  | smoke in production
                |                             | exit-criteria evaluation; deployment        |                                    |
                |                             | verification; test completion               |                                    |
Operation       | Running system, changes     | Maintenance and regression testing for      | Updated regression suite,          | Whatever the change touches
                |                             | fixes; review of production signals         | lessons learned                    |

Try it: Requirements → Test Cases

Shift-left and shift-right testing

Shift-left means moving test activities earlier in the lifecycle so defects are found when they are cheapest to fix. CTFL v4.0 describes the approach and gives typical practices: reviewing specifications from a tester’s perspective, writing test cases before the code is written, using continuous integration for fast feedback, running static analysis before dynamic testing, and starting non-functional testing at component level where possible. The syllabus also notes the cost side: shift-left may need extra training, effort or cost early in the project, which is expected to save effort later. Shift-left is established practice.

Shift-right means extending testing and observation into production: releasing a change to a small share of traffic first and comparing it with the baseline (canary release, as described in Google’s SRE workbook), hiding unfinished features behind feature flags, running synthetic checks against live endpoints, and watching error rates and latency after every deploy. Canary releases and production monitoring are established practice in teams that deploy continuously; controlled fault-injection experiments in production (often called chaos engineering) go a step further.

The two are complements, not alternatives. Shift-left reduces the number of defects that reach a build; shift-right limits the damage of the ones that still reach users and tells you which of them your pre-release tests missed. Testing in production never replaces pre-release testing, and it needs safeguards: dedicated test accounts, no real personal data in test transactions, a flag or rollback that can switch the change off in minutes.

• Shift-left examples — acceptance criteria reviewed before sprint planning; API contract tests written from the OpenAPI document before the endpoint exists; unit and static checks on every pull request.
• Shift-right examples — a canary on 5% of traffic with automatic rollback if the error rate rises above the baseline; a synthetic login check every minute; a post-deploy health check across all public APIs.

Try it: Acceptance Criteria Generator

Lifecycle models and how testing differs in each

The lifecycle model decides when test activities can happen, how much is written down and what the biggest testing risk is. The test activities themselves — analysis, design, execution, completion — exist in every model; what changes is their timing and granularity.

• Sequential (waterfall) — phases run in order and each finishes before the next begins. Dynamic testing is concentrated in a test phase after implementation; test planning and documentation are done up front and are usually formal. The main risk is lateness: defects in requirements are discovered months after they were written, and when development overruns, the test phase is the one that gets squeezed. The counter-measure is to do static testing (reviews of requirements and design) in the early phases even though dynamic testing waits.
• V-model — still sequential, but each development level is paired with a test level: requirements with acceptance testing, system specification with system testing, architectural design with integration testing, detailed design with component testing. Test analysis and design for each level start as soon as its development counterpart is produced, which is an early form of shift-left; execution still happens on the right-hand side of the V, after the code exists.
• Iterative and incremental — the product is built in increments, and each increment passes through its own design, build and test. Testing is repeated every iteration, so the growing regression suite becomes the main cost; without automation, each iteration spends more time re-checking old behaviour and less on the new.
• Agile / Scrum — the Scrum Guide defines Sprints of one month or less, an Increment that must meet the Definition of Done, and three accountabilities (Product Owner, Scrum Master, Developers) with no separate tester role: everyone who creates the Increment is a Developer, so testing is a whole-team responsibility inside the Sprint. Documentation is lighter, acceptance criteria and the Definition of Done work as the exit criteria, and test-first practices (TDD, ATDD, BDD) are common. The agile testing quadrants — defined by Brian Marick and described in Lisa Crispin and Janet Gregory’s book Agile Testing — help a team check that business-facing, technology-facing, manual and automated testing are all present.
• DevOps and continuous delivery — every change passes through a CI/CD pipeline that builds, deploys and runs automated tests, so the pipeline is the main test execution engine and quality gates live in it. Releases are small and frequent, which lowers the risk of each one, and shift-right monitoring closes the loop. DORA’s change fail rate and failed deployment recovery time are useful signals of whether testing in the pipeline is doing its job. CTFL v4.0 notes that manual testing from the user’s perspective is still needed and that the pipeline itself must be built and maintained.

Model          | When dynamic testing runs        | Documentation      | Main testing risk                     | Key practice
---------------|----------------------------------|--------------------|---------------------------------------|------------------------------
Waterfall      | After implementation, one phase  | Formal, up front   | Requirement defects found late;       | Early reviews of requirements
               |                                  |                    | test phase squeezed                   | and design
V-model        | Per level, right side of the V   | Formal, per level  | Execution still late                  | Design tests per level early
Iterative      | Every iteration                  | Moderate           | Regression effort grows each round    | Automate regression
Scrum          | Inside every Sprint              | Light, just enough | "Done" without testing done           | Testing in Definition of Done
DevOps / CD    | On every change, in the pipeline | Pipeline as record | Slow or flaky pipeline; blind spots   | Fast suites + monitoring

Entry and exit criteria across the lifecycle

Entry criteria define the preconditions for starting an activity; exit criteria define what must be achieved before it can be declared complete. CTFL v4.0 notes that in agile teams exit criteria are often called the Definition of Done and entry criteria for a user story the Definition of Ready. The end-to-end QA pillar gives the general overview and the testing life cycle page gives criteria for each STLC phase; at SDLC level the useful gates are the hand-overs between development phases:

• Requirements → design — every story in scope has acceptance criteria including error paths; the ambiguity review is done; open questions have an owner and a date.
• Design → implementation — API contracts are published; non-functional targets are numbers, not adjectives; the test environment needs are agreed.
• Implementation → integration — the build is green; unit tests pass; static analysis shows no new critical findings; the change has been code-reviewed.
• Integration → release — the release candidate deploys to the test environment; the smoke suite passes; the test data baseline is loaded. This is the entry to system and acceptance testing on the release candidate.
• Within release, release candidate → production (the go/no-go decision) — planned tests executed or explicitly descoped; no open blocker or critical defects; regression suite green; residual risks accepted in writing by the product owner.
• Release → operation — deployment verification passed; dashboards and alerts exist for the new behaviour; rollback has been rehearsed.

Worked example: one feature through both lifecycles

For example, a fictional online store in Riyadh adds “pay in 4 instalments” at checkout for orders between SAR 200 and SAR 5,000, through an external instalment provider. Here is what testing does in each SDLC phase.

• Requirements — the tester’s review asks three questions the story never answered: how is SAR 999.99 split into four payments (who gets the rounding halala)? What does the shopper see if the provider declines? How is a partial refund handled after two instalments were paid? The answers become acceptance criteria.
• Design — the provider’s API contract is reviewed; the tester asks for a sandbox account and a mock for the decline and timeout responses, and for a rule on how long checkout waits before giving up.
• Implementation — test cases are designed with boundary values (199.99, 200.00, 5,000.00, 5,000.01), equivalence classes for provider responses (approved, declined, timeout, malformed) and a risk ranking that puts payment and refund first; API checks are automated as the endpoints appear.
• Integration — tests run against the provider sandbox: approval, decline, a 30-second timeout, a duplicate callback. A defect is found: “Order stays in PENDING forever when the provider callback arrives twice.”
• Release — full checkout regression, exit criteria evaluated (no open critical defects, all high-risk conditions passed), release to 5% of traffic first with the instalment error rate watched against the card-payment baseline.
• Operation — production shows a small rate of provider timeouts at peak hours; the tester adds a regression test for the retry path and a monitoring check for the timeout rate.

Try it: Boundary Value Analysis Try it: Risk-Based Test Generator Try it: Regression Scenario Generator

Map of this topic and where to go next

This pillar is the entry point for lifecycle questions. The software testing life cycle page goes through each STLC phase in depth — tasks, work products, entry and exit criteria per phase — and maps it to the ISTQB test process and ISO/IEC/IEEE 29119-2. Related pillars cover the neighbouring subjects: static testing and reviews (how requirements and designs are reviewed before any code runs), test strategy, test planning and risk-based testing (how the effort is decided and ranked), the defect lifecycle and triage (what happens to a defect after it is reported), and CI/CD testing with smoke, sanity and regression testing and deployment verification (how the cycle runs inside a pipeline).

For the overall picture of test levels, test types and release gates, see the end-to-end quality assurance pillar; for what to automate and what to keep manual, see the manual versus automated testing comparison. A short self-check for any team:

• Testers review requirements before development starts, not after the first build.
• Each development phase has a named test activity and an owner.
• Entry and exit criteria exist for the hand-overs, and a missed criterion is an explicit, recorded decision.
• The regression suite runs automatically on every integrated build.
• Production signals are reviewed after every release and escaped defects become regression tests.

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-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsISO/IEC/IEEE · 2022The international software-testing standard: concepts, processes, documentation and techniques.
• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020The definition of Scrum: its accountabilities, events and artifacts, including the Definition of Done that testing helps meet.
• Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009The agile testing quadrants and how testers work inside a delivery team — the basis of "testing at the right layer".
• Continuous Integration (Martin Fowler)martinfowler.com · 2024The widely referenced description of continuous integration: integrate often, keep the build self-testing and fast, and fix a broken build immediately.
• DORA's software delivery performance metricsDORA (Google Cloud)The DORA delivery metrics — change lead time, deployment frequency, failed deployment recovery time, change fail rate and related measures — grouped by throughput and instability.
• Canarying Releases — The Site Reliability WorkbookGoogle / O'Reilly MediaReleasing a change to a small share of traffic first and comparing it with the baseline before rolling out — deployment verification as practised in SRE.