Did the implementation meet the specification?
Evidence compares the artifact against explicit requirements, interfaces and constraints.
Side 128
Verification & Validation
Two questions kept separate: did we build the thing according to specification, and is the resulting thing actually suitable for the intended use?
requirement→implementation→verification→validation→evidence
04lenses
16working concepts
V0content
SS-1.0standard
Verification and validation answer different questions.
Collapsing them creates systems that are internally correct but externally useless—or useful by accident without reliable conformance.
Does the artifact work for the intended use?
Evidence compares system behavior with real goals, users and operating conditions.
A bad requirement can be perfectly implemented.
Ambiguous, incomplete or misdirected requirements shift failure upstream.
Fitness depends on environment and stakes.
A system validated in one setting may not generalize to another.
Different claims require different test evidence.
Inspection, analysis, simulation and testing reveal different failure classes.
Examine artifacts without executing them.
Reviews can catch omissions, inconsistencies and noncompliance early.
Use models or proofs to evaluate properties.
Formal reasoning is strongest when assumptions are explicit and tractable.
Exercise models under controlled scenarios.
Simulation expands coverage while inheriting model limitations.
Observe the implemented system under chosen conditions.
Tests provide direct evidence but cover only sampled cases and environments.
Evidence should connect back to the claim it supports.
Traceability turns a pile of tests into an auditable argument about requirements.
Link each requirement to implementation and evidence.
Unmapped requirements reveal gaps before deployment.
Ask what has actually been exercised.
Coverage metrics are useful indicators but are not substitutes for meaningful test design.
Track which evidence becomes stale after modification.
A small implementation change can invalidate assumptions in distant parts of the system.
Know exactly what version was tested.
Uncontrolled versions make successful validation difficult to reproduce.
Good validation tries to break the intended use case.
Edge cases, adversarial conditions and real users expose assumptions hidden by happy-path testing.
Test limits and transitions.
Failures often cluster around thresholds where modes or assumptions change.
Observe plausible wrong use.
Robust systems anticipate foreseeable operator behavior rather than assuming ideal interaction.
Vary operating conditions.
Load, noise, latency, temperature, incentives or social context can change behavior.
Document what remains untested or unresolved.
Validation supports a decision; it does not eliminate uncertainty.
Passing tests does not prove fitness for purpose. Verification asks whether the artifact conforms to specified requirements; validation asks whether those requirements and the resulting artifact solve the real problem.