Key takeaways
- Verification asks "are we building it right?" and catches problems in specs, designs, and code before software runs. Validation asks "did we build the right thing?" and catches problems by running software.
- Verification is checking the blueprint. Validation is living in the house. You need both because a perfect blueprint can still produce a house nobody wants to live in.
- In modern CI/CD, clean separation between two breaks down. Both happen continuously, often in the same pipeline, and most teams do both without using these terms.
Verification is any activity that reviews whether a work product (a requirement, a design, a piece of code) conforms to its specification, without executing software. Code reviews, design inspections, requirements walkthroughs, static analysis, and linting are all verification.
Validation is any activity that confirms finished software meets the user's actual needs by executing it. Unit tests, integration tests, E2E tests, user acceptance testing, and beta testing are all validation.
Barry Boehm framed it in 1979 as two questions: verification asks "are we building products right?" and validation asks "are we building the right product?" That framing is in every textbook and every interview answer. It's correct but abstract. The useful part is seeing what each one looks like for a real feature.
What both look like for same feature
Take a mobile checkout flow as an example. Here's how verification and validation apply at each stage.
Requirements phase
- Verification: reviewing PRD to check that payment requirements cover all card types (Visa, Mastercard, Amex, RuPay), all error states (declined, expired, insufficient funds), and retry logic. This is a document review, not code execution.
- Validation: not possible yet. There's no software to run.
Design phase
- Verification: inspecting API contract to confirm payment endpoint accepts fields mobile app will send. Reviewing Figma mockups to confirm error states have UI designs. Checking that database schema supports order statuses flow requires.
- Validation: still not possible. No running code.
Implementation phase
- Verification: code review on pull request. Static analysis flagging an unhandled null case in payment response parser. A linter catching that API response model doesn't match the documented contract.
- Validation: unit tests running against payment calculation function. Integration tests confirming app talks to payment gateway correctly. Both involve executing code.
Testing phase
- Verification: reviewing test cases against requirements checklist to confirm all specified scenarios are covered (this is traceability, and it's a verification activity).
- Validation: running checkout flow end-to-end on a real device. Completing a purchase with a test card. Checking that confirmation screen shows correct order details. This is execution-based testing.
Post-release
- Verification: doesn't apply. The artifacts are already in production.
- Validation: monitoring crash-free rates, tracking user-reported payment failures, running A/B tests to see if checkout conversion rate meets business targets.
The pattern: verification happens before or without running software. Validation requires running it.
Where clean boundary breaks down
The verification/validation distinction was defined in an era of waterfall development. Design was done, reviewed (verified), locked, then implemented, then tested (validated). Clean phases, clean handoffs.
In CI/CD, both happen on every commit:
- A developer pushes code. The linter runs (verification). Unit tests run (validation). Both finish in 90 seconds. The PR is auto-blocked if either fails.
- A code reviewer reads diff (verification) and runs the branch locally to check behavior (validation). Same person, same session, both activities.
- A static analysis tool scans for security vulnerabilities (verification). An integration test hits the staging API to confirm endpoint works (validation). Both run in the same CI pipeline.
In practice, most teams don't say "we're doing verification now" or "we're doing validation now." They say "code review," "linting," "testing," "monitoring." The V&V terminology shows up in three places:
- Interview questions
- Compliance audits (ISO 13485 for medical devices, DO-178C for aviation software, IEC 62304 for healthcare)
- ISTQB exam prep
If your team works in a regulated industry, distinction matters for documentation. You need to show auditors which activities were verification and which were validation. If you're building a mobile app without regulatory requirements, you're likely doing both already. You just don't label them.
Why skipping either one is expensive
Skipping verification means nobody reviews spec, design, or code before it runs. Bugs that could have been caught by reading a document make it into codebase. They get caught later during testing, but by then fix costs more:
- A misunderstood requirement caught during a requirements review costs one meeting to fix
- The same misunderstanding caught during testing costs a code change, a re-test cycle, and a potential sprint delay
- Caught in production, it costs a hotfix, an app store release, and user-facing impact
Industry data from IBM and NIST consistently shows that defects found in the requirements phase cost 10-100x less to fix than the same defects found in production.
Skipping validation means nobody runs software before shipping it. The design looks right. The code passed review. But nobody tested whether checkout flow actually works on a Samsung Galaxy A14 with 3GB RAM on Android 13. The API contract matches spec, but payment gateway returns a 503 under load and the app shows a blank screen instead of an error message.
Verification confirms the plan is correct. Validation confirms plan survived contact with reality.
What this looks like for mobile QA specifically
Mobile adds layers that make both verification and validation harder.
Verification gets harder because:
- Mobile apps have platform-specific design guidelines (Material Design for Android, Human Interface Guidelines for iOS). Verifying compliance means a separate review per platform.
- API contracts need to account for mobile-specific concerns: smaller payloads for slow connections, graceful degradation when a field is missing, backward compatibility for users who haven't updated app.
- Permission models differ between Android and iOS. Verifying that spec handles both, and handles permission denials gracefully, is mobile-specific review work.
Validation gets harder because:
- The same code runs on thousands of device/OS combinations. A checkout flow that passes validation on a Pixel 8 might fail on a Redmi Note 12 because of a manufacturer-specific keyboard behavior.
- Mobile-specific failure modes (app backgrounded during payment, network switch from Wi-Fi to cellular, push notification permissions denied) don't exist in web testing.
- Emulators don't reproduce all device behaviors. Validation on emulators misses bugs that only appear on physical hardware: camera integration, biometric auth edge cases, HEIF image handling on iPhones.
Drizz covers the validation layer for mobile. Tests are written in plain English, run on real Android and iOS devices, and use Vision AI to interact with the screen. The validation step runs against what user actually sees, on hardware the user holds, instead of against a code-level abstraction on an emulator.
FAQ
What is the difference between verification and validation?
Verification reviews artifacts without running software. Validation runs software to confirm it works.
Is testing verification or validation?
Execution-based testing (unit, integration, E2E) is validation. Reviewing test cases against requirements is verification.
Which comes first, verification or validation?
Verification starts earlier (during requirements and design). Validation starts when there's running code.
Do you need both verification and validation?
Yes. Verification catches spec-level mistakes before coding. Validation catches behavior-level bugs after coding.
What is an example of verification vs validation?
Verification: reviewing an API contract for missing fields. Validation: calling API and checking response.
