02 — SDLC Models — Where Testing Lives in Each

"A sequence of phases you memorize for an exam" was my SDLC model, and it was trivia until I saw what each model was really claiming. The idea that changed it: each SDLC model is really a claim about where testing sits relative to coding, and that single choice changes everything about how a tester works [1][2]. Waterfall parks testing at the end; the V-Model gives every dev phase its own test phase; Agile melts testing into the same sprint as the code; Spiral wraps risk analysis around every loop. The model isn't trivia — it dictates when I get involved, what artifacts I have to work with, and how late a defect can hide.

The framing that landed is that all of these models are answering the same two questions differently: how do we slice the work, and when does verification happen. Once I saw it as a 2D choice rather than a list of names, the differences stopped feeling arbitrary.

The spectrum, in one picture

Here's the whole landscape as four timelines. The dash length is "how long a chunk of work goes before it's tested":

The vertical axis isn't formality — it's how long a defect can survive before something catches it. Agile's dashes mean a defect introduced Monday is found by Friday. Waterfall's tail block means the same defect sits undetected for months.

Waterfall and the V-Model: sequential, with different ambition

Waterfall is the original sequential model: requirements, then design, then implementation, then testing, then deployment — each phase completes before the next begins [3]. Testing is a single phase at the end. Its virtue is simplicity and predictability; its fatal flaw is that defects discovered at the end are the most expensive ones to fix, because the faulty assumption is baked into every earlier phase.

The V-Model is Waterfall's honest response to that flaw [4]. It keeps the sequential discipline but extends each development phase downward into a matching test phase that runs upward: unit tests verify the code, integration tests verify the design, system tests verify the architecture, and UAT verifies the requirements. The "V" is literally a V — dev descends the left arm, testing ascends the right. The mental shift: testing isn't a phase that follows development, it's a parallel activity whose plan is written during development. The test for a requirement is designed the moment the requirement is signed off.

Spiral: risk as the organizing principle

Spiral is the one I underestimated. It's iterative like Agile, but each loop is explicitly four quadrants — plan, risk-analyze, engineer, evaluate — and the risk analysis quadrant is what makes it distinct [5]. Every iteration starts by asking "what's the biggest risk right now," then does just enough engineering to retire that risk, then loops. Testing in Spiral isn't a separate activity; the evaluate quadrant is the testing, and its purpose is to decide whether the risk was actually retired before the next loop begins.

Spiral is the model for projects where the dominant uncertainty is technical or requirements-shaped — research-heavy work, large migrations, anything where "we don't yet know if this is possible" is a real question. You spiral precisely because you can't plan the whole thing up front, but you also can't pretend the risk doesn't exist.

Agile and its frameworks: testing inside the sprint

Agile inverts Waterfall's central assumption. Instead of one big delivery at the end, it delivers working software in short cycles (sprints or iterations), and testing is integrated throughout each iteration rather than existing as a separate phase [6]. The Agile Manifesto's values — working software over comprehensive documentation, responding to change over following a plan — directly shape where testing lives [7]. In Agile, a feature isn't "done" until it's tested; the definition of done includes tests passing.

Under the Agile umbrella sit several frameworks, and the roadmap treats them as separate nodes for good reason — they organize the work differently:

• Scrum organizes work into time-boxed sprints (usually 1–4 weeks) with fixed roles (Product Owner, Scrum Master, Developers) and ceremonies (sprint planning, daily standup, review, retrospective) [8]. Testing happens continuously within the sprint, and a sprint's increment is supposed to be potentially shippable — which is only true if it's tested.
• Kanban has no time-boxed sprints at all. Work flows continuously across a board (To Do → In Progress → Done), and the key constraint is work-in-progress limits — a cap on how many items can sit in any column [9]. For QA, Kanban's strength is that it makes bottlenecks visible: if the "In QA" column is permanently full, that's a systemic signal, not a personal failing.
• XP (Extreme Programming) is the most prescriptive about engineering practices — test-driven development, continuous integration, pair programming, refactoring [10]. It's where a lot of the testing techniques later in the roadmap (TDD especially) were born. XP treats testing as so central that the tests are written before the code, every time.

