ISTQB-aligned · ISO/IEC/IEEE 29119

STLC Explained: The 6 Phases of the Software Testing Life Cycle

STLC — Software Testing Life Cycle — is the academic six-phase framework that defines how testing activities flow from requirement to closure. This guide walks each phase with its entry / exit criteria, deliverables, and the failure mode teams hit most often when they shortcut it.

See how Testriq applies it Test Strategy Template

STLC vs SDLC — quick distinction

SDLC (Software Development Life Cycle) describes the full build pipeline — requirements through maintenance. STLC describes the testing-specific phases that run in parallel with SDLC's development phase. Where SDLC says "Test the build", STLC tells you the six structured phases that turn a requirement into a defensible closure report.

In Agile / DevOps the STLC phases compress and overlap — Requirement Analysis happens during story grooming, Test Case Design happens alongside development, Execution runs continuously in CI, Closure happens every sprint. The phases stay; the cadence changes.

The six STLC phases

Each phase has explicit entry criteria, deliverables, exit criteria, and a common pitfall to avoid.

1. Requirement Analysis

Purpose: Read what was built (and what wasn't), map it to testable artifacts, and surface ambiguity while it's still cheap to resolve.

Entry criteria

  • Approved requirements / user stories / acceptance criteria available
  • Stakeholder access for clarifications

Deliverables

  • Testability matrix (each requirement → 1+ test scenario)
  • List of ambiguities + open questions back to PM
  • RTM (Requirement Traceability Matrix) baseline

Exit criteria

  • RTM baselined
  • Open questions either resolved or risk-accepted in writing

Common pitfall: Skipping this phase because "the stories are clear enough" — ambiguity that's free to resolve here costs 10-100× to fix once code ships.

2. Test Planning

Purpose: Decide what gets tested, how, by whom, with what tools, against what criteria — the strategic doc that gates execution.

Entry criteria

  • RTM baselined
  • Test approach (manual / automation / hybrid) agreed

Deliverables

  • Test plan document (IEEE-829-aligned)
  • Effort estimation + schedule
  • Resource + tooling commitments
  • Risk register + mitigation plan

Exit criteria

  • Test plan signed off by stakeholders
  • Schedule + budget approved

Common pitfall: Treating the test plan as a one-time document. The plan must be a living artifact that updates per release; otherwise it ossifies into a compliance prop nobody reads.

3. Test Case Design & Development

Purpose: Convert requirements into executable test cases — positive, negative, boundary, equivalence-class, decision-table, exploratory charters.

Entry criteria

  • Test plan signed off
  • Test design techniques agreed (BVA, ECP, decision-table, state-transition)

Deliverables

  • Detailed test cases (per /test-case-template format)
  • Automation scripts (where applicable)
  • Test data sets + generation scripts
  • Updated RTM with case IDs

Exit criteria

  • Test cases peer-reviewed
  • Automation scripts committed + CI-runnable

Common pitfall: Writing only happy-path test cases. Production bugs almost always come from inputs nobody thought to test — invalid Unicode, daylight-savings edges, zero-quantity orders, expired tokens at 23:59.

4. Test Environment Setup

Purpose: Stand up an environment that mirrors production closely enough for results to be trusted, and isolated enough to test destructively.

Entry criteria

  • Test cases ready
  • Infra requirements documented (DB sizes, integrations, mocks)

Deliverables

  • Provisioned test environment
  • Seeded test data
  • Mock services / stubs for unavailable integrations
  • Smoke-test pass on the bare environment

Exit criteria

  • Environment smoke-test passes
  • Integration endpoints reachable
  • Access provisioned for QA team

Common pitfall: Sharing a single staging environment across QA, demos, and partner integration testing. A broken demo invalidates a day of test runs, and partner tests step on QA data without anyone realising.

5. Test Execution

Purpose: Run the tests. Log defects. Re-test. Repeat until exit criteria are met or the build is rejected.

Entry criteria

  • Environment smoke-test green
  • Build under test deployed
  • Test cases + automation scripts ready

Deliverables

  • Daily execution status
  • Defect log (severity + reproducibility + impact)
  • Pass/fail metrics per requirement
  • Updated RTM (executed status)
  • Exploratory testing session notes

Exit criteria

  • All planned test cases executed
  • All P0/P1 defects resolved + verified
  • Exit-criteria metrics met (coverage, pass rate, defect density)

Common pitfall: Treating "all tests pass" as the only exit signal. A pass rate of 100% on a test suite that misses the production failure modes is worse than a 95% pass rate on a suite that covers them — false confidence is more expensive than honest gaps.

6. Test Cycle Closure

Purpose: Capture what was learned, file the artifacts, hand off to operations / support, and feed the next cycle a sharper risk register.

Entry criteria

  • Exit criteria met
  • Sign-off given by stakeholders

Deliverables

  • Test closure report (executive summary + drilldown)
  • Coverage + defect-density metrics
  • Lessons-learned retrospective
  • Automation-candidate prioritisation
  • Updated risk register for next cycle

Exit criteria

  • Test closure report distributed
  • Artifacts archived per retention policy
  • Lessons-learned actioned in next cycle's plan

Common pitfall: Skipping closure when the release is "already out the door". Without retrospective discipline, every defect class repeats forever and automation never gets prioritised correctly.

Templates referenced above

Testriq QA Process

How we apply + extend STLC in real engagements.

Read

Test Strategy Template

Structure for the strategic doc that gates Test Planning.

Read

Test Plan Template

IEEE-829-aligned plan structure.

Read

Test Case Template

Field-by-field format used in Test Case Design.

Read

Frequently Asked Questions

What's the difference between STLC and SDLC?

SDLC (Software Development Life Cycle) is the full software-build framework — requirements, design, implementation, testing, deployment, maintenance. STLC (Software Testing Life Cycle) is the testing-specific 6-phase framework that runs in parallel with SDLC's development phases. Where SDLC says "Test the build", STLC tells you the six phases that gets you from requirement to closure report.

Is STLC waterfall-only, or does it work in Agile / DevOps?

STLC phases describe activities, not gates. In waterfall they're sequential and gated. In Agile / DevOps they collapse and overlap — Requirement Analysis happens during story grooming, Test Case Design happens alongside development, Execution runs continuously in CI, Closure happens per-release every two weeks. The phases stay; the cadence compresses.

What does "entry criteria" and "exit criteria" mean in STLC?

Entry criteria are the conditions required before a phase can begin (e.g., RTM baselined before Test Planning starts). Exit criteria are the conditions required before a phase can be considered complete (e.g., all P0/P1 defects resolved before Test Execution exits). Without explicit entry/exit criteria, phases slide into each other and the "done" bar becomes negotiable — usually downwards.

What is the RTM (Requirement Traceability Matrix)?

A table that maps every requirement / acceptance criterion to one or more test cases, and tracks each test case's execution status. The RTM is the artifact that proves coverage to auditors: requirement X is exercised by test cases Y and Z, both passed on date D against build B. Without an RTM, "we tested it" is a claim you can't substantiate.

Does Testriq follow STLC strictly?

We use STLC as the academic backbone, then layer our own Discovery + Risk Modeling phase before Requirement Analysis and an explicit Reporting + Evidence phase before Closure. See /qa-process for our adapted six-phase process and how it maps to + extends STLC.

Which STLC phase is most often skipped?

Test Environment Setup. Teams assume staging is "close enough", only to discover under load testing that connection-pool limits, queue depths, or storage-tier differences cause production-only failures. Treat environment setup as a first-class phase with its own smoke-test gate.

From theory to production — let Testriq run STLC for you

ISTQB-certified testers, ISO 9001 + ISO/IEC 27001 controlled processes, evidence-grade outputs from phase 1 through phase 6.

Talk to a QA Lead