SDLC Models and Testing — Waterfall, V-Model, and Agile

This post is part of the ISTQB Foundation Level series — a structured guide to software testing concepts as defined by the ISTQB syllabus, for exam candidates and QA practitioners building a solid foundation.

Why the SDLC Model Matters for Testing

The question “when do we test?” has a different answer depending on how your team builds software. In a sequential waterfall project, testing happens after the code is written. In an agile team, testing happens in every sprint. In a DevOps pipeline, automated tests run on every commit.

The Software Development Life Cycle (SDLC) model your organisation uses determines:

When testers get involved
What types of testing are performed at each stage
How defects are found, reported, and tracked
How much testing is possible given the timeline
How early — or late — quality feedback reaches the team

The ISTQB Foundation Level syllabus covers the major SDLC models because a tester who doesn’t understand the model they’re working within will constantly be making incorrect assumptions about what’s expected of them.

Sequential Models

Waterfall

The Waterfall model is the original structured approach to software development. Phases flow sequentially, with each phase completed before the next begins:

Requirements → Design → Implementation → Testing → Deployment → Maintenance

How testing fits in Waterfall:

Testing is a discrete phase that begins after implementation is complete. This has several consequences:

Testers receive completed code rather than being involved in earlier phases
Defects found late are expensive to fix (see the cost table in Post 1)
If development runs over schedule, testing time is typically compressed first
The test phase must detect all defects that requirements, design, and coding could have prevented

The core problem with late testing: by the time testers see the software, major architectural decisions are locked in. A fundamental design flaw discovered in testing might require changes that cascade back through the entire development phase. This is why many waterfall projects shipped with known defects accepted rather than fixed — the cost of fixing was too high at that point in the cycle.

When Waterfall still makes sense:

Projects with extremely stable, well-understood requirements
Safety-critical systems requiring formal documentation of each phase
Contractual or regulatory requirements for sequential phase gates
Large-scale infrastructure projects with long planning horizons

:::note[ISTQB Exam Tip] The ISTQB syllabus presents Waterfall’s limitations neutrally — it doesn’t say Waterfall is bad, it says certain models have different trade-offs. Focus on understanding those trade-offs rather than treating Waterfall as obsolete. :::

V-Model

The V-Model addresses Waterfall’s “late testing” problem by mirroring each development phase with a corresponding test phase. The two branches of the V represent development (left side going down) and testing (right side going up), connected at the implementation point:

Requirements Analysis ←————————→ Acceptance Testing
  System Design     ←————————→ System Testing
    Architecture    ←————————→ Integration Testing
      Module Design ←————————→ Unit Testing
              Implementation

What the V-Model changes:

The critical insight is that test design begins during the corresponding development phase, even though test execution happens later. When requirements are written, acceptance test cases are designed. When system architecture is defined, system test scenarios are planned. This creates a direct traceability from requirements through to test cases.

This means:

Testers are involved from the beginning, not just during the test phase
Ambiguities in requirements are caught when test design is impossible against an unclear spec
Each test level has a clear counterpart in the development process

Benefits of the V-Model:

Defects in requirements and design are caught earlier (during test planning)
Clear structure and traceability
Well-suited to safety-critical and regulated domains

Limitations of the V-Model:

Still sequential at its core — changes in requirements are expensive
Limited flexibility once phases are underway
Not well-suited to projects with evolving or unclear requirements

:::tip[ISTQB Exam Tip] The V-Model maps test levels to development phases. Know these mappings for the exam: unit testing ↔ module design, integration testing ↔ architecture, system testing ↔ system design, acceptance testing ↔ requirements. This traceability is the defining feature of the V-Model. :::

Iterative and Incremental Models

Between the fully sequential models and full agile lies a family of iterative and incremental approaches. These models build software in repeated cycles (iterations), delivering a subset of functionality in each cycle.

Key characteristics:

Requirements evolve over the course of the project
Each iteration produces a potentially shippable increment
Feedback from each iteration informs the next
Testing occurs within each iteration, not as a final phase

Testing implications:

Testers need to test early and often, not just at the end
Regression testing becomes critical — each new increment must not break existing functionality
Test automation investment pays dividends earlier
Defects can be fixed within the iteration that found them

Examples include the Rational Unified Process (RUP) and spiral development. Many organisations use hybrid approaches that combine sequential planning with iterative development.

Agile Models

Core Agile Principles for Testing

The Agile Manifesto’s values have direct implications for how testing works:

Working software over comprehensive documentation: Testing focuses on working software, not exhaustive test documentation
Customer collaboration over contract negotiation: Testers work closely with product owners and users, not just against a static spec
Responding to change over following a plan: Test strategies adapt as the product evolves
Individuals and interactions over processes and tools: Team dynamics (including tester–developer collaboration) take priority

Agile testing is not the absence of structure — it’s structure adapted to change and collaboration.

Testing in Every Sprint

In Scrum, the most common agile framework, a sprint is a time-boxed development cycle (typically 1–4 weeks). Testing is not a separate phase — it’s part of every sprint:

Sprint Stage	Testing Activity
Sprint Planning	Review acceptance criteria, identify test scope
Daily Standup	Surface blockers, communicate test findings
Development	Unit testing, TDD, developer testing
Sprint work	Integration testing, exploratory testing, automation
Sprint Review	Acceptance testing with stakeholders
Sprint Retrospective	Reflect on testing process, improve for next sprint

A feature is not “done” until it has been tested. The Definition of Done (DoD) for most mature agile teams includes test coverage, acceptance criteria verification, and regression tests updated.

The Whole-Team Approach to Quality

Agile explicitly rejects the idea that quality is the test team’s responsibility. In a healthy agile team:

