Short answer: The software testing life cycle has six phases (requirements, planning, case design, environment, execution, closure), but most teams over-invest in the first three and under-invest in the fourth. The minimum useful version: write stories with acceptance criteria, automate the boring tests, run the manual ones once, and treat closure as a retro line item. If you're running iterations, STLC happens inside each iteration, not as a phase before the next release.
The software testing life cycle (STLC) is a standardized process that a piece of software goes through to get tested. The six phases of testing that are often adapted in accordance with needs are: Requirement analysis, Test planning, Test case design, Test environment setup, Test execution, and Test closure. It hangs on the wall in every QA team in every enterprise. Most teams that run iterations don’t know that they skip most of it. And the ones that don’t, usually wish they did.
This guide that gives an honest read We will explore what STLC truly means, the areas where teams tend to over-invest, the location of the hidden bottleneck, the difference it makes when STLC is run as part of the agile cadence versus as a release. The audience for this is engineers and anchors who’ve inherited a “QA process” without inheriting the training and who’d love to spend less time on the part that doesn’t catch bugs.
STLC, plainly explained
STLC is the step by step structural process of testing a software product by the team. The six common phases consist of.
- Requirements analysis — read the requirements, decide what needs testing.
- Test planning — decide who tests what, when, with which tools.
- Test case design — write down the actual tests.
- Test environment setup — get the hardware, software, and data in place.
- Test execution — run the tests.
- Test closure — write the report, file the bugs, move on.
All done. It is a sequence diagram for testing activities in the same way that the waterfall lifecycle is for building activities. Both can be useful as vocabulary. If your team releases software iterations rather than once a quarter, both are misleading as a literal sequence. The Atlassian guide to agile testing makes the same point: testing in agile is a continuous activity, not a phase you bolt on at the end.
Ad-hoc testing creates inconsistent coverage & unreliable reporting. Therefore, STLC exists to prevent this. One reason most teams don’t follow it to the letter is that the letter-version assumes a sequential waterfall context. In the iterative case, the stlc happens inside each iteration compressed and overlapping with development the phase-boundaries vanish.
The textbook version versus what real teams do
Each box starts where the previous box finished, whereas, in reality, things don’t work like that. All six phases run in parallel inside a two-week iteration, which gets the time it deserves, and no more.
Actual teams shorten STLC in this manner.
- Requirements and planning happen when the story is written. Acceptance criteria are the test plan. The PM writes them, the engineer reads them, the QA either pairs on them or reviews them before development starts.
- Test case design happens when the engineer is writing the feature. Automated tests are written alongside the code. Manual test scenarios get drafted in the story itself.
- Environment setup is whatever the CI pipeline already does, plus whatever ad-hoc staging the engineer spins up. It's done before the engineer Finishes the story.
- Execution runs continuously. Automated tests run on every push. Manual tests run when the story is Delivered to the PM.
- Closure is the PM clicking Accept or Reject. The "test summary report" is the iteration retro line about quality.
The compression is what makes iteration work. If you were to take the classic six-phase sequence literally, you would end up with a waterfall inside a waterfall, with the result that there is a “testing phase” added on at the end of every iteration to which nobody has time. When teams attempt to work like this, they end up delivering a delayed shipment that isn’t even tested thoroughly.
Phases 1 + 2: Requirements and planning, merged
In a healthy team, a single conversation about requirements analysis and test planning takes place in the first two phases of the Software testing Life Cycle (STLC). They are done when they write a story.
There are two parts of the conversation. A story's definition of what constitutes "accepted" (acceptance criteria) is defined by the PM. This means the criteria must be written as observable user behaviour. The engineer and the QA discuss and finalize the degree of coverage required, the work items that will be automated, those that will be manual, and if anything is so risky that it needs a separate test plan.
When teams skip this conversation, the stories that appear fine in the backlog explode in code review. The classic version states that when you code the story called “User can sign in”, and you have done the review, during PM acceptance, the PM says “wait what about password reset? What about expired sessions?” The narrative returns with a spring. Two days’ worth of work was wasted because the team didn’t have a five-minute conversation upfront.
Teams that hold effective conversations aren't writing more documentation. Their stories are smaller and clearer with acceptance criteria. In iterative format, acceptance criteria are the test plan. The principles of effective story writing cover what good criteria look like in practice.
Phase 3: Test case design, where teams over-invest
Among the six phases of STLC, this is the one teams invest a disproportionately high effort on. In case you take a moment to think about it, it’s also hard to justify.
The book version says: to every requirement, attach detailed test cases specifying steps, expected result, preconditions and test data. That would result in hundreds of test cases a typical iteration of 10 stories. The QA crew takes several days to write them. The engineers disregard the cases because there were written before the code exists and do not map to the code's behaviour. The cases will be archived. Three months later, they can no longer be found.
The condensed version says to write the automated tests in code, beside the code. In cases where automation is not cost-effective (one-off migrations, complex UI flows, anything that touches third-party services), draft three or four manual test scenarios directly in the story and execute once before acceptance. Avoid drafting a 60-step test case for a 5-step feature. Approaches like generative testing push more coverage into code rather than into hand-written cases.
The most important metric is the bugs caught not cases written. More often than not, test suites which have excessive documentation catch fewer bugs than well-worded acceptance criteria and an honest automated test layer. Documentation isn't something the majority of teams would spend their time on.
Phase 4: Test environment, the hidden bottleneck
No one ever warns you about this phase. The configuration of the test environment is where teams lose more iteration time than any other phase of STLC. And the textbook has a small box for it.
The process: After completing a feature, the engineer goes to the PM to deliver. The staging environment is not functioning. A configuration was altered last week. The migration of the database failed to occur. The key to API expired. Sandbox is down for Third Party The environment isn’t ready, that’s why the PM can’t check the work for another day.
Resources that nobody owns might be shared, leading to the phenomenon described. Environment is not an engineering investment that is incremented. The documentation and the STLC hasn’t helped either because it considers it a precondition. When a team has reliable staging and production environments they pay less Of course, a failure in a staging or production environment is not irrelevant; it’s not like no one cares, and in fact, they do care. But it’s less.
The diagnostic: How often does your team's iteration slip because the environment is broken when the PM tried to accept work? If the answer is “more than once a month”, environment is a structural problem, not setup for each iteration. The solution involves utilizing engineering hours on the platform, rather than improving test cases. Wiring deploys into your CI/CD integrations so a green build provisions a usable staging environment removes most of the wait.
Phase 5: Execution, automation, and the manual minimum
Test execution within an iterative team may consist of two layers run in parallel.
Any push triggers the automation layer to run. The main user flows have unit tests, integration tests, contract tests, and a smoke suite. Martin Fowler's practical test pyramid is still the cleanest mental model for which test runs at which layer. The test execution lies within the pipeline. It's the job of the team to keep it fast enough that engineers don’t avoid running it (roughly, under five minutes locally is the threshold) and reliable enough that a red build means something is broken (not “the test is flaky and we’ve been ignoring it for three months”). Making testing visible in the workflow is what stops the manual layer from quietly slipping back to the end of the iteration.
"The manual layer activates upon delivery of stories to the PM." The acceptance criteria for the story are checked once by the PM (or a QA) who clicks Accept or Reject and moves on. Manual testing can miss defects. The automated tests covered the route taken by the user so you are not chasing a ghost! If every iteration you do a manual regression of the whole app, your automated coverage is too low and you are paying for the gap with people time.
Let automation deal with repetitive tasks! Judgement is Managed. If a team uses one where the other belongs, then they will either ship slow (over-automating exploratory work) or ship buggy (under-automating regression).
Phase 6: Closure, skip the report, keep the retro
The summary report in an official course material is a test summary report with pass/fail counts, bug counts, coverage metrics, etc. In iteration-based teams, typically, everyone reads what they report except the writer. The information collected can be utilized for retros and is insignificant outside of them.
What matters the most in closure.
- What did testing miss? A bug that landed in production is a test-case gap. Write it down. Add the missing case to the automated layer for next iteration.
- What did testing slow down without catching anything? Flaky tests, environment problems, manual cases that never failed in twelve iterations. Cut them. They're paying salary for no return.
- What needs to happen before the next iteration? Usually environment work. Sometimes test data refresh. Sometimes a fragile dependency that's about to break.
These three items belong in the retrospective, not a test summary report. The team that summarizes everything in 4 pages every iteration is producing audit material. A team that includes three retro line items in the plan for the next iteration is producing. Same task, plenty of difference. Our notes on getting more out of your iteration review cover how to keep that conversation honest without turning it into theatre.
STLC inside iterations — what changes when you run agile
Every time a waterfall context is released, a STLC run is made. Six weeks for building, two weeks for testing, then ship. STLC runs once per story in iteration context, which is compressed into the iteration window. The textbook phase boundaries disappear and the activities are run in parallel.
When a waterfall-trained QA joins an agile team, they are most confused by this. They expect the STLC cascade to be visible: requirements → planning → design → environment → execution → closure. All of that can occur in any order within an iteration. Over a fortnight, the six activities occur at various stages on ten different stories. The DORA research on test automation as a capability makes the case that high-performing teams keep automation suite ownership inside the development team, not parked with a separate QA function. The same iterative pattern is described in how to integrate testing into an agile workflow.
Each story should have its own mini-software testing lifecycle (STLC), compressed to the size of the story – that’s the mental model that works. Larger stories will receive more of each phase. Less is more. The calendar of the team doesn't have “test phase”. Each story of the team packs in the test inside it.
It's saying goodbye to the test summary report that is the hardest part of the transition. The most visible STLC artifact, it is the least useful in an iterative context. Swap it out for retro line items, automated coverage metrics in the pipeline, and the acceptance criteria themselves. You will forfeit the audit trail. Your velocity will increase. That was worth it
When NOT to run STLC formally
The sequence of STLC formalized plays a role. Three instances where it demonstrates its value.
- Regulated industries (medical, aerospace, finance) where the audit trail is the deliverable. The test summary report is what the regulator reads. The phase-boundaries are how you prove coverage. Iterative STLC won't satisfy a regulator that wants to see test cases linked to requirements linked to code paths.
- Hardware-bound or single-release products where the release cadence is yearly and the cost of a missed bug is replacement-level expensive. Phones, embedded systems, payment terminals. The cost of running STLC formally is small relative to the cost of shipping a bug to manufactured devices.
- Compliance handoffs between teams where one team builds and another tests, and the contract between them needs to be documented at the artifact level. Common in agency / contractor work, less common in product teams.
Outside of those scenarios, the formal sequence is overhead. The process cost of testing is lower and the testing itself is better when we compress an increment into stories with acceptance criteria, automated coverage, and a retro line item.
As a tracker company we say all this If your team is required to have a formal software testing life cycle (STLC) because of compliance, our tool is not for you. Choose a tool built to provide an audit trail. LiteTracker is designed for teams that conduct iterations, in which the acceptance criteria serve as the test plan.
Frequently asked
What is the software testing life cycle?
The Software Testing Life Cycle (STLC) is a set of six phases through which the testing of any software item goes through. These six phases are: requirements analysis, test planning, test case design, test environment setup, test execution and test closure. There is a vocabulary for testing just like there is a vocabulary for building development lifecycle. The six phases act as concepts but mislead as a literal sequence when the team runs iterations.
What are the six phases of STLC?
There are six main stages in testing a software programme. They are a requirements analysis, test planning, test case design, test environment setup, test execution, and test closure. In iterative teams, all six occur concurrently within each iteration, rather than one after the other.
What's the difference between SDLC and STLC?
SDLC stands for Software Development Life Cycle. It is the life cycle for developing software. The lifecycle of testing is STLC. STLC operates within SDLC while also providing feedback to SDLC. SDLC follow MY-BC: SDLC waterfall phases. In iterative SDLC, test engineering happens within each iteration with development just as design engineering does.
Is STLC the same as agile testing?
NO. The Software Testing Life Cycle (STLC) is used to describe the phases that the testing team works with, while Agile Testing is the practical implementation of running such phases in a compressed manner inside an iteration rather than sequentially before release. Although Agile teams execute all six STLC activities, they don’t draw phase boundaries between them
What's the most under-invested STLC phase?
Setup for Testing Environment. Based on the textbook it’s a precondition, but in practice, it’s where iteration time leaks most. Teams that don’t invest in environment reliability lose time to acceptance defects on broken staging, expired keys, and missing data. Engineering work on the platform is what the fix is.
Do you need a test summary report?
Generally not in iterative teams. Data is used for retros and the audit purpose is seldom genuine. In many contexts, report more or less replaces with three retro line items: what testing missed, what testing slowed down, what needs to happen next iteration. Industries regulated are the exception.
Who is responsible for STLC in an agile team?
Responsibility spread across phases. The PM is responsible for the acceptance criteria. Automated tests are the responsibility of engineers. The duty of QA is to own exploratory along with complex scenarios. The entire team is responsible for retrospectives. Iterative Teams Have No STLC Owner
Can you skip STLC entirely?
Not quite. All teams test; whether or not the testing is structured/testing the structure is the real question. Ad-hoc testing results in unreliable reporting with incomplete coverage. Acceptance Criteria is the right minimum on every story, an automated test layer that runs on every push, and one manual sanity-check per story at PM acceptance.
Still stuck
If your team writes acceptance criteria for every story, runs an automated test suite on every push, and clicks Accept or Reject when stories land in the PM’s queue, then you’re running STLC at the right level for an … At that point, most formal phase boundaries are redundant.
LiteTracker is your answer if you're after a tool that keeps stories, acceptance criteria, PM-acceptance status in a single place, and considers velocity to be accepted stories only. The basic plan is free and does not limit the number of users. The import takes about minute. Choose a tool developed for audits, if your squad is in a controlled sector that requires formal STLC artefacts; LiteTracker is not that!
STLC shouldn't be carried out as a ceremony. Use it in a vocabulary for actions that already happened in the iteration itself.