Module 2 · Software development lifecycle

Software Development Models

By the Mutqan Soft QA team · · 18 min · Beginner

A software development model, which ISTQB calls an SDLC model, describes how the development process is organised: which activities happen, in what order and how they overlap. It arranges in time the activities from the SDLC and STLC guide. The ISTQB Foundation syllabus (CTFL v4.0) names three families: sequential models such as the waterfall model and the V-model, iterative models such as the spiral model and prototyping, and incremental models such as the Unified Process.

Take a clinic that wants an online appointment system with booking, SMS reminders and online payment. Built sequentially, all three features are specified, designed, built and tested, then released together months later. Built incrementally, booking is released first, reminders follow in the next increment and payment in the third. Built iteratively, a rough version of the whole flow is shown to receptionists and patients and reworked over several cycles. Most agile teams combine the last two.

Why it matters

The model decides when a tester can do what. CTFL v4.0 lists what the choice of lifecycle affects: the scope and timing of test activities, the level of detail of test documentation, the choice of test techniques and test approach, the extent of test automation, and the tester’s role and responsibilities.

An approach copied from another model fails: a formal test plan for a two-week increment is outdated before approval, and fortnightly releases without automated regression testing re-check a smaller share of a growing product each time. Knowing the model lets you name such a risk in a project’s first week instead of its last.

Sequential, iterative and incremental

All three contain the same work; they differ in how much of the product passes through each activity at once and how often the activities repeat. Incremental means adding pieces; iterative means repeating and refining. They are separate ideas that can be used alone or together, and they are often combined.

  • Sequential: the phases run in a fixed order, each finished before the next starts, and the whole product is released once at the end. Examples: the waterfall model and the V-model.
  • Iterative: the team builds a version, evaluates it and improves it in repeated cycles, returning to features that already exist. Examples: prototyping, and the spiral model, where each cycle is planned around the most important open risks.
  • Incremental: the product is split into pieces; each increment is specified, designed, built and tested, and adds to what was delivered before. Example: the Unified Process.
  • Both together: each short cycle delivers a usable increment, and feedback on it can change earlier work. Most agile methods, such as Scrum, work this way; some teams call any such approach simply "agile".

How testing differs in each model

Every model contains the same test activities, from test planning and analysis through design, implementation and execution to test completion. What changes are the five aspects CTFL v4.0 lists: the scope and timing of those activities, the detail of the documentation, the techniques, the extent of automation and the tester’s role.

Sequential models run dynamic tests on the whole product only after it is built, iterative models re-test reworked features every cycle, and incremental models add each piece with regression testing of the earlier ones. Conceptual model

Sequentiale.g. waterfall, V-model

  1. 1Specify everything
  2. 2Design and build everything
  3. 3Test everything
  4. 4Release once
First code to test dynamically:
Late, after implementation
Re-tested in every cycle:
No cycles: testing is concentrated near the end
Test documentation:
Detailed and formal
Main testing risk:
Requirement defects found late; test phase squeezed

Iterativee.g. spiral, prototyping

  1. 1Build a version of the whole
  2. 2Test and evaluate it with users
  3. 3Rework the same features

Repeats: Back to step 1

First code to test dynamically:
Early, a rough version
Re-tested in every cycle:
Reworked features; their test cases change
Test documentation:
Light until the design settles
Main testing risk:
Detailed tests written too early go out of date

Incrementale.g. Unified Process

  1. 1Increment 1: build, test, deliver
  2. 2Increment 2: add, test, re-check 1
  3. 3Increment 3: add, test, re-check 1 and 2
First code to test dynamically:
Early, the first increment
Re-tested in every cycle:
Earlier increments; the regression suite grows
Test documentation:
Per increment, plus a growing regression suite
Main testing risk:
Untested interactions between increments

Most agile teams, for example in Scrum, combine iterative and incremental development.

  • Sequential: early on, testers review requirements and do test analysis and test design, but executable code arrives late, so dynamic testing starts late. Documentation is usually detailed and formal. The main risk: a misunderstood requirement may surface only in system or acceptance testing, and when development overruns, the test phase is squeezed.
  • Iterative and incremental: CTFL v4.0 notes that when each iteration delivers a working prototype or product increment, static and dynamic testing may be performed at all test levels in every iteration. Frequent delivery needs fast feedback and extensive regression testing.
  • Agile variants: change is expected throughout, so lightweight documentation and extensive test automation are favoured, and much manual testing uses experience-based techniques such as exploratory testing, in which the tester designs and runs tests at the same time, guided by what they learn from the software, often in a time-boxed session.
  • Iterative rework: detailed step-by-step test cases for a feature that will be redesigned next cycle will need rewriting. Record test conditions and exploratory notes first; write detailed test cases once a part is stable.

Worked example: one clinic app, three ways

The clinic app has three features: booking (B), SMS reminders (R) and online payment (P). The timelines show when each is specified, built and tested.

  • Sequential: in the first weeks the tester reviews the full specification, asks how long before an appointment a reminder is sent and what happens when a paid booking is cancelled, and designs system test cases traced to each requirement. Dynamic testing waits for the complete build.
  • Incremental: increment 2 tests reminders and re-checks booking where reminders read its data: a rescheduled or cancelled appointment must update or cancel its reminder. Increment 3 adds payment and re-checks both. The regression suite grows each time, so automate the booking checks in increment 1.
  • Iterative: in cycle 1 the tester explores the rough version with a receptionist and records usability problems and open questions instead of detailed test cases for screens that will change. As screens settle, key flows become regression checks; the final version gets full system and acceptance testing.
Clinic booking app: Booking (B), Reminders (R), Payment (P)

