Most diagrams of the software testing life cycle show six boxes in a row: requirement analysis, planning, test design, environment setup, execution and closure. It's a useful vocabulary. It's also a misleading picture. Teams that run testing as a straight line learn about their biggest risks at the end, when changing course costs the most.
I think of the STLC as a loop. Every activity produces information that should reshape the others. The diagram matters less than whether that information gets back to the people making decisions.
STLC stands for software testing life cycle.
“STLC” is industry shorthand, not a standard. No standards body defines a six-phase software testing life cycle. That doesn't make the term wrong, but it helps to anchor it to vocabulary that is defined, so teams and vendors mean the same thing.
Two references do that well. The ISTQB Foundation Level syllabus (v4.0.1) names seven test activities: test planning, test monitoring and control, test analysis, test design, test implementation, test execution and test completion. ISO/IEC/IEEE 29119-2 defines test processes at the organizational, management and dynamic levels, and states that they apply to any development lifecycle model. I treat both as a shared language, not a rulebook. They let a tester in Atlanta and a tester in Ho Chi Minh City describe the same work in the same words.
Here's how the familiar STLC labels map to that vocabulary, and the question each activity should answer:
| Common STLC label | ISTQB activity | Question it answers | Typical output |
|---|---|---|---|
| Requirement analysis | Test analysis | What could go wrong, and how much would it matter? | Risk list, open questions, test conditions, and traceability to requirements |
| Test planning | Test planning | How much testing is enough, given our risks and constraints? | Test plan with scope, approach and entry and exit criteria |
| Test case development | Test design and implementation | What evidence will tell us whether a risk is real? | Test cases, test data and exploratory charters |
| Environment setup | Test implementation | Can we observe the product in conditions close to real use? | A ready environment and a build that passes smoke checks |
| Test execution | Test execution | What did we learn, and what surprised us? | Results, defect reports and new questions |
| Test cycle closure | Test completion | What do we know, what don't we know, and what should we keep? | Test summary report, lessons learned, and a decision on which tests to keep, retire or automate |
| (Usually missing) | Test monitoring and control | Is our plan still right, given what we're learning? | Updated risk list and plan adjustments |
The last row is the one most STLC guides leave out. Monitoring and control is what turns a line into a loop.
A test plan is a hypothesis about where the risk is. Execution tests that hypothesis. When an exploratory session uncovers a data-handling problem nobody anticipated, the right move is to update the risk list, re-plan and design new tests. Finishing the scripted ones first and filing the surprise for next release is the wrong move.
This is where the difference between testing and checking earns its place. James Bach and Michael Bolton define checking as “the mechanistic process of verifying propositions about the product.” Testing is broader: evaluating a product by learning about it through exploring and experimenting. Scripted test cases are checks. They confirm what you already expected. Testing is how you find what you didn't expect, and that discovery is what feeds the loop.
A healthy STLC has both. Checks protect known behavior cheaply and repeatably. Testing finds new risk. Each cycle should move some of what testing discovered into checks, so people stay free to keep exploring.
Risk should decide how much effort each activity gets. ISTQB states plainly that exhaustive testing is impossible, so every team is already choosing what not to test. The only question is whether they choose on purpose.
During analysis, I use a coverage heuristic to make sure the risk list isn't just a restatement of the requirements. The SFDIPOT mnemonic from James Bach's Heuristic Test Strategy Model, explained well by Michael Bolton, asks about a product's Structure, Function, Data, Interfaces, Platform, Operations and Time. It's a prompt for questions. A login story looks simple until you ask about Time (session expiry, clock skew) and Operations (what users actually do when they forget a password).
Entry and exit criteria are often written as paperwork: “test plan approved,” “all test cases executed.” Criteria like these describe activity, not knowledge. Better criteria name the information a decision needs.
| Activity | Weak criterion | Stronger criterion |
|---|---|---|
| Test analysis (entry) | Requirements document signed off | Acceptance criteria exist for the risky behaviors, and open questions are logged |
| Test execution (entry) | Environment available | Build is deployed, smoke checks pass, and test data reflects realistic volume |
| Test execution (exit) | 100% of test cases executed | Every high-risk area has evidence; open defects are triaged with a ship/no-ship view |
| Test completion (exit) | Test summary report issued | Stakeholders know what was tested, what wasn't, and the residual risk they're accepting |
Testing rarely finishes. It stops, when the people who own the release judge they know enough to decide. Good exit criteria make that judgment explicit instead of hiding it behind a pass rate.
In a Waterfall project the activities run closest to the diagram: analysis and planning early, execution after the build is complete. That is where the loop is hardest to see, because feedback from execution arrives late and re-planning is expensive. Teams in this setting get the most from reviewing requirements early and from explicit monitoring and control checkpoints during execution.
In a two-week sprint, or a pipeline that deploys daily, the same seven activities still happen. They're just compressed and repeated per story, per change, sometimes per commit. Analysis happens in refinement, when testers ask “how would we know this works?” before code exists. Monitoring and control happens at standup and in the pipeline dashboard. Completion happens at the sprint review, when the team decides which new checks to keep.
The risk in fast delivery isn't skipping phases. It's letting the automated, repeatable parts of testing crowd out analysis and exploration, because those don't show up on a burndown chart.
The software development life cycle (SDLC) covers everything from idea to retirement: designing, building, deploying and maintaining a product. The STLC is the testing slice of that work. It overlaps the SDLC rather than following it, because testing can start as soon as requirements exist, often before any code does.
| Dimension | STLC | SDLC |
|---|---|---|
| Scope | Testing activities that tell the team whether the product is ready | Designing, building, deploying and maintaining the product |
| Starts | When requirements exist, often before any code | With a business need or idea |
| Ends | When the people who own the release judge they know enough to decide | When the product is retired or replaced |
| Who is involved | Testers, QA leads and automation engineers | Developers, designers, product owners, QA and DevOps |
| Typical outputs | Test plan, test cases, results, defect reports and a test summary | Requirements, designs, code, deployment plans and user documentation |
| Role in quality | Produces the evidence about quality | Builds the product, with testing as one of its activities |
Katalon True Platform can hold the evidence that keeps the loop connected. It keeps plans, manual and automated test results, and reporting in one place, so monitoring and control works from current data rather than status meetings. Its Requirement Analyzer agent can help draft test ideas from requirements. A tool can't decide which risks your business cares about or when you know enough to ship. That judgment belongs to your team, and the STLC exists to inform it.