2.1 SDLC Models and Good Testing Practices

What an SDLC Model Is and Why It Matters to Testing

A software development lifecycle (SDLC) model is an abstract, high-level representation of the development process that defines the phases of the lifecycle and the order in which they are performed. The ISTQB CTFL v4.0 syllabus (section 2.1) is explicit that every software development activity should have a corresponding test activity so that defects can be found and prevented as early as possible. No model is presented as universally best; what matters is whether testing is integrated to provide timely feedback and manage risk.

The syllabus groups SDLC models into broad families. Sequential development models describe the process as a linear, sequential flow of activities — any phase should ideally begin only when the previous one finishes. The classic examples are the waterfall model, where requirements, design, coding, and testing happen in strict order, and the V-model, which pairs each development phase with a matching test level so test activities are planned in parallel with development even though execution still happens later.

Iterative and incremental development models group activities into smaller cycles. Incremental development builds the system feature by feature, delivering usable pieces over time. Iterative development repeatedly refines a set of features through several cycles until the result is satisfactory. Both deliver working software earlier and allow earlier feedback, but each new increment or iteration can affect what already works, which raises regression risk.

Agile, the V-Model, and How Testing Maps to Each

Agile software development uses short iterations, frequent delivery, close stakeholder collaboration, and evolving understanding of the product. Testing in Agile is typically continuous and a whole-team responsibility: testers contribute to backlog refinement, write and clarify acceptance criteria, design tests, perform exploratory testing, build automation, and support release decisions every iteration rather than in a separate end phase.

The table below contrasts how the same testing concerns appear across models.

In the V-model specifically, component testing corresponds to detailed design, integration testing to architectural design, system testing to system requirements, and acceptance testing to user requirements. This mapping is a frequent exam point.

Good Testing Practices That Hold Across Models

Regardless of the lifecycle, the CTFL syllabus lists good practices that should always apply:

• Every development activity has a corresponding test activity — requirements are reviewed and feed acceptance tests; architecture feeds integration test planning; code is supported by component testing and static analysis.
• Each test level has objectives specific to that level, so testing is not duplicated needlessly across levels.
• The test basis is analyzed and reviewed while test cases are being designed, which finds defects in the basis itself (ambiguous or untestable requirements) before code exists.
• Testers are involved as early as possible, ideally during requirement reviews, to maximize defect prevention.

Good practices stabilize testing even as documentation style changes: a waterfall project may rely on formal phase-gate documents, while an Agile team relies on lightweight artifacts and continuous conversation, yet both need clear test objectives, a testable basis, managed environments, and useful defect evidence.

Retrospectives, DevOps, and Continuous Feedback

Modern lifecycles institutionalize feedback. DevOps unites development and operations to deliver software faster and with higher quality through automation, shared ownership, and a strong feedback loop from build through deployment to production. Continuous integration and continuous delivery (CI/CD) pipelines run automated checks on every change so defects surface within minutes. Retrospectives — held at the end of an iteration or release — let the team inspect what went well and what should improve, including the test process itself, turning lessons into concrete actions.

The exam often presents a team that writes all tests after release or only reviews requirements at code freeze; these are warning signs that testing is not integrated throughout the SDLC.

Choosing a Model and Common Influences

0 syllabus stresses that the SDLC model chosen for a project is influenced by several factors, and these in turn shape how testing is organized. The most important influences are: the nature of the product and project (a regulated medical device differs from a marketing website), the business priorities (time-to-market versus thoroughness), and identified product and project risks. For a safety-critical avionics system, a sequential model with formal phase gates and heavy documentation may be mandated; for a consumer mobile app, a fast Agile cadence with continuous delivery may fit better.

A hybrid is common: many organizations combine an Agile delivery rhythm with formal regulatory evidence, so testers produce both lightweight day-to-day artifacts and the audit trail a standard requires.

A subtle but examinable point is that the lifecycle changes the timing and emphasis of test activities, not the fundamental test process. The activities of test planning, monitoring and control, analysis, design, implementation, execution, and completion still occur — they are simply distributed differently. In waterfall they cluster into a phase; in Agile they recur every iteration; in DevOps many run continuously inside a pipeline. Recognizing this lets you answer scenario questions that describe an unfamiliar team setup: map the described activity onto the standard test process rather than memorizing one model.

Worked Example: Same Feature, Three Models

Consider building a "apply discount code" feature. In waterfall, requirements for the discount rules are fully specified and reviewed up front, component and system tests are designed against that spec, and execution happens in a dedicated late test phase. In an incremental project, a basic discount works in increment one and stacking/expiry rules arrive later — so each increment is tested as delivered, and regression tests grow with the system.

In Agile, the discount story enters a sprint with acceptance criteria written collaboratively; the team writes tests early, automates them in CI, and demonstrates the working feature at the sprint review, gathering feedback immediately. The what (verify the discount calculates correctly and does not break the cart) is identical; the when and how differ by model — and that is precisely what CTFL questions probe.