Lesson 0002: Mapping Test Timing with V/W/H Models in the Software Lifecycle

Software Development Life Cycle (SDLC)

The classic SDLC consists of seven phases, each with typical deliverables and effort distribution:

1. Requirement Analysis – research user needs, business goals and constraints. Deliverable: PRD (Product Requirement Document). Typical effort: 10‑15%.

2. System Design – architecture, database and API design. Deliverable: Design Document. Typical effort: 10‑15%.

3. Implementation (Coding) – write code and unit tests. Deliverable: Source code, runnable program. Typical effort: 30‑40%.

4. Testing – integration, system and acceptance testing. Deliverable: Test report, defect list. Typical effort: 15‑25%.

5. Deployment – release to production and configure monitoring. Deliverable: Online service. Typical effort: 5‑10%.

6. Operations – monitoring, bug fixing and performance tuning. Deliverable: Stable running system. Effort: continuous.

7. Retirement – decommission, data migration and archiving. Deliverable: Decommission report. Effort: one‑off.

Software Testing Life Cycle (STLC)

STLC runs in parallel with SDLC and contains six dedicated testing phases:

1. Requirement Analysis – analyse testability and identify test requirements. Deliverable: Test Requirement Document.

2. Test Planning – define test strategy, resources, schedule and risks. Deliverable: Test Plan.

3. Test Case Design – design concrete test scenarios and cases. Deliverable: Test Case Set.

4. Test Environment Setup – prepare test data, tools and environment. Deliverable: Usable Test Environment.

5. Test Execution – run tests, record results and report bugs. Deliverable: Test Execution Report.

6. Test Evaluation – assess coverage, quality and release recommendation. Deliverable: Test Summary Report.

V‑Model

Proposed in the 1980s, the V‑Model pairs each development phase with a corresponding testing phase, emphasizing a one‑to‑one relationship between artifacts and test levels. Core values:

Early test design – unit tests are designed before coding.

Clear responsibilities – each role knows what to develop and what to test.

Limitations:

Sequential waterfall style; lacks iteration.

Unsuitable for projects with frequently changing requirements.

W‑Model

The W‑Model evolves the V‑Model by running testing activities in parallel with development. Each development stage is verified (V) and validated (V) – verification checks correctness of the artifact, validation checks that it meets the previous stage’s requirements.

Key differences compared with the V‑Model:

Test timing : V‑Model tests after development; W‑Model tests alongside development (Shift‑Left).

Bug‑fix cost : V‑Model discovers bugs late (high cost); W‑Model discovers early (low cost).

Suitable scenario : V‑Model fits small, stable‑requirement projects; W‑Model fits medium‑to‑large projects with changing requirements.

H‑Model

The H‑Model treats testing as completely independent from development. Testing can start as soon as a “test‑ready point” is reached, without waiting for the whole feature to be finished. Core values:

Test independence – testing is not a subsidiary of development.

Supports multiple iterations – each module can be tested independently.

Fits continuous delivery pipelines (CI/CD).

Shift Left & Shift Right

Requirement → Design → Coding → Test → Deploy → Ops
↑                                 ↑
Shift Left                     Shift Right

Shift Left (early testing)

Testing activities should be introduced as early as possible because the earlier a defect is found, the lower the fix cost.

IBM Systems Sciences Institute data (classic):

Requirement phase – fix cost 1× (baseline).

Design phase – fix cost 5×.

Coding phase – fix cost 10×.

Testing phase – fix cost 50×.

Production phase – fix cost 200×.

Typical Shift‑Left practices:

Participate in requirement reviews to catch issues early.

Review API and database designs.

Write unit tests before code (TDD) and practice pair programming.

Run automated tests on every commit (continuous integration).

Shift Right (testing in production)

Testing should continue after release. Netflix’s Chaos Monkey is a classic example.

Typical Shift‑Right practices:

Canary release – expose new version to 1 % of users first.

Gray‑scale rollout – gradually increase exposure.

A/B testing – compare two versions in production.

Chaos engineering – inject faults deliberately (e.g., Netflix).

Production monitoring + alerts.

Real‑User Monitoring (RUM).

Example: Login Feature Test Design

Using the three models for a hypothetical login feature in the TaskFlow app:

V‑Model:
Requirement Analysis → Acceptance Test (Can user log in?)
System Design → System Test (Is login API correct?)
Detailed Design → Integration Test (DB read/write?)
Coding → Unit Test (Password encryption?)

W‑Model:
Requirement Analysis – V&V –> Acceptance Test Design
System Design – V&V –> System Test Design
Detailed Design – V&V –> Integration Test Design
Coding –> Unit Test
Then: Unit → Integration → System → Acceptance (parallel with development)

H‑Model:
Whenever a test‑ready point appears (e.g., API spec published, UI ready, DB ready) start the corresponding test without waiting for the whole feature to finish.

TaskFlow Lifecycle Flowchart – Practical Exercise

Create a lifecycle document:

cd taskflow
touch docs/testing/01-lifecycle.md

Add Mermaid diagrams to docs/testing/01-lifecycle.md:

# TaskFlow Test Lifecycle

## V Model View
```mermaid
flowchart LR
    A[Requirement Analysis] --> B[System Design]
    B --> C[Detailed Design]
    C --> D[Coding]
    D --> E[Unit Testing]
    C --> F[Integration Testing]
    B --> G[System Testing]
    A --> H[Acceptance Testing]
    E -.->|Regression| I[Continuous Testing]
    F -.->|Regression| I
    G -.->|Regression| I
    H -.->|Regression| I
```

