Applying the V-Model

Career Paths

How to interpret this table?

You may choose this advanced topic if you like doing the things listed under “they usually do”, and you are fine with not doing the things listed under “they usually do not do”.

Alternatively, you may choose it if you are interested in applying for the listed job roles and want to practice work that is close to those roles.

Job title	They usually do	They usually do NOT do	Real-life examples
Software Engineer (verification-focused)	Define requirements with corresponding tests, maintain traceability, verify each development level against its specification	Defer testing decisions, improvise tests late, or treat testing as a separate phase	Safety-critical systems, regulated software, test-driven environments
Quality / Test Lead	Plan verification and validation activities early, ensure test coverage matches specifications, enforce traceability	Write tests without clear requirements or accept unverified features	Embedded systems, enterprise software with formal QA

Affected SDLC Phases

If a team chooses this advanced topic, the planning, system design, implementation, and testing phases are tightly coupled. Each development activity on the left side of the V must have a corresponding verification activity on the right side. Testing is planned upfront, not added later.

Affected Tasks

Features are defined

Minimum Viable Product (MVP)

By the end of this task, your team has defined features together with corresponding acceptance criteria and test intentions.

Technical Details

For every feature, the team must define:
- Functional requirements
- Corresponding acceptance or system tests

Requirements without planned verification are not allowed. Each feature must explicitly state how it will be validated later.

Quality

High-quality feature definitions show clear one-to-one mapping between requirements and tests.

Features are sorted by priority

Minimum Viable Product (MVP)

Your team prioritizes features together with their verification effort.

Technical Details

Priority decisions must consider not only implementation effort but also testing and validation complexity.

Quality

High-quality prioritization reflects realistic test and verification costs.

Features' cost and price are estimated

Minimum Viable Product (MVP)

Your team estimates cost including implementation and verification activities.

Technical Details

Estimates must explicitly include test design, test implementation, and verification effort.

Quality

High-quality estimates do not underestimate testing and validation work.

System is working

Minimum Viable Product (MVP)

By the end of this task, your team demonstrates a working system together with executed tests that verify the implemented features.

Technical Details

The demo must show:
- Implemented features
- Corresponding tests being executed
- Test results confirming correct behavior

Manual or automated tests are acceptable, but they must trace back to feature definitions.

Quality

High-quality demos make verification visible and traceable, not implicit.

Bug fixing

Minimum Viable Product (MVP)

During development, your team reports and fixes one defect by updating both implementation and corresponding tests.

Technical Details

The bug report must reference:
- The violated requirement
- The failing test
- The fix and re-executed verification

Fixes without updated verification are not acceptable.

Quality

High-quality bug fixing maintains traceability and strengthens the verification chain.

User documentation

Minimum Viable Product (MVP)

User documentation reflects verified system behavior.

Technical Details

Documentation must align with validated features and tested behavior.

Quality

High-quality documentation avoids describing unverified or hypothetical functionality.

Developer documentation

Minimum Viable Product (MVP)

Developer documentation explains requirement-to-test traceability.

Technical Details

Documentation must describe:
- How requirements map to tests
- How verification is maintained across changes

Quality

High-quality documentation makes the V-Model structure explicit and auditable.