Calling a build “DVT” does not make the design validated. If the enclosure is still changing, the Android image is an engineer build, and the test fixtures do not exist, the label only hides unresolved work.
EVT, DVT, and PVT are decision gates. Each build should answer a different set of questions, use a controlled baseline, and finish with evidence strong enough to release the next investment. The exact names vary between companies, but the discipline should not.
Give each phase one primary job
Engineering Validation Test proves that the architecture works and exposes the design changes needed. Design Validation Test proves the intended design meets product requirements across tolerance and environment. Production Validation Test proves the factory can build and test that design repeatedly.
| Phase | Primary question | Typical hardware state | Software state | Exit evidence |
|---|---|---|---|---|
| EVT | Does the architecture work? | Early custom boards, prototype mechanics, accessible test points | Bring-up BSP and functional application | Interfaces demonstrated, major risks understood, change list approved |
| DVT | Does the design meet requirements? | Production-intent PCB, enclosure, display, cables, power, antennas | Release-candidate BSP and application | Compliance, environmental, reliability, and system tests passed |
| PVT | Can the factory build it repeatedly? | Released BOM, drawings, tooling, fixtures, packaging | Controlled production image and provisioning | Yield, cycle time, traceability, and outgoing quality accepted |
Do not turn the table into a rigid calendar. A product may need EVT1 and EVT2, or a focused DVT rebuild after an antenna change. The correct gate depends on evidence, not the number of units already purchased.
Prepare EVT to learn quickly
EVT units should be instrumentable. Keep access to serial console, current measurement, storage logs, display signals, and critical rails. Add zero-ohm options, matching networks, and test pads where uncertainty remains. A beautiful sealed enclosure is less useful than a board that explains its failures.
Bring up power and boot before integrating every peripheral. Then work through display, touch, storage, USB, serial buses, audio, cameras, networking, suspend/resume, thermal sensors, and update/recovery. Track every deviation from the requirement matrix.
Use the real Android application early. A synthetic CPU test will not reveal GPU composition, database writes, USB permission behavior, or the timing between scanner and UI. The Android SBC development workflow gives a useful sequence from board bring-up to integrated product testing.
EVT should close architectural risks: SoC and memory margin, BSP viability, display interface, power tree, thermals, radio location, storage endurance, and recovery. Cosmetic defects can wait. A missing kernel driver or unstable panel link cannot.
At exit, create a controlled list of changes for the next revision. Classify each as required, optional, or deferred, with an owner and verification method. Untracked rework is how EVT lessons disappear.
Make DVT production-intent
DVT is where the product should stop depending on lab exceptions. Use the intended PCB stack-up, components, panel and touch assembly, cables, connectors, antenna, thermal interface material, fasteners, adhesives, coatings, and power adapter. If a substitute is unavoidable, record what result it prevents you from claiming.
Freeze a release-candidate Android baseline with exact bootloader, kernel, vendor image, system image, application, configuration, and signing keys. “Latest build” is not traceable. Give every unit a serial number linked to its hardware revision and image.
The DVT plan should trace back to requirements and cover normal use, rated boundaries, foreseeable misuse, and recovery.
| DVT area | Example evidence |
|---|---|
| Functional | Every interface and product workflow passes with production peripherals |
| Performance | UI latency, boot time, transaction time, video, and network meet targets |
| Power and thermal | Peak and steady power, maximum ambient soak, touch temperature, throttling |
| Environmental | Temperature, humidity, vibration, drop, ingress, or chemical exposure as required |
| EMC and radio | Emissions, immunity, ESD, antenna performance, and required regulatory pretests |
| Reliability | Reboot cycling, connector life, power interruption, storage and long-duration operation |
| Security | Production build, verified boot, key handling, update signing, debug lockdown |
| Service | Recovery, logs, replacement procedure, and technician access |
Failures are expected; unexplained passes are more dangerous. Record setup, unit, software, instruments, raw data, photos, and disposition. After a fix, rerun the original test and the adjacent functions that the change could affect.
The fanless thermal design guide and Android OTA guide provide deeper validation cases that belong in many DVT plans.
Enter PVT only with controlled inputs
PVT is not the place to discover that the factory cannot flash the signed image or that a cable needs hand shaping. Release the BOM, approved vendor list, Gerbers and assembly data, mechanical drawings, torque values, work instructions, test limits, packaging, labels, and software package before the build.
Build through the intended line with intended operators. Engineering can observe, but should not quietly rework every difficult station. Measure first-pass yield, retest yield, cycle time, defect pareto, fixture repeatability, provisioning time, and operator feedback.
The production test should catch likely manufacturing faults without repeating the entire DVT suite. It may verify rails, memory and storage identity, display and touch, radios, USB and serial ports, audio, camera, secure identity, software version, and final kiosk or application launch. Choose limits from DVT data and component tolerance rather than from one golden unit.
Keep a small number of known-good and known-bad fixtures or fault samples. A fixture that only ever sees passing units can drift unnoticed.
Treat Android software as manufactured material
The software load has version, origin, processing steps, and acceptance criteria just like a PCB. Hash the released package. Control signing access. Record which unit received which image and provisioning result.
Separate factory access from field access. PVT may need fastboot, ADB, serial console, or a test application, but the shipped unit should leave the line in its production state. The final station must verify that debug policy, device identity, update channel, and customer configuration are correct.
Test interrupted flashing and failed provisioning. Define quarantine and rework paths that do not encourage operators to improvise. The ADB and debug lockdown guide covers the handoff from factory access to the sealed product.
Use change control after every gate
A late change can invalidate earlier evidence. Changing a regulator may affect EMC and thermals. Changing plastic resin can affect antenna performance. Changing the panel can affect power, timing, optical quality, and touch noise. Changing eMMC can affect boot and update time.
For each engineering change, list affected requirements and tests. Decide whether the result needs analysis, a focused regression, or a full rerun. This impact assessment is more useful than a blanket rule that every change restarts the entire program.
Maintain an as-built record for each build phase. The procurement checklist should connect approved parts and supplier notifications to this same record.
Exit criteria should be measurable
Before a build starts, agree on allowed open issues. A reasonable gate might require zero unresolved safety or security defects, zero failures against mandatory product requirements, approved dispositions for cosmetic defects, and stable yield above a defined threshold. The numbers depend on product and risk; the important point is deciding them before schedule pressure arrives.
Hold a formal review with hardware, mechanical, software, test, quality, manufacturing, sourcing, and product owners. Record the decision and conditions. “Ship unless someone objects” is not a gate.
Frequently asked questions
How many units are needed for EVT, DVT, or PVT?
There is no universal count. The sample size must cover design variation, destructive tests, multiple suppliers or cavities, software scenarios, and confidence in yield. Let the test matrix and risk drive quantity.
Can compliance testing wait until PVT?
Final certification may use production units, but pre-compliance work belongs earlier. Discovering emissions, ESD, or radio failure after tooling and line release is expensive.
Should software be frozen during DVT?
Use a controlled release candidate. Fixes will occur, but each build must be traceable and relevant tests rerun. Testing an unidentified moving target produces weak evidence.
Bottom line
EVT learns whether the architecture works, DVT proves the design, and PVT proves the process. Give each phase a controlled baseline, written exit criteria, and traceable evidence. A build is ready to advance when its unanswered risks are appropriate for the next gate, not when the calendar says the phase is over.