STLC: The 6 Phases of the Software Testing Life Cycle

If you are studying the software testing life cycle, you are learning how testing work moves from understanding requirements to closing a cycle with evidence and lessons. STLC is not a pile of random test activities. It is a structured path with goals, entry criteria, tasks, deliverables, and exit criteria. Teams that skip structure still test, but they struggle to explain coverage, risk, and readiness.

This guide explains the six common STLC phases in depth, compares STLC with SDLC, shows entry and exit criteria, maps STLC to Agile and Waterfall, and gives practical examples you can use in real projects and interviews.

What Is the Software Testing Life Cycle (STLC)?

The software testing life cycle (STLC) is the sequence of testing activities performed to plan, design, execute, and close quality work for a software product or release. It starts when testing scope becomes visible and ends when the team has executed the agreed work, reported status, and captured learning.

STLC answers:

• What needs to be tested and why?
• How will we test it?
• What cases, data, and environments do we need?
• What did we find?
• Are we done enough to release or move on?
• What should improve next time?

STLC does not mean testing starts only after coding finishes. In modern teams, testing thinking begins early, even when formal execution waits for a build.

STLC vs SDLC

Dimension	SDLC	STLC
Focus	Building and delivering software	Verifying and validating quality
Typical start	Idea, demand, or project start	Requirement or change analysis for testing
Main outputs	Working software, features, releases	Plans, cases, results, defects, quality reports
Primary owners	Product + engineering (+ design)	QA + whole team quality collaboration
Relationship	Parent delivery lifecycle	Specialized lifecycle inside and beside SDLC

Simple mental model:

• SDLC builds the thing.
• STLC questions the thing with evidence.
• Both must align on scope, risk, and done.

If your organization documents approach versus release tactics, connect STLC planning artifacts to test plan vs test strategy.

The 6 Phases of STLC

Most training materials and many organizations use these six phases:

1. Requirement analysis
2. Test planning
3. Test case development
4. Test environment setup
5. Test execution
6. Test cycle closure

Some models insert test design as separate from case writing, or put data preparation in its own lane. The six phase model remains the most useful default for interviews and process design.

Requirement analysis
        |
Test planning
        |
Test case development
        |
Test environment setup
        |
Test execution
        |
Test cycle closure

In Agile, draw the same phases as a loop, not a one way waterfall.

Phase 1: Requirement Analysis

Goal

Understand what must be tested, what can be tested, and what is unclear.

Main Activities

• Review user stories, PRDs, acceptance criteria, designs, and API contracts.
• Identify testable requirements and non functional needs.
• Mark requirements as functional, integration, security, performance, accessibility, and so on.
• List dependencies and open questions.
• Identify automation candidates at a high level.
• Highlight missing acceptance criteria.

Entry Criteria

• Requirements or change requests are available in some draft or agreed form.
• Testing team has access to product context and stakeholders.

Exit Criteria

• Testable requirements list exists.
• Ambiguities logged and assigned.
• High level scope boundaries understood.
• Initial risk notes captured.

Deliverables

• Requirement traceability draft.
• Query log for product and engineering.
• Automation feasibility notes.
• Preliminary scope in or out list.

Example

Story: "Buyers can reset passwords by email."

Analysis notes:

• Need expiry rule confirmation (30 minutes?).
• Need message behavior for unknown emails.
• Need password policy source of truth.
• Need email deliverability in staging.
• Security risks: enumeration, token reuse, rate limits.
• Accessibility: form labels and error announcements.

Good analysis prevents late surprises during execution.

Phase 2: Test Planning

Goal

Decide the approach, resources, schedule, tools, and risk response for the cycle.

Main Activities

• Define scope and objectives.
• Choose test types and levels.
• Estimate effort.
• Assign roles.
• Select tools.
• Identify environment needs.
• Define entry and exit criteria for execution and release testing.
• Plan risk mitigation.
• Decide metrics and reporting cadence.

Entry Criteria

• Requirement analysis is sufficiently complete to plan.
• Release or sprint goals are known enough to schedule against.

Exit Criteria

• Test plan approved or accepted by stakeholders under team process.
• Resources and schedule are realistic.
• Risks and contingencies documented.

Deliverables

• Test plan document or living plan page.
• Effort estimate.
• Tooling and environment request list.
• Risk register section for testing.

Planning is where STLC connects to strategy. Strategy says how the org tests in general. The plan says what this release will do. Keep that distinction clean.

Lightweight Agile Plan Skeleton

