STLC: The Six Phases of the Software Testing Life Cycle

TL;DR

• STLC stands for Software Testing Life Cycle, a six-phase sequence covering requirement analysis, test planning, test case development, environment setup, test execution, and test cycle closure.
• Each phase carries entry and exit criteria. Skipping those checks is what turns a test cycle into a stall, usually at environment setup.
• STLC runs inside SDLC rather than beside it, and in Agile teams the six phases compress into a sprint instead of disappearing.
• Autosana handles environment setup, execution across real devices, and closure reporting inside your pipeline, which removes the phases where cycles usually lose days.

A test cycle stalls because the staging environment points at a production payment gateway. The mismatch surfaces two days later, after a tester files a defect about duplicate charges.

Environment setup is the fourth phase of the STLC, and it carries its own entry and exit criteria. Teams that treat it as background work while test cases get written lose days to exactly this class of problem.

This guide walks the six STLC phases, the criteria that gate each one, how the sequence compresses under Agile, and what mobile adds to it.

What STLC Is

STLC is the Software Testing Life Cycle: a defined sequence of phases covering testing activity from requirement analysis through cycle closure. Each phase has entry criteria that start it, deliverables it produces, and exit criteria that end it.

The ISTQB Foundation Level syllabus describes the same activities as a fundamental test process. The ISO 29119 standard formalizes them as test management and dynamic test processes.

The value of naming phases is accountability. A cycle running late is easier to diagnose when you can say which phase it is stuck in, and which exit criterion remains unmet.

The Six Phases of the STLC

Phase one: requirement analysis

Testers read the requirements and determine what is testable. Ambiguity gets raised here, where clarifying costs a conversation.

Deliverables are a list of testable requirements, a requirement traceability matrix, and a list of questions for the business. Exit happens when every requirement is either marked testable or logged as an open question.

The requirement saying the dashboard should load quickly leaves phase one as a question, because quickly carries no test.

Phase two: test planning

A test lead defines scope, approach, resourcing, and schedule. The plan names what gets automated, what stays manual, which devices and browsers the cycle covers, and what risks justify the allocation.

Deliverables are the test plan, effort estimate, and tooling decisions. Exit happens when the plan has stakeholder sign-off and the schedule fits the release date.

Phase three: test case development

Testers write cases and prepare test data. Each case names preconditions, steps, expected results, and the requirement it traces to.

Deliverables are the test cases, automation scripts, and test data sets. Exit happens when cases are peer reviewed and traceability back to requirements is complete.

Phase four: test environment setup

The environment gets built and verified: builds deployed, services configured, data seeded, device access arranged. This phase runs in parallel with phase three, which is why teams forget it has its own exit criteria.

Deliverables are a ready environment and a smoke test confirming it works. Exit happens when a smoke test passes against the environment and every integration points at the intended target.

That last check is the one skipped in the opening example.

Phase five: test execution

Cases run, results get recorded, defects get logged and retested. Execution follows the plan's priority order, so critical paths run before edge cases.

Deliverables are execution results, defect reports, and updated traceability. Exit happens when planned cases have run, defects are triaged, and blockers are resolved or formally accepted.

Regression testing and UAT both sit inside this phase.

Phase six: test cycle closure

The team compiles results, evaluates coverage against plan, and records what to change next cycle. Metrics worth capturing include defect density, defect leakage to production, and the ratio of planned to executed cases.

Deliverables are a test closure report and a lessons-learned record. Exit happens when the report is circulated and improvement actions have owners.

Closure is the phase most often skipped under deadline pressure, which is why the same environment mistake repeats across cycles.

STLC vs SDLC

The STLC is a subset rather than a parallel track. Every STLC phase maps onto an SDLC phase, with requirement analysis aligning to SDLC requirements, and execution aligning to SDLC testing and deployment readiness.

Teams treating the STLC as something that begins after development finishes get the sequential waterfall version, where testing absorbs every schedule overrun upstream.

How the STLC Adapts for Agile and CI/CD

The six phases persist under Agile, compressed into a sprint and repeated every iteration.

Requirement analysis happens during backlog refinement, where testers raise testability questions before a story enters the sprint. Planning becomes a sprint-level decision about coverage rather than a document. Case development runs alongside implementation. Environment setup gets automated so it costs minutes.

