Testing Throughout the SDLC
See how testing maps to every phase of the software lifecycle, from Waterfall’s V-Model to Agile shift-left. Master the four test levels and four test types.
Testing Throughout the SDLC video walkthrough
A guided overview of chapter 2, connecting the exam language to practical testing decisions.
Briefing focus
Testing isn’t a phase — it’s everywhere
This is a structured lesson briefing. Real video/audio can be added later as a media source.
Estimated time
8 min
- 1Testing isn’t a phase — it’s everywhere
- 2The four test levels
- 3Four test types you must recognise
- 4Maintenance testing
Transcript brief
See how testing maps to every phase of the software lifecycle, from Waterfall’s V-Model to Agile shift-left. Master the four test levels and four test types. The walkthrough introduces the core concept, works through a realistic project example, and closes with the mistakes learners most often make in quiz and exam questions.
Key takeaways
- Recognise the exam wording for this chapter.
- Apply the concept to a real software delivery situation.
- Know which detail to check first when a scenario question feels ambiguous.
Testing isn’t a phase — it’s everywhere
Whether your team runs Waterfall, V-Model, incremental or Agile, testing activities exist in every phase of the SDLC. The classic V-Model illustrates this perfectly: every left-hand development phase has a right-hand test level that validates it.
The four test levels
| Level | Focus | Who usually runs it | Typical tools |
|---|---|---|---|
| Unit / Component | A single module in isolation | Developer | JUnit, Jest, pytest, xUnit |
| Integration | Interfaces between components | Developer / SDET | REST-assured, Karate, Postman |
| System | The complete integrated system | Test team | Playwright, Cypress, Selenium |
| Acceptance | Fit-for-purpose against user needs | Business / end-user | BDD (Cucumber, SpecFlow), UAT scripts |
Real-life scenario · Healthcare
NHS prescription service rollout
Situation. An NHS Digital team built an e-prescription service. Unit tests (by devs) covered the dose-calculation engine. Integration tests (by SDETs) validated the GP-to-pharmacy message flow against a simulator. System tests (by QA) ran Playwright end-to-end journeys on realistic data. Finally, a UAT cohort of 30 GPs ran acceptance tests with real patient stories in a pre-prod environment.
Lesson. Each level answered a different question — from ‘Is this function correct?’ to ‘Can a real GP prescribe safely?’ Skipping a level leaves a risk gap.
Four test types you must recognise
- Functional testing — ‘Does the system do what it should?’ Based on specifications and user stories.
- Non-functional testing — ‘How well does it do it?’ Covers performance, security, reliability, usability, compatibility.
- White-box (structural) — derived from internal code structure; measured in statement/branch coverage.
- Change-related testing — re-testing (confirmation) fixes + regression to ensure nothing else broke.
Regression ≠ Re-test
Confirmation testing verifies the specific fix works. Regression testing verifies the fix did not break anything else. The exam frequently tests this distinction.
Maintenance testing
Once a system is live, testing does not stop. Every change triggers maintenance testing, driven by an impact analysis that identifies affected areas.
| Trigger | Type | Example |
|---|---|---|
| Defect fix | Corrective | Hotfix a login 500 error |
| Environment change | Adaptive | Migrate database from PostgreSQL 14 → 16 |
| Enhancement | Perfective | Add dark-mode toggle for accessibility |
| Avoiding future issues | Preventive | Refactor legacy auth before it reaches end-of-life |