Sequential:
  [specify B R P] [design] [build] [test B R P] -> release B R P

Incremental:
  [B: specify, build, test] -> release B
  [R: specify, build, test + regression of B] -> release B R
  [P: specify, build, test + regression of B R] -> release B R P

Iterative:
  [rough B R P] -> feedback -> [better B R P] -> feedback -> [final B R P] -> release

Try it: Requirements → Test Cases Try it: Regression Scenario Generator

Choosing a model by context

No model is best in general; the choice depends on context. The organisation or project lead usually decides, but a tester who understands the reasons can adapt the test approach and point out testing risks. Ask:

  • How stable are the requirements? Requirements fixed by an external document, such as a report format published by a regulator, suit a sequential plan; a consumer product whose features will change once users try it suits iterative development.
  • How soon is value or feedback needed? If users must use part of the product early, deliver in increments.
  • Can it be delivered in parts? A one-time data migration pushes that part towards sequential delivery.
  • How costly is failure? Regulated or safety-critical products need formal, traceable test documentation in any model, including for every increment.
  • Models can be combined: a payment back end integrated with a bank may be built and tested sequentially while the mobile app on top grows in increments.

Try it: Risk-Based Test Generator Try it: Acceptance Criteria Generator

Common mistakes

  • Using "iterative" and "incremental" as synonyms: added pieces need regression testing of earlier increments, reworked versions need re-testing of changed features.
  • Waiting for the test phase in a sequential project instead of reviewing requirements and designing tests early.
  • Testing only an increment’s new features. Defects often appear where a new increment touches old data or flows.
  • Writing detailed step-by-step test cases for a prototype that will be redesigned next cycle.
  • Trusting the label instead of the practice: a team that "does agile" may release once a year. Ask how often working software actually reaches testers and users.

The QA perspective

On a new project, ask: When will the first testable build exist? How often does working software reach users? How stable are the requirements? What must be true before work counts as done? Record the answers in the test plan or the team’s working agreement; they shape the test approach.

Then adapt: in a sequential project, invest early in requirement reviews and traceability; in an iterative or incremental project, plan each increment’s testing with it, keep a living regression suite and automate repeated checks. Raise the risks a model creates with a concrete consequence, such as "three features share one two-week test window", so the product owner decides instead of being surprised.

Practice exercise

Choose a model for two projects and plan the testing

Your task

Project A: the finance system must produce a monthly report in a new format published by a regulator. The format is fixed, the deadline is six months away, the change ships once and an external auditor will check it. Project B: a coffee chain wants a mobile app with order-ahead, loyalty points and a store locator in customers’ hands within two months, and expects to change features based on usage.

Recommend a model family, or a combination, for each project and describe how testing would be organised.

Steps
  1. Note the context: requirement stability, need for early feedback, delivery in parts, cost of failure.
  2. Choose a model family for each project and give one reason.
  3. Describe when static and dynamic testing happen and how detailed the documentation is.
  4. Name the main testing risk and one counter-measure.
Show the model answer
Model answer

Project A: fixed requirements, one delivery and an auditor point to a sequential model, often in V-model style. Review the specification against the regulator’s format first, then design test cases for every field and rule, traced to the specification, with early test data: a month with no transactions, maximum values, rounding. Dynamic testing runs at system and acceptance level; documentation is formal because the auditor reads it.

Project A risk: execution comes late and an overrun shrinks the test window. Counter-measures: agree exit criteria and a protected test window in the test plan, and ask for the calculation logic to be delivered and tested first.

Project B: uncertain requirements and the need for early feedback point to iterative and incremental development, for example with Scrum: order-ahead first, then loyalty, then the locator. In each increment, acceptance criteria are reviewed before development, new features are tested with exploratory testing, and documentation stays light.

Project B risk: increments interact, since points are earned on orders and a cancelled order must remove its points. Counter-measure: automate the core order checks in increment 1 and add order-and-points scenarios to the regression suite in increment 2.

Frequently asked questions

What is the difference between iterative and incremental development?

Incremental development adds the product in pieces, each finished and usable; iterative development builds a version and refines it in repeated cycles. For testing, incremental work needs regression testing of earlier increments, while iterative work means re-testing features whose design changed. Most agile teams use both together.

Is Agile a development model?

Not a single one. Agile is a set of values and principles described in the Manifesto for Agile Software Development. Methods that follow it, such as Scrum, usually organise work as iterative and incremental development. CTFL v4.0 lists Scrum, Kanban, extreme programming (XP) and similar approaches as methods and practices that describe development activities in more detail.

Is the V-model sequential or iterative?

Sequential. The V-model pairs each development level with a test level and starts test analysis and design for a level during the matching development phase, but test execution still happens after the code exists, and the product is delivered at the end.

Can a tester choose the development model?

Usually not: the organisation or the project lead decides. The tester’s job is to understand the model, adapt the test approach to it and report the testing risks it creates, with a concrete consequence and a proposed counter-measure.

References

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
  • ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
  • Manifesto for Agile Software DevelopmentThe Agile Manifesto authors · 2001The four values of agile software development, such as working software over comprehensive documentation and responding to change over following a plan.
  • The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020The definition of Scrum: its accountabilities, events and artifacts, including the Definition of Done that testing helps meet.
Tools

Practise with Mutqan tools

Requirements → Test Cases

Convert a list of numbered requirements into traceable test cases with a requirement-to-test matrix.

Test Design

Risk-Based Test Generator

Score features by likelihood and impact, then generate a prioritised risk-based test plan.

Test Design

Go deeper

Your progress on this topic

Part of the QA Roadmap

Before this topic