STLC: The Software Testing Life Cycle

The SDLC describes how a product gets built. The software testing life cycle (STLC) zooms in on testing itself: the ordered set of activities that takes you from “here are the requirements” to “here is the evidence, and here is what we learned”. Knowing the STLC lets you plan your work, explain your status to managers, and answer one of the most common QA interview questions with structure instead of vague recollection.

The STLC is a widely used industry model rather than a single formal standard. The ISTQB Foundation syllabus describes a closely matching test process (test planning, monitoring and control, analysis, design, implementation, execution and completion). The names below are the ones you will hear most often in job interviews; the table at the end maps them to ISTQB terms.

The six phases at a glance

#	Phase	Key question	Main deliverables
1	Requirement analysis	What needs testing?	Testable requirements list, questions log, RTM draft
2	Test planning	How will we test it, with what, by when?	Test plan, effort estimate, risk list
3	Test case development	What exactly will we check?	Test cases, test data, automation scripts
4	Test environment setup	Where will we run it?	Ready environment, smoke test result
5	Test execution	What actually happens?	Test results, defect reports, updated RTM
6	Test cycle closure	What did we learn?	Test summary report, metrics, lessons learned

Each phase has entry criteria (what must be true to start) and exit criteria (what must be true to finish). These are what make the cycle controllable rather than a list of good intentions.

Phase 1: Requirement analysis

The test team studies the requirements, user stories, designs and any other test basis to understand what needs to be tested.

Activities:

• Identify testable requirements and flag those that are not.
• Raise questions with the product owner, business analyst or developers.
• Identify the types of testing needed: functional, performance, security, accessibility, compatibility.
• Decide what is a candidate for automation.
• Start the requirements traceability matrix (RTM).

Entry criteria: requirements or user stories are available; stakeholders are reachable for questions. Exit criteria: questions are answered or logged as risks; the RTM lists every requirement in scope.

The requirements traceability matrix

An RTM links requirements to the tests that cover them, and later to results and defects. It answers “is every requirement tested?” and “if this requirement changes, which tests do I update?”.

Requirement	Description	Test cases	Status	Defects
REQ-101	User can log in with valid email and password	TC-001, TC-002	Passed	None
REQ-102	Account locks after 5 failed attempts	TC-003, TC-004, TC-005	Failed	BUG-231
REQ-103	User can reset password by email	TC-006	Not run	None

You can generate a starter matrix with the RTM Generator.

Phase 2: Test planning

Usually led by a test lead or senior QA, planning turns analysis into a strategy with resources and a schedule. A test plan typically covers:

• Scope: what is in and, just as important, what is explicitly out.
• Approach: test levels and types, manual vs automated, techniques.
• Entry and exit criteria for execution.
• Environments, tools and test data needed.
• Roles and responsibilities.
• Schedule and effort estimate.
• Risks and mitigations, for example “payment sandbox may be unstable; mitigation: mock the provider for functional tests”.
• Deliverables the team will produce.

Entry criteria: requirement analysis is complete. Exit criteria: the plan is reviewed and approved by stakeholders.

Phase 3: Test case development

Testers design and write the test cases, prepare test data, and write or update automation scripts. This is where test design techniques such as equivalence partitioning and boundary value analysis are applied, covered in Test Case Design Techniques.

A test case usually contains:

Field	Example
ID	TC-003
Title	Account locks after the fifth consecutive failed login
Preconditions	Active account qa.user@example.com with 0 failed attempts
Steps	1. Enter the valid email. 2. Enter a wrong password. 3. Click “Sign in”. 4. Repeat steps 2–3 four more times.
Test data	Wrong password: NotMyPassword1
Expected result	After the 5th attempt the message “Your account is locked” appears and a correct password is rejected
Requirement	REQ-102

Entry criteria: approved test plan; requirements stable enough to design against. Exit criteria: test cases and data reviewed; RTM shows coverage for every in-scope requirement.

Phase 4: Test environment setup

The environment is the hardware, software, network configuration, test data and access needed to run the tests. It is often prepared by DevOps or developers, with testers verifying it. This phase can run in parallel with test case development.

Before trusting an environment, run a smoke test: a small set of checks that the build is deployed, key services are up, and the main journeys work at a basic level. If the smoke test fails, there is no point starting detailed execution.

Entry criteria: environment requirements from the test plan; build available. Exit criteria: environment is ready, test data is loaded, smoke test has passed.