Sprint 42 testing plan
Scope in: checkout coupon redesign, password reset expiry fix
Scope out: native mobile apps, partner portal
Risks: email provider flakiness in staging, limited test cards
Approach: API checks + UI journeys + one exploratory charter daily
Automation: extend coupon regression in CI
Exit for sprint goal: no open P0/P1 in scope, smoke green on RC

Phase 3: Test Case Development

Goal

Design the checks that will generate evidence.

Main Activities

• Write test scenarios and cases.
• Prepare test data design.
• Create automation scripts where planned.
• Peer review cases.
• Update traceability matrix.
• Identify negative, boundary, and permission cases.

Entry Criteria

• Requirements stable enough for design, or changes are versioned.
• Plan defines scope and priorities.

Exit Criteria

• Prioritized cases reviewed.
• Traceability covers critical requirements.
• Data needs identified.
• Automation scripts for planned candidates ready or scheduled.

Deliverables

• Test case suite.
• Test data sheets or factories.
• Automation code for agreed coverage.
• Review notes.

This phase is where technique skill shows. Use strong case writing practices from the test case guide, and design methods such as equivalence partitioning where inputs have classes and edges.

Sample Traceability Snippet

Requirement	Cases	Priority
Reset link expires in 30 minutes	TC-AUTH-021, TC-AUTH-022	High
New password must meet policy	TC-AUTH-023 to 027	High
Old password fails after reset	TC-AUTH-028	High
Unknown email messaging	TC-AUTH-029	Medium

Phase 4: Test Environment Setup

Goal

Prepare a stable, representative place to run tests.

Main Activities

• Request or configure environments.
• Install builds and dependencies.
• Connect test data stores.
• Validate access, roles, and integrations.
• Establish monitoring and log access.
• Run environment smoke checks.
• Document known environment limitations.

Entry Criteria

• Environment architecture known.
• Access requests can be granted.
• Build pipeline can deploy to the target.

Exit Criteria

• Environment is available and smoke verified.
• Test accounts and data baselines ready.
• Blocking environment issues escalated or resolved.

Deliverables

• Environment readiness checklist.
• Credential and access map (stored securely).
• Baseline data set description.
• Known limitations list.

Environment Readiness Checklist

[ ] Correct build deployed
[ ] Health endpoints green
[ ] Auth provider configured
[ ] Mail catcher or email sandbox working
[ ] Payment sandbox keys present
[ ] Feature flags set for the test scope
[ ] Test users for each role exist
[ ] Log access confirmed
[ ] Timezone and locale settings known
[ ] Data reset procedure documented

Environment work often runs in parallel with case development. That parallel path is normal and healthy.

Phase 5: Test Execution

Goal

Run the planned tests, log results, and report defects.

Main Activities

• Execute smoke on each new build.
• Run assigned suites.
• Log pass, fail, blocked, skipped with reasons.
• File defects with evidence.
• Retest fixes.
• Perform regression according to plan.
• Hold exploratory sessions for unknown risk.
• Report daily or sprint quality status.

Entry Criteria

• Test cases ready for the scope being executed.
• Environment ready.
• Build is available and preferably smoke green.
• Entry criteria from the plan are met.

Exit Criteria

• Planned mandatory cases executed or explicitly waived.
• Critical defects closed or accepted with documented risk.
• Regression goals met.
• Results reported and understood by stakeholders.

Deliverables

• Execution results.
• Defect reports.
• Updated traceability with status.
• Progress and risk reports.

Execution quality depends on earlier phases. Weak analysis and weak cases create noisy execution. Weak environments create blocked time.

For defect quality during execution, use a strong bug report standard so developers can act quickly.

Daily Execution Board Example

Suite	Planned	Pass	Fail	Blocked	Notes
Smoke	12	12	0	0	Green on build 1.18.3
Auth feature	28	24	2	2	Email delay blocked 2
Coupon regression	15	14	1	0	Double apply bug open
Exploratory	2 sessions	-	-	-	Charter notes attached

Phase 6: Test Cycle Closure

Goal

Close the loop with evaluation, archives, and learning.

Test Closure Activities in STLC

Common closure activities:

1. Confirm exit criteria status with evidence.
2. Publish a test summary report.
3. Analyze defect metrics and escaped defect risk.
4. Archive cases, data, results, and automation artifacts.
5. Capture lessons learned and process improvements.
6. Hand over known issues and residual risk to support or product.
7. Update regression packs based on new learning.
8. Celebrate what reduced risk, not only what found bugs.

Entry Criteria

• Execution for the cycle is complete or stopped by management decision.
• Result data is available.

Exit Criteria

• Summary report accepted under process.
• Artifacts archived.
• Action items for improvement assigned.
• Residual risks communicated.

Deliverables

• Test closure or summary report.
• Lessons learned notes.
• Updated regression suite.
• Quality signoff or risk acceptance record.

