The Software Testing Life Cycle (STLC): all six phases explained

So far in this series we have covered what testing is, the four levels of testing and manual vs automated testing. Now we put it in order: what does a tester actually do, step by step, from the first requirement to the release?

The answer is the Software Testing Life Cycle, or STLC: six phases that take testing from "what should we test?" to "we're done, here's what we found". It is also one of the most common topics in QA job interviews.

What is the STLC?

The STLC is the sequence of activities a team follows to plan, design, run and finish testing. Each phase has:

• Entry criteria: what must be true before the phase can start.
• Activities: the work done in the phase.
• Deliverables: what the phase produces.
• Exit criteria: what must be true before you move on.

Here are the six phases at a glance:

We will use the same food delivery app from Part 2, and follow one new feature through all six phases: discount codes at checkout.

Phase 1: Requirement analysis

Goal: understand exactly what needs to be tested.

The testers read the requirements and ask questions before any code is written. For discount codes:

• Can a customer use two codes on one order?
• Does the code apply before or after the delivery fee?
• What message appears for an expired code?

Every unanswered question here is a bug avoided later. Testers also decide which requirements can be tested and how (manual, automated, or both).

Deliverables: a list of testable requirements, open questions, and often a Requirements Traceability Matrix (RTM): a table that links every requirement to the tests that cover it, so nothing is forgotten.

Phase 2: Test planning

Goal: decide how the testing will be done.

A test lead writes the test plan, which answers:

• Scope: what will be tested, and what won't. ("Discount codes on web and Android. iPhone next release.")
• Approach: which test levels and types, and what to automate.
• Resources: who tests what, and with which tools.
• Schedule and effort: how long it will take.
• Risks: what could go wrong, and the backup plan.
• Entry and exit criteria for the whole cycle.

Deliverables: the test plan and effort estimate.

Phase 3: Test case design

Goal: write the actual tests.

Testers turn the requirements into test cases, each with steps and an expected result, plus the test data they need:

ID	Test case	Expected result
TC-01	Apply a valid 10% code to a 500 order	Total becomes 450
TC-02	Apply an expired code	"This code has expired" message, total unchanged
TC-03	Apply two codes	Second code is refused with a clear message
TC-04	Apply a code, then empty the cart	Discount is removed

Test cases are reviewed by another tester or a developer. Automation engineers start writing automated scripts for the cases chosen in planning.

Deliverables: reviewed test cases, test data and automation scripts. The RTM is updated so every requirement maps to its test cases.

Phase 4: Test environment setup

Goal: get a place ready to run the tests.

Tests need somewhere to run that behaves like production: servers, a database with test data, browsers, phones and the right app version. Often a separate team prepares it, and testers do a quick smoke test to check it actually works before starting.

This phase often runs at the same time as Phase 3.

Deliverables: a working test environment and smoke test results.

Phase 5: Test execution

Goal: run the tests and record what happens.

Testers run the test cases, manual and automated, and mark each one passed, failed, blocked (can't run, because something else is broken) or not run.

When a test fails, they log a defect (bug report) with the steps to reproduce it, what was expected, what actually happened, and screenshots or a video. When developers fix it, testers re-test that fix, then run regression tests to make sure the fix didn't break anything else.

Deliverables: test results, defect reports and an updated RTM showing which requirements passed.

Phase 6: Test closure

Goal: finish properly and learn for next time.

The team checks the exit criteria. For example: "all critical tests passed, no open critical bugs, at least 95% of planned tests run". Then they write a test summary report:

• What was tested, and what wasn't.
• How many tests passed, failed and were blocked.
• Bugs found, fixed and still open, by severity.
• Risks the release still carries.
• Lessons learned for the next cycle.

Deliverables: the test summary report, and the test cases and scripts saved for reuse.

Entry and exit criteria

Entry and exit criteria stop two classic problems: starting too early (testing a build that doesn't even start) and never finishing (testing forever, or stopping on a deadline without knowing the risk).

Phase	Example entry criteria	Example exit criteria
Test case design	Requirements reviewed and signed off	All test cases written and reviewed
Test execution	Environment ready, smoke test passed	All planned tests run; critical bugs fixed
Test closure	Execution finished	Summary report shared and signed off

How the STLC fits the SDLC

The SDLC (Software Development Life Cycle) covers building the whole product. The STLC is the testing part of it, and it runs alongside development, not after it:

This is the "test early" idea from Part 1. When testers start on day one, the test cases are ready the moment the build is.

STLC in agile teams

In agile teams, the STLC doesn't disappear. It gets smaller and faster, and repeats every sprint:

• Requirement analysis happens during backlog refinement, when testers ask questions about each user story.
• Planning is part of sprint planning, often with an overall test strategy instead of a long plan per sprint.
• Design, execution and closure happen inside the sprint, story by story.
• Automation carries the regression checks from sprint to sprint.

Same six steps, just in days instead of months.

Quick interview recap

1. STLC = the six phases of testing: requirement analysis, test planning, test case design, environment setup, test execution, test closure.
2. Each phase has entry criteria, activities, deliverables and exit criteria.
3. The RTM links requirements to test cases, to prove everything is covered.
4. The STLC runs in parallel with the SDLC, and repeats every sprint in agile.

What's next

In Part 5 we get hands-on: your first automated test in 15 minutes, with Python and pytest.

ProvaLab's Test Management follows the same life cycle: requirements linked to test cases, test plans, test runs with every result recorded, and defects linked back to the failing test. See it in the two-minute product tour.