Software testing guide

Basics

Software Testing Life Cycle (STLC)

STLC is the specialist slice of SDLC focused on planning tests, designing them, executing them, and learning from the results—structured so quality work is traceable, not accidental.

Reading time ~13 minutes · Last updated May 3, 2026

Simple analogy: rehearsing a school play

Directors read the script (requirements), block scenes (test planning), teach actors their cues (test design), run dress rehearsals (execution), fix loose props (defect management), and hold a retrospective after opening night (closure). STLC is that rehearsal discipline applied to software releases.

Common STLC phases

  1. Requirement analysis: testers study specs, acceptance criteria, regulations. Outputs include clarified assumptions and testability risks.
  2. Test planning: define scope, schedule, resources, tools, entry and exit criteria, metrics (Defect Detection Percentage, automation ROI targets).
  3. Test design / development: author cases, data sets, automation scripts, environment checklists; peer-review for coverage gaps.
  4. Environment setup: provision configs, secrets, representative datasets, integrations—often parallel to development when using ephemeral environments.
  5. Test execution: manual runs, CI pipelines, exploratory charters, defect logging, retesting fixes.
  6. Closure: summarise coverage vs risk, residual defects, lessons learned, knowledge base updates.

Example: STLC inside a two-week Scrum sprint

  • Day 0–1: refinement workshop clarifies API pagination rules—test analysts update a lightweight RTM snippet tying story IDs to behaviours.
  • Day 2: sprint planning selects regression subsets + new cases for risky migrations.
  • Mid-sprint: automation engineers stabilise flaky selectors while developers complete features behind toggles.
  • Pre-release: exploratory session focuses on cross-browser QR login; critical defects block toggle enablement.
  • Sprint review / retro: closure metrics feed into next sprint’s risk backlog (maybe performance debt spotted during execution).

How STLC hugs SDLC without duplicating it

SDLC spans all engineering roles; STLC answers “how will we obtain credible evidence about quality each step?” When organisations gate releases, STLC artefacts (plans, logs, dashboards) demonstrate diligence—even if teams operate iteratively instead of waterfall binders.

Expert considerations

Shift-left initiatives collapse phases: testers participate during requirement analysis with reusable Given / When / Then scenarios that become automated checks. Continuous testing blurs execution into development hours, yet governance still expects identifiable planning and closure evidence for regulated industries.

Quality intelligence platforms aggregate STLC telemetry (pass rates, flake rates, MTTR) alongside SDLC signals (lead time, deployment frequency) so executives see holistic health—not vanity green dashboards.

Takeaways

  • STLC supplies repeatable structure for something creative—testing—without killing agility.
  • Invest in planning and environment fidelity early; execution surprises usually trace upstream gaps.
  • Close loops with metrics and narratives stakeholders actually understand.