Execution runs continuously rather than in a phase-shaped block. Continuous integration means the execution phase of the STLC fires on every commit, which is the largest structural change Agile makes to the model.

Closure compresses into the sprint retrospective, where the metrics that mattered get reviewed alongside everything else.

The phases that break under this compression are the ones needing human judgment. Requirement analysis and closure resist automation, so teams under pressure drop them first and then wonder why the same defects recur.

STLC for Mobile Apps

Mobile changes three phases materially.

Test planning carries a device matrix decision. Which models, OS versions, and vendor forks the cycle covers is a planning output, and deriving it from your own analytics beats copying a market share list. Mobile app testing coverage tracks directly to this decision.

Environment setup extends to device access. Alongside build deployment and service configuration, the cycle needs real devices available, provisioned, and in a known state. This is the phase where mobile cycles most often lose days.

Execution multiplies by the matrix. One test case running across eight configurations is eight executions, so execution time scales with matrix width rather than case count. Parallel execution across devices is what keeps that manageable.

Closure adds store-facing metrics. Crash-free session rate and ANR rate belong in the closure report, since they measure what the previous release actually delivered. Testing a mobile app end to end means closing that loop.

Entry and Exit Criteria Keep the STLC Honest

Phases without criteria are labels. The criteria are what give the STLC its diagnostic value.

Two habits make these work. Write the criteria before the cycle starts, since criteria written midway get shaped to fit current reality. Hold the boundary, because starting execution against an unverified environment is how the opening example happens.

A cycle reporting itself as on track while phase four remains unverified is reporting optimism. The criteria convert that into a checkable fact.

How Autosana Fits

We built Autosana around the STLC phases where mobile cycles lose the most time, which are environment setup and execution.

Our environments configuration handles backend targets, locale, and network profile per run, so the integration check from phase four becomes a configuration value rather than a manual verification step.

We execute across real iOS, Android, and web devices in parallel through real device testing, which keeps the execution phase from scaling linearly with matrix width. Device provisioning happens on demand rather than through a hardware lab booking.

Our flows describe intent, so case development produces artifacts that survive UI change. A test case written this cycle stays valid through the next redesign.

We organize flows into suites triggered by CI/CD integration, which is how the execution phase runs continuously rather than as a block. Every run records video and step results, so closure reporting draws on evidence that generated itself.

Conclusion

Look at your last test cycle and name the phase it was stuck in longest.

For mobile teams the answer is usually phase four, environment setup, and the reason is that it runs in parallel with case development and therefore gets no exit check of its own. A smoke test against the environment before execution starts costs ten minutes.

Write the exit criteria for all six phases before the next cycle begins. The STLC becomes useful at exactly the point those criteria are written down and held.

FAQ

What does STLC stand for?

STLC stands for Software Testing Life Cycle. It is a six-phase sequence covering requirement analysis, test planning, test case development, environment setup, test execution, and test cycle closure.

What are the six phases of the STLC?

Requirement analysis, test planning, test case development, test environment setup, test execution, and test cycle closure. Each phase has entry criteria, deliverables, and exit criteria.

How does the STLC differ from the SDLC?

SDLC covers the entire software development process from requirements through maintenance. STLC covers testing activity within it, so the STLC is a subset that maps onto SDLC phases.

What are entry and exit criteria in the STLC?

Entry criteria are conditions that must hold before a phase begins. Exit criteria are conditions confirming it is complete. Writing them before the cycle starts keeps phase reporting honest.

Does the STLC apply to Agile teams?

Yes, compressed into each sprint. Requirement analysis moves to backlog refinement, execution runs continuously through CI, and closure compresses into the retrospective rather than disappearing.

Which STLC phase causes the most delay?

Environment setup, because it runs in parallel with case development and often receives no exit check. A smoke test confirming integrations point at intended targets catches most of these problems early.

What changes in the STLC for mobile apps?

Planning adds a device matrix decision, environment setup extends to device provisioning, execution multiplies by matrix width, and closure adds crash-free session and ANR metrics from the previous release.

What goes into a test closure report?

Coverage against plan, defect density, defect leakage to production, the ratio of planned to executed cases, and improvement actions with named owners for the next cycle.