Closure Report Skeleton

Release: 1.18
Scope tested:
Not tested / deferred:
Execution summary:
Defect summary by severity:
Escaped risk / known issues:
Environment limitations:
Automation status:
Exit criteria evaluation:
Residual risk statement:
Recommendations:
Signoff:

Closure is not bureaucracy when it is short and honest. It is how organizations stop repeating the same release pain.

STLC Phases with Entry and Exit Criteria (Summary Table)

Phase	Enter when	Exit when	Key output
Requirement analysis	Requirements available	Ambiguities logged, scope understood	Query log, RTM draft
Test planning	Enough scope clarity	Plan accepted, resources set	Test plan
Test case development	Plan and requirements ready	Cases reviewed, data designed	Suites, scripts
Environment setup	Access and architecture known	Env smoke passes	Ready environment
Test execution	Build + cases + env ready	Mandatory tests done, risks clear	Results, defects
Test closure	Execution finished or stopped	Report archived, learning captured	Closure report

STLC in Agile vs Waterfall

Topic	Waterfall flavored STLC	Agile flavored STLC
Phase timing	Mostly sequential	Overlapping and continuous
Documentation	Heavier formal docs	Lighter living docs
Planning	Project level plan	Release + sprint planning
Case design	Large upfront suites	Just in time plus durable regression
Execution	Late big test window	Every sprint
Closure	End of project stage gate	End of sprint/release plus retros
Automation	Often later	Continuous investment

Important: Agile does not delete STLC phases. It compresses and repeats them.

To connect sprint-level quality conversations back to risk types, use agile testing quadrants alongside this STLC view.

Sprint Mapping Example

• Backlog refinement: requirement analysis.
• Sprint planning: test planning slice.
• Early sprint: case design, data, env checks, automation updates.
• Throughout sprint: execution, defects, retests.
• Sprint review/retro: mini closure and learning.

Exploratory work thrives in Agile loops. Keep charters linked to risk, as covered in the exploratory testing guide.

Roles Across STLC

Role	Common contribution
QA engineer	Analysis questions, cases, execution, defects, automation
QA lead	Plan, risk calls, reporting, closure quality
Developer	Unit tests, fix quality, env support, testability
Product manager	Priority, acceptance clarity, risk acceptance
Designer	Expected UX behavior, edge state designs
DevOps	Pipelines, environments, observability
Support	Production patterns that should become tests

STLC fails when QA is isolated as the only quality owner. It works when quality is shared and testing craft is explicit.

Metrics That Support STLC Decisions

Useful metrics:

• Requirement coverage for critical scope.
• Planned versus executed cases.
• Defect detection by phase or severity.
• Blocked time due to environment.
• Automation pass trends for smoke and core regression.
• Escaped defects after release.
• Mean time from defect report to fix verification.

Dangerous vanity metrics:

• Raw case count as a success score.
• Pass percentage without risk context.
• Number of documents created.

Always pair numbers with a risk narrative.

Worked Example: Full STLC for a Feature

Feature: team workspace invites.

Requirement analysis

• Roles: owner, admin, member.
• Invite by email.
• Expiry in 7 days.
• Existing user vs new user paths.
• Permission to invite only owner/admin.
• Open question: can invites be revoked after acceptance starts?

Test planning

• Scope in web app only.
• API tests for invite states.
• UI journeys for send, accept, expire.
• Security focus on privilege escalation.
• Exit: no open high severity invite defects.

Test case development

• Positive invite and accept.
• Expired invite.
• Revoke invite.
• Member cannot invite.
• Duplicate invite behavior.
• Wrong workspace token handling.

Environment setup

• Mail sandbox.
• Two tenants.
• Role based users.
• Clock control or time travel strategy for expiry.

Test execution

• Smoke green.
• 32 cases run, 2 fails, 1 blocked on email delay.
• Defects filed with evidence.
• Fixes retested.

Closure

• Summary shows invite expiry fixed on second build.
• Residual risk: mobile clients not in scope.
• Added two automated API regression checks.
• Lesson: need deterministic time control for expiry tests.

That is STLC as lived practice, not a poster on a wall.

Common Mistakes in STLC Adoption

Mistake 1: Treating STLC as Paperwork Only

If artifacts exist but nobody uses them for decisions, STLC is theater.

Mistake 2: Starting Execution with No Entry Discipline

Testing unstable builds without smoke gates burns time. Pair STLC execution entry with smoke versus regression thinking.

Mistake 3: No Closure, No Learning

Teams jump to the next sprint and forget residual risk communication. Escaped defects then surprise support.

