Software Testing Life Cycle (STLC): 6 Phases, Entry and Exit Criteria, Example

When a bug reaches production, the cause is often not that someone forgot to run a test. It is that a requirement was never questioned, the test data was wrong or nobody agreed what “done” meant. The software testing life cycle addresses those problems by giving testing a clear structure from the first requirement to the final report.

This guide explains each phase, then follows one illustrative feature through all of them: a login page that locks an account after five failed attempts. Sources do not fully agree on the number of phases. You will see models with seven or eight, but they mostly split the same work differently. We use the widely taught six-phase version.

What is the STLC?

The STLC is a defined series of testing activities carried out to confirm that software meets its requirements. Each phase has a goal, inputs and outputs, so that testing is planned and traceable rather than improvised at the end.

The benefits are practical. Testers get involved early, when defects are cheaper to fix. Effort goes to the highest risks. And when a manager asks “are we ready to release?”, the team can answer with evidence.

The six STLC phases at a glance

Entry criteria are the conditions that must be true before a phase starts. Exit criteria are the conditions that must be true before it ends. They stop a team from, for example, running tests on a broken build and wasting a day.

Phase 1: Requirement analysis

Testers study requirements to find out what can be tested and what is unclear. This is often the cheapest place to prevent a bug, since a question costs far less than a production fix.

• Entry: requirement documents or user stories are available.
• Activities: identify functional and non-functional needs, ask questions, assess risk and decide what could be automated.
• Exit: open questions are answered and the requirements traceability matrix (RTM) is started.
• Deliverables: a list of testable requirements, and the RTM.

Login example. The story says “lock the account after five failed attempts”. A good tester asks: five in what period? How is it unlocked? Does a successful login reset the count? What message is shown? Each answer becomes something testable.

Phase 2: Test planning

The team decides the scope, approach, people, tools, schedule and risks. The test lead usually owns this phase.

• Entry: analysed requirements and an initial risk assessment.
• Activities: define scope, estimate effort, select tools, assign roles and set exit criteria for later phases.
• Exit: the test plan is reviewed and approved.
• Deliverables: the test plan and effort estimates.

Login example. In scope: lockout rules, reset and error messages on web and mobile. Out of scope: single sign-on, handled by another team. The biggest risk is locking out genuine users, so that gets the most attention. If you are unsure how a plan differs from a strategy, read test plan vs test strategy.

Phase 3: Test case development

This is where testers write the detailed test cases, automation scripts and test data.

• Entry: an approved test plan and stable requirements.
• Activities: write and review test cases, prepare data, script automated checks and update the RTM.
• Exit: test cases and data are reviewed and ready.
• Deliverables: test cases, scripts and test data.

Notice that TC-01 and TC-02 test either side of the limit, which comes straight from boundary value analysis. For more on writing these well, see how to write test cases.

Phase 4: Test environment setup

Tests need somewhere realistic to run: the right servers, data, accounts, browsers and network access. This phase often runs in parallel with phase 3, and it may be handled by developers or a DevOps team.

• Entry: a test plan, an architecture overview and environment requirements.
• Activities: set up hardware or containers, load data, configure access and install the build.
• Exit: the environment is ready and a smoke test passes.
• Deliverables: a working environment and a smoke test result.

Login example. Staging gets test accounts in known states, along with a shortened lockout timer so testers do not have to wait. A quick smoke test confirms that login loads at all before the full run starts. Containers help keep environments consistent, as shown in our Docker Compose tutorial.

Phase 5: Test execution

Testers run the planned tests, compare actual and expected results and report defects. Fixed bugs are retested, and related areas receive regression testing.

• Entry: test cases are ready, the environment works and a build has been delivered.
• Activities: run tests, record results, log defects, retest fixes and update the RTM.
• Exit: planned tests are run, and defects are fixed or formally accepted.
• Deliverables: test results and defect reports.

Login example. TC-04 fails: with two browsers, the counter only reaches four. The tester logs the bug with clear steps and evidence, as described in how to write a bug report. Once it is fixed, TC-04 is rerun, and related login checks go through the regression checklist.

Phase 6: Test closure

This phase is commonly skipped, which is a shame, since it is how a team improves. The team evaluates the cycle, archives its work and records what it learned.

• Entry: execution is complete and the defect status is known.
• Activities: check exit criteria, analyse defect trends, archive test assets and hold a retrospective.
• Exit: the closure report is signed off.
• Deliverables: the closure report and lessons learned.

Login example. The report shows that all five cases passed after one fix. The lesson is that concurrency was only tested late, so future features with counters get that scenario added during design.

STLC vs SDLC

The SDLC, or software development life cycle, covers building the whole product. The STLC is the part focused on testing, and runs alongside it.

Requirement analysis in the SDLC feeds requirement analysis in the STLC, and development delivers builds into test execution. Testing does not have to wait until coding ends. Starting early is what people mean by “shift left”.

STLC in Agile and DevOps

The phases can sound like a long, one-way process, but they do not have to be. In Agile, the same activities shrink and repeat within each sprint, often in hours instead of weeks:

• Requirement analysis happens in backlog refinement, through questions on the user story.
• Planning happens in sprint planning, with lightweight notes in place of long documents.
• Test design happens alongside coding, often as acceptance criteria and automated tests.
• Environment setup is automated through containers and infrastructure as code.
• Execution runs continuously in a CI/CD pipeline.
• Closure becomes part of the sprint review and retrospective.

Keep what is useful and scale the paperwork to the risk. A small internal tool may need a short checklist, while a banking system may need formal sign-offs for regulatory reasons.

Common mistakes

• Bringing testers in late. Bugs found in requirements are far cheaper than those found after release.
• Vague exit criteria. Without them, deadlines make the decision for you.
• Testing in a poor environment. Failures caused by bad data or configuration waste time and erode trust.
• Skipping closure. The team then repeats the same mistakes in the next cycle.
• Following it too rigidly. The STLC is a guide. Heavy documents do not automatically mean better quality.

Final thoughts

The software testing life cycle is simply a disciplined answer to six questions: what do we test, how, with which cases, where, what happened and what did we learn? Look at your next feature and check which of those questions your team usually skips. Fixing that one gap will likely give you the biggest gain.

Frequently asked questions

Keep learning