The box-testing lens, applied

The roadmap nests white-box, black-box, and gray-box testing inside the SDLC discussion, and the connection is worth making explicit. Each SDLC model implies a default testing lens:

• Waterfall defaults to black-box. The spec is frozen up front; testers verify the finished product against it, with no need to read the code.
• V-Model layers white-box at the unit level (the developer's tests) over black-box at the system level (the QA team's tests). The matching of phases to test levels is the whole point.
• Agile collapses the distance between coder and tester, so gray-box becomes the natural lens — the tester sits next to the developer, sees the code, and uses that knowledge to design better behavioral tests.
• Spiral is lens-agnostic; whatever the risk demands.

The box lens (covered in my foundations notes) and the SDLC model aren't independent topics. They're two axes of the same decision: how do we slice the work, and how much do we let ourselves see inside.

Testing Techniques: the bridge

The roadmap's Testing Techniques node is the bridge from these models to the actual practice of designing test cases [11]. Techniques — equivalence partitioning, boundary-value analysis, decision tables, state transition — are how you turn a vague "test the login" into a finite, defensible set of cases. They belong to whatever SDLC model you've chosen, but they're most visibly practiced in V-Model and Agile, where the test design happens in parallel with development rather than as an afterthought.

How I use this

The practical payoff is a diagnostic question I ask of any project I join: which SDLC model is this, really, and where does that put me?

• If it's Waterfall in name only — "Agile" ceremonies but testing still happens in a tail phase — I know defects will pile up and I should push for shift-left, even informally, by writing tests during the sprint.
• If it's genuine Scrum, I insist the definition of done includes automated tests passing, and I fight any "we'll test it next sprint" pattern, because that's just Waterfall wearing a standup.
• If it's Kanban, I watch the WIP limit on my own column; a chronically full QA column is a process problem, not a "work harder" problem.
• If it's Spiral or research-shaped, I make the risk analysis explicit — write down "the top risk is X, here's the test that will tell us if we've retired it."

The model isn't decoration. It decides whether I'm writing tests before, during, or after the code, and that single timing choice dominates everything else about whether the tests actually help.

References

[1] Cadabra Studio, "QA role in SDLC: why is quality assurance important in IT," 2023. [Online]. Available: https://cadabra.studio/blog/why-is-quality-assurance-important-qa-role-in-sdlc/

[2] TutorialsPoint, "SDLC overview," 2023. [Online]. Available: https://www.tutorialspoint.com/sdlc/sdlc_overview.htm

[3] Guru99, "What is Waterfall model in SDLC? Advantages and disadvantages," 2023. [Online]. Available: https://www.guru99.com/what-is-sdlc-or-waterfall-model.html

[4] Guru99, "V-Model in software testing," 2023. [Online]. Available: https://www.guru99.com/v-model-software-testing.html

[5] Netguru, "Spiral model in software engineering: a practical guide," 2023. [Online]. Available: https://www.netguru.com/blog/spiral-model-software-engineering

[6] Guru99, "Agile methodology: what is Agile model in software testing?," 2023. [Online]. Available: https://www.guru99.com/agile-scrum-extreme-testing.html

[7] Agile Alliance, "Manifesto for Agile Software Development," 2001. [Online]. Available: https://agilemanifesto.org/

[8] Atlassian, "Scrum — what is, how it works," 2024. [Online]. Available: https://www.atlassian.com/agile/scrum

[9] Atlassian, "Kanban — a brief introduction," 2024. [Online]. Available: https://www.atlassian.com/agile/kanban

[10] Agile Alliance, "What is Extreme Programming (XP)?," 2023. [Online]. Available: https://www.agilealliance.org/glossary/xp

[11] Elprocus, "What are testing techniques: types, advantages & disadvantages," 2023. [Online]. Available: https://www.elprocus.com/what-are-testing-techniques-types-advantages-disadvantages/