Mistake 4: Copying Waterfall STLC into Agile Unchanged

Giant upfront case repositories with no living maintenance collapse under change. Keep durable regression, design the rest just in time.

Mistake 5: Ignoring Non Functional Requirements

STLC that only lists functional clicks misses security, performance, reliability, and accessibility risks.

Mistake 6: Weak Traceability

If nobody knows which critical requirement lacks a test, exit criteria become opinions.

Mistake 7: Environment as an Afterthought

Late environment setup is a classic schedule killer. Start it early and parallelize.

Mistake 8: Measuring Only Defect Counts

More bugs found can mean better testing or worse quality. Interpret metrics in context.

Interview Answer Pattern for STLC

When asked to explain the software testing life cycle:

1. Define STLC in one sentence.
2. List the six phases.
3. Give one activity and one deliverable per phase.
4. Mention entry and exit criteria.
5. Explain STLC vs SDLC briefly.
6. Add how Agile overlaps phases.

That structure sounds experienced and complete without reciting a textbook page.

Deliverables Map Across STLC

Teams often ask what they must produce. Right-size this list to product risk.

Phase	Minimum viable deliverable	Stronger delivery
Requirement analysis	Query list + in/out scope	RTM draft + risk notes
Test planning	One page plan	Full plan with estimates and criteria
Case development	Prioritized cases for critical scope	Reviewed suite + automation candidates
Environment setup	Ready checklist with smoke result	Data refresh runbook + access matrix
Execution	Results + defects	Daily risk dashboard + retest log
Closure	Summary with residual risk	Lessons, suite updates, signoff record

If a startup skips heavy documents but keeps the thinking behind each cell, STLC still works. If an enterprise produces documents nobody reads, STLC does not.

Handling Change Mid Cycle

Requirements change. STLC must absorb change without denial.

Practical rules:

1. Version the requirement snapshot used for design.
2. Re-run analysis questions for the changed slice only.
3. Update plan scope and exit criteria if risk shifted.
4. Mark obsolete cases clearly; do not leave contradictory expected results.
5. Communicate residual risk when time is cut but scope is not.

Example: product removes coupon stacking two days before release. Update cases, remove automation that asserts stacking, and note in closure that historical stacking bugs are no longer applicable.

Non Functional Work Inside STLC

STLC is not only functional clicks.

Quality attribute	Where it enters STLC
Performance	Analysis of SLOs, plan for load windows, env capacity, execution of scenarios, closure of results
Security	Threat notes in analysis, permission cases, targeted tools, residual risk statement
Accessibility	Criteria in stories, cases for keyboard and labels, sample assistive checks
Reliability	Failover and retry scenarios, chaos-lite tests in safe envs
Operability	Logging and alert checks during execution when relevant

If non functional needs are always "later," they become production incidents. Put them in planning explicitly even when depth is small.

Tooling Across Phases

Tools should support the phase, not define it.

• Analysis: issue tracker, Confluence/Notion, design tools
• Planning: same docs plus estimation boards
• Design: TestRail/Xray/Zephyr, or markdown + Git, plus IDE for automation
• Environment: CI, Docker, infrastructure as code, secret managers
• Execution: runners, reports, defect trackers, observability
• Closure: dashboards, retro templates, repository PRs for suite updates

Changing tools mid release is usually more expensive than imperfect tools used consistently.

Practice: Apply STLC to a Small App

Pick a simple product idea, such as a notes app.

Write one page with:

• Three requirements.
• A mini plan.
• Ten test cases.
• Environment needs.
• A fake execution table.
• A five line closure summary.

Then compare your artifacts with a teammate. Gaps in questions, data, or exit criteria will appear quickly.

Second drill: take a real sprint and label each day with the STLC phase you spent the most time in. If execution always crowds out analysis and closure, your process is reactive.

For competitive practice, open QABattle tracks and treat one battle as a micro STLC: analyze the challenge, plan your approach, design checks, execute, then write a short closure note about what risk remains.

Final Practical Workflow

Use this checklist for every release cycle:

1. Analyze requirements and log ambiguities early.
2. Plan scope, risk, approach, and criteria.
3. Develop prioritized cases and data.
4. Prepare and smoke the environment in parallel.
5. Execute with daily visibility and strong defect reports.
6. Retest fixes and run agreed regression.
7. Evaluate exit criteria with evidence.
8. Publish closure notes and residual risk.
9. Update automation and regression packs.
10. Carry lessons into the next cycle's analysis and plan.

STLC is valuable when it makes quality work visible, repeatable, and improvable. The six phases of the software testing life cycle give teams a shared map. Your job is to right-size that map for your product, run it with discipline, and never confuse documents with actual confidence.