Developers write unit tests and take responsibility for the quality of their code
Testers coach the team on testability, risk, and quality practices
Product owners write clear acceptance criteria
Everyone participates in identifying and resolving defects quickly

The tester’s role shifts from “gatekeeper who approves releases” to “quality advocate who raises visibility of risks.”

:::tip[ISTQB Exam Tip] The ISTQB syllabus covers the “whole-team approach” as an agile concept. Key idea: quality is everyone’s responsibility, not just the testers’. Testers in agile teams often act as coaches and collaborators, not just executors of test scripts. :::

DevOps and CI/CD

DevOps extends agile principles into the operational domain, breaking down the wall between development and operations. For testing, DevOps introduces the concept of continuous testing — automated tests run as an integral part of the software delivery pipeline.

CI/CD Explained

Continuous Integration (CI): Developers commit code to a shared repository frequently (multiple times per day). Each commit triggers an automated build and test run. If tests fail, the team knows within minutes, and the commit is rejected or flagged.

Continuous Delivery (CD): The software is always in a deployable state. After CI tests pass, the artifact is automatically deployed to a staging or pre-production environment and additional automated tests run.

Continuous Deployment: Every commit that passes all tests is automatically deployed to production, with no manual approval step.

Testing in DevOps

The DevOps model demands a specific approach to testing:

Test Type	When in Pipeline	Purpose
Unit tests	Every commit (CI)	Fast feedback on code correctness
Integration tests	CI/CD pipeline	Service and component interaction
API tests	CD pipeline	Contract verification
UI / E2E tests	Pre-production	User journey validation
Performance tests	Pre-production / production	Load and scalability verification
Exploratory testing	Pre-release	Human-driven risk investigation
Production monitoring	Production	Detect real-world failures post-release

The critical insight: automated tests must be fast enough to not bottleneck the pipeline. Slow test suites become obstacles; teams start skipping them. A well-designed DevOps pipeline has tests stratified by speed and scope — fast unit tests run on every commit, slower E2E tests run less frequently.

Shift-Left and Shift-Right

Shift-Left

“Shift-left” means moving testing activities earlier in the development lifecycle — to the left on the typical timeline diagram where time runs left to right.

What shift-left looks like in practice:

Testers reviewing requirements before a line of code is written
Test-driven development (TDD): writing tests before writing code
Developers running unit tests as part of their normal workflow
Acceptance criteria written and reviewed before sprint work begins
Performance testing environment set up at the start of a project, not the end

Why it matters: Every principle 3 from Post 1 — early testing saves money. A defect found in requirements costs a fraction of what it costs to find in production. Shift-left is the practical implementation of that principle.

Challenges of shift-left:

Requires testers who are comfortable working with incomplete software and requirements
Needs investment in test infrastructure early in the project
May meet resistance from teams accustomed to sequential hand-offs
Requires strong collaboration between testers, developers, and product owners

Shift-Right

“Shift-right” means extending testing activities later in the lifecycle — into production and beyond.

What shift-right looks like in practice:

Monitoring production systems for anomalies and failures
A/B testing and canary deployments — releasing new features to a subset of users first
Synthetic monitoring — automated tests that run against production continuously
Chaos engineering — deliberately introducing failures to test system resilience
Feature flags — enabling features for specific user segments for controlled rollout
User feedback loops — treating production user behaviour as a signal about quality

Why it matters: Some defects only appear under real production conditions — real user data volumes, real network conditions, real usage patterns that no test environment fully replicates. Shift-right accepts this reality and builds quality assurance mechanisms directly into production operations.

:::note[ISTQB Exam Tip] Shift-left and shift-right are not alternatives — they are complementary. A mature quality strategy does both: prevents defects early through shift-left and detects production-specific issues through shift-right. Exam questions may present them as choices; understand that the best answer is often “both, in a risk-based combination.” :::

Choosing the Right Model

The ISTQB doesn’t prescribe one SDLC model over another — it teaches testers to adapt their approach to the model their organisation uses. Here’s a practical framework for thinking about model choice:

Question	Points toward
Are requirements stable and well-understood?	Sequential (Waterfall, V-Model)
Are requirements expected to evolve?	Iterative / Agile
Is regulatory or contractual documentation required?	Sequential (with formal phase gates)
Is fast time-to-market critical?	Agile / DevOps
Does the team have automated testing capability?	Agile / DevOps
Is the system safety-critical?	V-Model, with formal verification
Is the team small and co-located?	Agile
Is the project large, distributed, multi-vendor?	Sequential or hybrid

In practice, most modern organisations use some form of hybrid: agile development with sequential planning for large features, CI/CD pipelines for deployment, and V-Model-style traceability for compliance. The skill is recognising which elements apply to your situation.

Conclusion

Understanding SDLC models is not an academic exercise for ISTQB candidates — it’s a fundamental professional competency. The model you work within determines your constraints: when you test, what artifacts you work with, how much influence you have over the product before code is written, and what “done” means.

The trends are clear: industry is moving toward earlier testing (shift-left), more automation (CI/CD), and broader quality assurance that extends into production (shift-right). The V-Model’s insight about test design starting during requirements phases has been absorbed into agile as story-level acceptance criteria. Waterfall’s discipline around documentation has been adapted for regulated contexts within otherwise agile organisations.

:::tip[ISTQB Exam Tip] For the exam, be prepared to: (1) identify test levels that correspond to V-Model development phases; (2) describe how testing differs between sequential and agile models; (3) explain shift-left and shift-right with examples; (4) explain the whole-team approach to quality. These topics appear consistently across exam versions. :::

The next area the ISTQB Foundation Level covers is test levels and types — moving from when we test to what we test and how. Understanding the SDLC context from this post will make those distinctions significantly clearer.