--- title: "02 — SDLC Models — Where Testing Lives in Each" uid: sdlc-models tags: ["waterfall", "roadmap:qa", "spiral", "v-model", "kanban", "sdlc", "xp", "scrum", "agile"] excerpt: "Each SDLC model is a claim about where testing sits relative to coding — and that single choice dictates when a tester gets involved, what artifacts exist, and how late a defect can hide." date: 2026-08-13T03:27:49+0000 source: https://www.aveshina.my.id/en/blog/sdlc-models --- "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": ```figure ``` 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/](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](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](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](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](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](https://www.guru99.com/agile-scrum-extreme-testing.html) [7] Agile Alliance, "Manifesto for Agile Software Development," 2001. [Online]. Available: [https://agilemanifesto.org/](https://agilemanifesto.org/) [8] Atlassian, "Scrum — what is, how it works," 2024. [Online]. Available: [https://www.atlassian.com/agile/scrum](https://www.atlassian.com/agile/scrum) [9] Atlassian, "Kanban — a brief introduction," 2024. [Online]. Available: [https://www.atlassian.com/agile/kanban](https://www.atlassian.com/agile/kanban) [10] Agile Alliance, "What is Extreme Programming (XP)?," 2023. [Online]. Available: [https://www.agilealliance.org/glossary/xp](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/](https://www.elprocus.com/what-are-testing-techniques-types-advantages-disadvantages/) ```quiz Q: The single choice that most defines an SDLC model from a tester's perspective is… - how many phases the model has - where testing sits relative to coding - whether the model has a fancy name correct: 1 explain: Waterfall parks testing at the end; the V-Model gives every dev phase a parallel test phase; Agile melts testing into the sprint. That timing choice dominates everything about how the tester works. Q: In the V-Model, the test phases… - all run at the very end, after all development - mirror the development phases — each dev phase has a corresponding test phase running up the other arm of the V correct: 1 explain: The V is literal: dev descends the left arm, testing ascends the right. The test for a requirement is designed when the requirement is signed off, not months later. Q: What distinguishes Kanban from Scrum? - Kanban has no time-boxed sprints; work flows continuously with WIP limits on each column - Kanban requires daily standups; Scrum does not - Scrum has no roles; Kanban has a Scrum Master correct: 0 explain: Kanban is flow-based with work-in-progress limits that surface bottlenecks. Scrum is iteration-based with fixed-length sprints and defined roles. Q: The Spiral model's defining quadrant — the one that distinguishes it from other iterative models — is… - planning - risk analysis - engineering correct: 1 explain: Every Spiral loop starts with risk analysis: identify the biggest risk, do just enough engineering to retire it, then evaluate. Risk is the organizing principle. Q: Which testing lens does Waterfall most naturally default to? - white box, because testers read all the code - black box, because the spec is frozen up front and testers verify the finished product against it correct: 1 explain: With requirements locked before coding, testers verify behavior against the spec without needing to see internals. Black box fits Waterfall's separation of concerns. ```