SDLC vs STLC is a classic interview question, and most explanations make it sound more complicated than it is. The software development lifecycle (SDLC) describes how a product gets built, from idea to release. The software testing lifecycle (STLC) describes how testing happens inside that bigger process. One contains the other. Testing is not a phase that follows development; it's a parallel track that runs alongside it.
SDLC in one paragraph
The textbook SDLC phases: requirements, design, implementation, testing, deployment, maintenance. Waterfall walks through them once, in order. Agile compresses the whole cycle into a sprint and repeats it every one to two weeks. Either way, the same activities happen; what changes is how often and how much at a time. On my team, a single sprint contains a little of everything: refining stories, building, testing, and shipping.
STLC: the textbook version
The STLC has six commonly listed phases:
- Requirement analysis: read the requirements from a tester's angle and ask what's testable and what's ambiguous.
- Test planning: decide scope, approach, environments, and what gets automated.
- Test case design: write the cases and prepare test data.
- Environment setup: get builds, devices, and data in place.
- Test execution: run the tests, log defects, retest fixes.
- Closure: summarize results and capture what to improve.
Each phase has entry and exit criteria, meaning conditions for starting and finishing. That's the version the textbook, and the interviewer, expects you to know.
Where SDLC and STLC intersect
The key idea is that every STLC phase maps onto an SDLC phase, earlier than most people assume. Requirement analysis happens during requirements, not after code exists. Test design happens while developers design and build. Only execution waits for a build. This is what people mean by "shift left": the cheapest bug I ever find is a contradiction in an acceptance criterion during refinement, because nobody has to write or rewrite any code to fix it.
What STLC actually looks like in an agile team
Nobody on my team says "we are now in the test planning phase." But every phase still happens, compressed and informal:
- Requirement analysis is me asking questions in sprint planning and flagging untestable acceptance criteria.
- Test planning is a short note on the JIRA ticket: what I'll check, on which devices, and whether it needs a new Maestro flow.
- Test design mixes lightweight written cases for complex logic with exploratory charters for the rest.
- Execution runs continuously as stories land, with automated smoke and regression suites doing the repetitive part in CI.
- Closure is folded into the sprint review and retro rather than a formal report.
The phases didn't disappear in agile; they shrank to fit inside a sprint and lost their ceremony. Recognizing them in that compressed form is what separates someone who has done the job from someone who memorized the diagram.
Interview mistakes I'd avoid
Three answers that give people away. First, "testing starts when development ends." That's waterfall thinking, and it's wrong even in waterfall, since test design never needed a build. Second, reciting the six STLC phases without being able to say what any of them looks like on a Tuesday in a sprint. Interviewers push on this precisely because the recitation is easy. Third, treating SDLC and STLC as competing alternatives you choose between. They're nested, not rivals, and saying "STLC runs inside the SDLC in parallel with development" answers the comparison question in one sentence.
One-line summary: the SDLC builds the product; the STLC runs inside it as a parallel track, starting at requirements, not at code-complete.
If you internalize that nesting, both acronyms stop being trivia and start being a map of where your testing time should go: as early in the cycle as someone will let you in the room.