What is STLC in software testing? A 2026 walkthrough

The Software Testing Life Cycle (STLC) is the structured sequence of phases a testing effort moves through, from requirements analysis to test closure. The traditional version has six phases. In 2026, agile teams usually run a compressed version that fits inside a two-week sprint, but the phases themselves still apply. Here's what each phase actually involves and how it's changed in the agile and AI eras.

The six STLC phases, in plain English

• 1. Requirements analysis. Read the spec or user story. Identify what needs testing. Flag ambiguous requirements before they become bugs.
• 2. Test planning. Decide scope, strategy, tools, owners, and exit criteria. See test plan vs test strategy for the document split.
• 3. Test case design. Write the cases (manual, scripted, or agentic intent). Link each case to the requirement it verifies.
• 4. Test environment setup. Stand up the staging environment, seed test data, configure feature flags, provision agents.
• 5. Test execution. Run the cases. Log defects. Re-run after fixes. Track pass-rate.
• 6. Test cycle closure. Sign off, archive evidence, retrospect on what didn't work, update the strategy if needed.

These phases don't have to be sequential or heavy. They do have to happen. Skip one and the others compensate badly.

How STLC shows up in modern QA teams

The waterfall version of STLC (each phase done thoroughly before the next starts) belongs to the 2010s. In 2026, agile teams compress all six phases into a sprint, often with phases overlapping. Requirements analysis happens during refinement. Planning is a short paragraph in the sprint goal. Case design happens in parallel with development. Environment setup is automated and continuous. Execution is mostly CI. Closure is the sprint demo plus the retrospective.

The structure is still there. It's just faster and more concurrent than the textbook diagrams suggest.

The agile STLC, in eight bullets

The compressed version that fits in a sprint:

• Read the user story; flag missing acceptance criteria before sprint start.
• Pick or generate test cases during sprint planning.
• Developers write unit and integration tests as part of the work.
• QA writes or generates scripted and agentic cases in parallel.
• CI runs unit and integration on every PR; scripted E2E on merge.
• QA runs manual and agentic sessions before the feature is called done.
• Defects loop back as new tickets and new cases.
• Sprint retro covers what to change in the strategy for next time.

A modern QA workflow example

A team picks up a new search-filter feature on Monday. By Tuesday the PM has clarified two ambiguous acceptance criteria the QA engineer flagged during refinement (requirements analysis). The sprint goal names the feature and the testing scope (planning). On Wednesday and Thursday the developer writes the unit and integration tests with the code; the QA engineer generates a first draft of E2E cases from the story and edits the ones the AI got wrong (case design). The CI pipeline already runs the staging environment on every PR (environment setup is continuous). Friday is execution day: unit and integration on every commit, scripted E2E on merge, an agentic exploratory session in the afternoon. The next Monday's retro reviews two things that broke and one thing the strategy should change (closure).

All six phases happened. None of them took the textbook two days each.

The common mistake: skipping the closure

The phase teams skip most often is the last one. The release ships, everyone moves to the next feature, and the lessons from the cycle don't feed back into the strategy. The result is a strategy that drifts further from reality every sprint, until the documented version and the lived version share almost no overlap.

Closure doesn't have to be heavy. A standing fifteen-minute item in the sprint retro covering "what did QA find that we didn't expect" is enough to keep the strategy current. The cost of skipping it compounds over quarters.

How AI changes the phases

Two phases compress dramatically in 2026: case design (AI generation makes first drafts much faster) and execution (agentic browsers run more cases than humans could). The other four phases stay human work. Requirements analysis still needs judgement. Planning still needs intent. Environment setup needs platform engineering. Closure needs the team's honest retrospective.

The teams that get the most from AI are the ones that lean on AI for the first two and stay disciplined about the other four. The teams that try to let AI do all six end up with execution decoupled from intent.

The compliance dimension

STLC matters most in regulated industries, where each phase needs documented evidence. The ISO/IEC/IEEE 29119 testing standard is the closest thing to a vendor-neutral reference for what each STLC phase should produce. For AI features specifically, the EU AI Act adds requirements around the testing of non-deterministic systems, which the traditional STLC was never designed for.

Where qtrl fits

qtrl holds artefacts from phases 3-6 in one place: cases (design), agents (execution environment, execution), runs and audit trails (execution, closure). Manual and AI execution share the same case repository and run history. The closure phase becomes much shorter when the evidence is already there in queryable form.

Frequently asked questions

Is STLC the same as SDLC? No. SDLC (Software Development Life Cycle) covers the whole development process. STLC is specifically the testing portion. STLC happens inside SDLC.

Does agile testing still use STLC? Yes, in a compressed form. The phases happen inside a sprint instead of across months.

What's the entry criteria for each STLC phase? Traditionally, the previous phase's exit criteria. In practice, phases overlap on agile teams, so the rule is closer to "you can start a phase once the inputs you need are in good enough shape."

Is STLC ISTQB material? Yes. The ISTQB Foundation syllabus covers STLC in detail and is the cleanest vendor-neutral reference.

Who owns each STLC phase? It depends on team shape. QA usually owns planning, case design, and execution. Developers own environment setup (via infrastructure-as-code) and contribute to execution at the unit and integration layers. Product contributes to requirements analysis. Closure is usually a team activity.

The phase nobody respects enough

Requirements analysis has the highest leverage of the six phases and gets the least attention. Every ambiguous acceptance criterion you catch before code gets written saves five bugs you would have found during execution. The QA engineers who push back on vague stories during refinement are doing the most valuable work in the entire cycle. The ones who wait until execution to surface the same questions are usually doing the most firefighting.

For a system that holds case design, execution, and closure evidence in one place, qtrl was built for that. Try it out.