## W Model View
```mermaid
flowchart LR
    A1[Requirement Analysis] -- V&V --> A2[Acceptance Test Design]
    B1[System Design] -- V&V --> B2[System Test Design]
    C1[Detailed Design] -- V&V --> C2[Integration Test Design]
    D1[Coding] --> D2[Unit Test]
    A2 --> H[Acceptance Test]
    B2 --> G[System Test]
    C2 --> F[Integration Test]
    D2 --> E[Unit Test]
```

## H Model View
```mermaid
flowchart TD
    Ready[Test Ready Point] --> Plan[Test Plan]
    Plan --> Exec[Test Execution]
    Exec --> Eval[Test Evaluation]
    Eval -.->|Improve| Plan
```

Commit the changes:

git add .
git commit -m "Lesson 0002: Add TaskFlow test lifecycle flowchart"

TaskFlow Stage Definition (Enterprise‑grade Template)

Each SDLC stage is expressed with entry criteria, exit criteria (Definition of Done), test activities, deliverables, owners and typical time share.

Stage 1 – Requirement Analysis

Entry : New requirement proposed, story ID assigned.

Exit : Requirement doc contains clear acceptance criteria, QA completes testability review, risks recorded, priority confirmed.

Test activities : Participate in requirement review, identify technical/business/compliance risks, confirm acceptance criteria.

Deliverables : Test requirement list, risk register.

Owner : PM (requirements) + QA (test perspective).

Time share : 10%.

Stage 2 – System Design

Entry : Requirement doc completed.

Exit : Architecture reviewed, API design conforms to standards, data model reviewed, testability considered (logs, monitoring points).

Test activities : Architecture review, API design review, data model review.

Deliverables : Design review record, draft API test cases.

Owner : Architect (design) + QA (testability).

Time share : 10%.

Stage 3 – Coding

Entry : Design passed review.

Exit : Code passes unit tests (coverage > 80%), code review, lint + static analysis error‑free, CI pipeline passes.

Test activities : TDD, code review, static analysis (e.g., SonarQube), unit testing.

Deliverables : Unit test code, code review record.

Owner : Development team.

Time share : 30%.

Stage 4 – Testing

Entry : Code completed (DoD).

Exit : All P0/P1 test cases passed, all P0/P1 bugs fixed, test report published, quality gate passed.

Test activities : Integration testing, system testing, end‑to‑end testing, performance testing, security testing.

Deliverables : Test report, bug list, quality assessment.

Owner : QA.

Time share : 20%.

Stage 5 – Deployment

Entry : Testing passed quality gate.

Exit : Smoke test passed, monitoring alerts configured, rollback plan ready.

Test activities : Smoke test after deployment, canary/gray‑scale rollout.

Deliverables : Deployment verification report, monitoring configuration.

Owner : Ops + QA.

Time share : 5%.

Stage 6 – Operations

Entry : Service live.

Exit : Continuous (no fixed exit).

Test activities : Production monitoring, chaos testing (periodic), real‑user monitoring, A/B testing.

Deliverables : Monitoring report, performance report.

Owner : Ops + QA.

Time share : Continuous.

AI Practice Prompts

These prompts can be fed to a generative AI to obtain ready‑to‑use Mermaid diagrams, test‑task tables or model recommendations.

Prompt 1 – Generate Mermaid diagrams for V, W and H models, compare them for a small SaaS product like TaskFlow, and recommend the most suitable model.

Prompt 2 – List test tasks for each development phase of TaskFlow in a table with columns: Phase, Action, Deliverable, Owner, Shift‑Left/Right label.

Prompt 3 – For a 5‑person team building a web app (TaskFlow) with 2‑week iterations and 3‑5 deployments per day, answer:
1) Which of V/W/H models fits best?
2) Why?
3) Specific implementation suggestions.
4) How to adjust when the team grows to 20 people?

QA Checklist

⬜ List the 5‑7 SDLC phases and their key deliverables.

⬜ List the 6 STLC phases.

⬜ Draw V, W and H models in a single diagram.

⬜ Explain the essence and value of Shift‑Left.

⬜ Explain the essence and value of Shift‑Right.

⬜ Choose the appropriate test model for TaskFlow.

⬜ Produce the TaskFlow lifecycle flowchart (including Mermaid code).

Thought Questions

Which test model does your current (or imagined) team use? V/W/H? What problems arise?

“The earlier you test, the better” – is this always true? Any exceptions?

Why does IBM data show that fixing a bug in production costs 200× the requirement‑phase cost? Do you trust this data?

If you were the test lead for TaskFlow with only one tester, would you prioritize Shift‑Left or Shift‑Right? Why?

V suits waterfall, W suits iterative, H suits CI/CD. Would you fuse the three? How?

Netflix’s Chaos Monkey is a classic Shift‑Right example, but some companies say “you cannot test in production”. What’s your view?

Recommended Reading

Books

Software Testing — Ron Patton (Chapter 2 covers SDLC and STLC).

Continuous Delivery — Jez Humble & David Farley (Chapter 4 discusses deployment pipelines, an engineering implementation of the H model).

How Google Tests Software — James Whittaker (Chapters 4‑6 detail Google’s test lifecycle).

Official Docs / Blogs

ISTQB Foundation Level Syllabus – Chapter 2 explains the test lifecycle.

Martin Fowler: Continuous Integration – seminal article closely related to the H model.

Martin Fowler: Continuous Delivery for ML – CD4ML perspective on test lifecycles.

Videos

“V‑Model vs W‑Model vs H‑Model in Software Testing” – YouTube (watch 2‑3 comparison videos for visual understanding).

Papers / Articles

“Shift Left Testing: Why It Matters” – searchable online; core Shift‑Left paper.

GitHub Projects

Mermaid CLI – convert Mermaid diagrams to PNG/SVG.