Phase 5: Test execution

Testers run the tests, compare actual results with expected results, and log defects for any mismatch.

• Mark each test Passed, Failed, Blocked (cannot run because of another issue) or Not run.
• Log defects with clear steps, expected vs actual results, environment details and evidence. The Bug Report Generator gives you a solid template.
• Retest (confirmation testing) each fixed defect, then run regression tests around the fix to check nothing else broke.
• Update the RTM and report progress daily or per agreed cadence.

Entry criteria: all previous exit criteria met; test cases ready; environment smoke-tested. Exit criteria (examples, agreed in the plan):

• All planned tests executed, or skipped with a recorded reason.
• No open critical or high-severity defects, or each one has an accepted, documented decision.
• Agreed requirement coverage reached, for example every in-scope requirement has at least one executed test.

Phase 6: Test cycle closure

The team evaluates the cycle and captures what was learned.

• Produce a test summary report: what was tested, results, open defects, residual risks, and a recommendation.
• Collect metrics such as tests executed, pass/fail counts, defects by severity and module, and defects found after release.
• Hold a retrospective: what slowed us down, which defects escaped and why, what to automate next.
• Archive test artefacts (cases, data, scripts, environment notes) so they can be reused.

Entry criteria: execution complete or formally stopped. Exit criteria: summary report delivered; lessons learned recorded.

The STLC in an Agile team

In a two-week sprint you will not produce a 40-page test plan, but every phase still happens, compressed and repeated per story:

STLC phase	Where it happens in Scrum
Requirement analysis	Backlog refinement: questioning stories, writing acceptance criteria
Test planning	Sprint planning, plus a lightweight test strategy that lives across sprints
Test case development	Early in the sprint, alongside development; automation written in parallel
Environment setup	Mostly automated: ephemeral or shared environments created by the pipeline
Test execution	Continuously as stories become ready; automated suites run on every commit
Test closure	Sprint review and retrospective; release-level summary before major releases

STLC terms vs ISTQB test process

Common STLC name	ISTQB test process activity
Requirement analysis	Test analysis
Test planning	Test planning (plus monitoring and control throughout)
Test case development	Test design and test implementation
Test environment setup	Part of test implementation
Test execution	Test execution
Test cycle closure	Test completion

Practice exercise

You are testing a “Forgot password” feature: a user enters their email, receives a reset link valid for 30 minutes, and sets a new password that must be at least 12 characters.

1. Write three entry criteria and three exit criteria for the test execution phase.
2. Draft an RTM with at least three requirements and the test case IDs that would cover them.
3. Write one complete test case in the format shown in Phase 3.

A good result has measurable criteria (not “testing is mostly done”), an RTM where every requirement maps to at least one test, and a test case with a precise expected result.

Show a model answer

Entry criteria for execution

• The build containing the feature is deployed to the QA environment and the smoke test passed.
• Test email inbox (for example a mail-catcher service) is configured and reachable.
• Test cases TC-010 to TC-018 are reviewed and approved.

Exit criteria for execution

• 100% of planned test cases executed, or skipped with a documented reason.
• Zero open critical or high-severity defects.
• Every requirement in the RTM has at least one passed test.

RTM

Requirement	Description	Test cases
REQ-201	Reset email is sent for a registered address	TC-010, TC-011
REQ-202	Reset link expires after 30 minutes	TC-012, TC-013, TC-014
REQ-203	New password must be at least 12 characters	TC-015, TC-016, TC-017
REQ-204	Response does not reveal whether an email is registered	TC-018

Test case TC-013

• Title: Reset link is rejected just after 30 minutes
• Preconditions: Registered user; reset requested; clock or token expiry controllable in QA
• Steps: 1. Request reset. 2. Advance time to 30 minutes 1 second after issue. 3. Open the link.
• Expected result: The page shows “This link has expired” and offers to send a new link; the password is unchanged.
• Requirement: REQ-202

Key takeaways

• The STLC phases are requirement analysis, test planning, test case development, environment setup, test execution and test cycle closure.
• Entry and exit criteria make each phase controllable and turn “are we done?” into a factual question.
• The RTM links requirements to tests, results and defects, exposing coverage gaps.
• In Agile, every phase still happens but is compressed and repeated per story and largely automated.
• The ISTQB test process uses different names for the same ideas; know both sets.