Software Testing Life Cycle (STLC)

What is STLC?

The Software Testing Life Cycle (STLC) is a structured sequence of activities carried out during the testing of a software product. It defines specific steps that a QA team follows to ensure the application meets quality standards and behaves as expected.

STLC is not just about executing tests — it starts from the moment requirements are available and ends only after all test activities are formally closed. Each phase has clear goals, deliverables, and criteria that must be met before moving forward.

The 6 Phases of STLC

STLC consists of six well-defined phases. Each phase builds on the previous one and produces specific outputs that feed into the next stage.

Phase 1: Requirement Analysis

This is the first and arguably most important phase. QA team members study the requirements — both functional and non-functional — to understand what needs to be tested.

Activities

• Review Business Requirements Documents (BRD) and Functional Requirement Specifications (FRS)
• Identify testable and non-testable requirements
• Raise requirement clarification questions (RTM — Requirement Traceability Matrix)
• Identify automation feasibility

Deliverables

• RTM (Requirement Traceability Matrix)
• Automation Feasibility Report

Phase 2: Test Planning

In this phase, the QA lead or test manager defines the overall test strategy, estimates effort, assigns resources, and sets the testing scope.

Activities

• Identify testing scope and objectives
• Define test strategy and approach
• Estimate testing effort and timelines
• Select testing tools and environments
• Identify risks and mitigation plans

Deliverables

• Test Plan document
• Effort estimation sheet

Phase 3: Test Case Development

This phase involves creating detailed test cases and test scripts based on the requirements analysed in Phase 1.

Activities

• Create test cases and test scripts
• Review test cases with peers and business analysts
• Prepare test data
• Update the RTM with test case coverage

Deliverables

• Test cases / test scripts
• Test data
• Updated RTM

Phase 4: Test Environment Setup

Before tests can be executed, the right environment must be ready — hardware, software, network configuration, and test data must all be in place.

Activities

• Set up hardware and software environments
• Configure test tools (Selenium, Appium, JIRA, etc.)
• Perform a Smoke Test to validate the environment is stable
• Prepare test data in the environment

Deliverables

• Test environment ready
• Smoke test results

Phase 5: Test Execution

This is the phase where actual testing happens. Testers execute test cases, log defects for failures, and retest fixes until all tests pass within the agreed scope.

Activities

• Execute test cases manually or via automation
• Log defects in a bug tracker (e.g. JIRA)
• Retest fixed defects
• Perform regression testing after each fix cycle
• Track test execution progress

Deliverables

• Test execution report
• Defect report
• Updated RTM

Phase 6: Test Closure

Once all agreed exit criteria are met (or a release decision is made), the test cycle is formally closed. This phase focuses on learning and documentation.

Activities

• Verify all tests have been executed and all critical defects resolved
• Prepare test summary report
• Conduct lessons-learned meeting
• Archive test artefacts for future reference

Deliverables

• Test Closure Report
• Test Summary Report

Entry & Exit Criteria

Every phase has entry criteria (what must be true before the phase starts) and exit criteria (what must be true before the phase ends). This keeps the process disciplined and prevents work starting on incomplete foundations.

STLC vs SDLC

A common source of confusion for new testers is the difference between STLC and SDLC. Here's a clear comparison:

STLC in Agile vs Waterfall

The six STLC phases exist in both Agile and Waterfall — but how they are executed looks very different in practice.

Key Test Metrics in STLC

Metrics give visibility into testing progress and quality. Here are the most important ones tracked across STLC phases:

• Test Case Pass Rate — (Passed Tests / Total Tests Executed) × 100. A healthy pass rate late in the cycle is typically 90–95%+.
• Defect Density — Number of defects per module or feature area. High defect density in a module signals unstable code needing closer scrutiny.
• Defect Removal Efficiency (DRE) — Percentage of defects found before production vs total defects (including post-release). A DRE above 90% is considered excellent.
• Test Coverage — Percentage of requirements covered by at least one test case. Tracked in the RTM.
• Mean Time to Detect (MTTD) — Average time between a defect being introduced and it being found. Lower is better.
• Blocked Test Cases — Test cases that cannot be executed due to environment issues or blocker defects. High numbers indicate process bottlenecks.

Common STLC Pitfalls

Even experienced QA teams fall into these traps. Recognising them early saves significant rework:

• Skipping requirement analysis. Jumping straight to test case writing without analysing requirements leads to incomplete coverage. Ambiguous requirements caught late are 10x more expensive to address.
• Test environment not production-equivalent. If the test environment has different OS versions, database sizes, or network configurations from production, defects slip through. At Viasat, we used Ansible to guarantee environment parity.
• No exit criteria defined. Without clear exit criteria, test closure becomes arbitrary — you stop testing when time runs out, not when quality is confirmed. Always define exit criteria in the test plan.
• RTM not maintained. A Requirement Traceability Matrix that isn't updated as requirements change gives false confidence about coverage. It becomes a liability instead of an asset.
• Treating regression as optional. After a bug fix, it's tempting to close the ticket and move on. Skipping regression is how fixes in one module break three others — and how those breaks reach production.
• No test data strategy. Running tests against production data (a security risk) or empty databases (unrealistic) instead of representative synthetic data skews results and misses data-dependent bugs.

STLC in Agile Sprints

The traditional STLC model presents six phases as a linear sequence — each phase completing before the next begins. In Agile, this model does not disappear; it compresses. All six STLC phases still happen, but they overlap, run in parallel, and repeat every two weeks inside a sprint. Understanding how to operate STLC at sprint speed is one of the most practical skills an Agile QA engineer can develop.

Requirement Analysis: Sprint Planning and Three Amigos

In a traditional project, requirement analysis happens once, upfront, from a complete BRD. In Agile, it happens at the start of every sprint — and it happens fast. QA joins sprint planning and backlog refinement, reviewing user stories for testability and raising questions before the sprint begins. The most effective technique here is the Three Amigos meeting: the product owner, a developer, and a QA engineer sit together and walk through each story. The developer asks how it should be built; the QA engineer asks how it can break. This 30-minute conversation consistently catches ambiguities that would otherwise surface as defects in sprint review.

Test Planning: Lightweight, Per-Sprint

A traditional test plan can run to 30 pages. In Agile, test planning is a one-page document — or sometimes just a section of the sprint planning notes — that covers what will be tested, what automation will be run, what environments are available, and what the exit criteria are for this sprint's stories. It is not a bureaucratic artifact; it is a communication tool. If it takes more than an hour to write, it is too heavy.

Test Case Development: First Half of the Sprint

Test cases in Agile are written during the first half of the sprint, in parallel with development. QA does not wait for a feature to be complete before writing tests for it. User stories with clear acceptance criteria become test cases directly — each acceptance criterion maps to at least one test case. BDD (Behaviour-Driven Development) teams write these in Gherkin, giving developers, QA, and the product owner a shared language for what "done" means. By the time the first feature is ready to test, QA already has the test cases prepared.

Test Execution: Second Half of the Sprint

As features become testable — usually from day 5 or 6 of a 10-day sprint — QA begins executing tests. Manual testing covers the exploratory and complex scenarios; automation runs regression. The critical discipline here is to test features as they complete rather than waiting for all features to be done before testing any of them. Waiting until day 9 to start testing is a Waterfall pattern hiding inside an Agile ceremony structure.

Test Closure: Sprint Review and Retrospective

Sprint-level test closure is a brief review — typically 15 to 20 minutes — at the end of the sprint. It covers: what was the pass rate, how many bugs were found and resolved, what is the current automation coverage delta (did the suite grow this sprint?), and are there any carry-over test cases that need to be accounted for in the next sprint? This is not a formal sign-off document; it is a quick health check that feeds directly into the sprint retrospective.

Managing Constant Context Switching

The hardest part of STLC in Agile is not the technical work — it is the context switching. In a single day, a QA engineer might review new stories in the morning, execute tests against yesterday's feature in the afternoon, and triage a bug that just came in from the previous sprint's production deployment between those two activities. Strategies that help: time-box testing sessions rather than testing until interrupted, use a shared Kanban board to make testing state visible to the whole team, and negotiate a "QA ready" column in the sprint board so developers know when a story is ready for testing without needing a conversation.