01 — Start With Requirements
Don't Start With the Test Chamber
Before asking: What tests should we run?
ask: What must the product prove?
Requirements may involve:
Function
Performance
Accuracy
Latency
Power
Thermal
RF
EMC
Mechanical
Environmental
Reliability
Cybersecurity
Manufacturability
Serviceability
Tests Exist to Verify Requirements.
02 — Requirement Must Be Verifiable
Weak requirement: Product shall have good wireless performance.
Better requirement: Product shall meet the defined connectivity performance under specified operating conditions.
If Success Cannot Be Measured, the Requirement Is Not Ready for Validation.
03 — Requirement ID
Each important requirement should have a unique identifier.
Example conceptually:
Requirement Identity Creates Traceability.
04 — Requirement Source
Know whether the requirement came from:
customer
system architecture
regulatory requirement
internal engineering decision.
Every Requirement Should Have a Reason to Exist.
05 — Requirement Owner
Someone should understand: What This Requirement Means.
Otherwise test teams may interpret it differently.
06 — Requirement Traceability
A mature chain is: Customer Need → System Requirement → Subsystem Requirement → Design → Verification Method → Test Evidence
Requirement Should Remain Traceable to Reality.
07 — Verification Matrix
One of the most important project documents should be a: Requirements Verification Matrix or equivalent traceability matrix.
Potential columns:
ID | Requirement | Verification Method | Stage | Configuration | Acceptance Criteria | Result | Evidence | Status |
This Turns Testing Into Requirement Closure.
08 — Verification Method
Not every requirement requires a physical test.
Typical engineering verification methods include:
Analysis
Engineering calculation / simulation.
Inspection
Examine implementation or documentation.
Demonstration
Show required function under defined conditions.
Test
Measure performance using defined stimulus and equipment.
Choose the Verification Method That Produces Appropriate Evidence.
09 — Analysis
Examples may include:
tolerance analysis
SI simulation
thermal simulation
reliability calculation.
Analysis Can Verify What Is Difficult or Expensive to Measure Directly.
But it should use credible inputs.
10 — Inspection
Examples:
connector type
label
PCB revision
assembly feature.
Not Every Requirement Needs a Laboratory.
11 — Demonstration
Example: operator can complete defined workflow.
Some Requirements Are Proven Through Controlled Functional Demonstration.
12 — Test
Test applies: Known Input → Product → Measured Output
and compares it against: Acceptance Criteria.
13 — A Test Is an Engineering Experiment
Therefore define:
Purpose
Equipment
Configuration
Procedure
Inputs
Outputs
Acceptance
Data
Test Procedure Should Remove Ambiguity.
14 — Acceptance Criteria Before Test
Do not run the test and later decide: Looks good enough.
Define Pass / Fail Before Seeing the Result.
15 — Evidence
A green spreadsheet cell is not always sufficient evidence.
Evidence may include:
raw measurement
logs
waveform
report
configuration record.
Pass Should Be Auditable.
16 — Requirement Closure
Requirement status can progress: Open → Planned → Tested → Passed → Closed.
17 — Failed Requirement
Failure does not automatically mean: Project Failure.
It means: Engineering Has Found an Unclosed Requirement.
18 — Requirement Waiver
Sometimes a requirement changes legitimately.
Then use controlled:
deviation
waiver
requirement change
rather than pretending the failure passed.
Change the Requirement Honestly — Don't Change the Test Result.
19 — Verification vs Validation
For the 365PCB framework, use this simple distinction:
Verification
Did We Build the Product According to Defined Requirements?
Validation
Does the Product Actually Fulfill Its Intended Use and Customer Need?
Both matter.
20 — Verified but Not Validated
A product can perfectly meet its written specification and still: Solve the Wrong Problem.
That usually means: Requirement Failure Upstream.
21 — Validation Without Verification
A demo may impress the customer.
But without disciplined verification, engineering may not know: Why It Worked or Whether It Will Work Repeatedly.
22 — Qualification
Qualification generally asks: Can this design survive / perform against its defined qualification requirements?
It may involve:
environment
EMC
reliability
safety
depending on product.
23 — Certification
Certification is different.
Certification may require:
recognized standards
authorized laboratory
certification body
depending on market.
Internal Validation Does Not Automatically Equal Regulatory Certification.
365PCB should never blur these concepts.
24 — Compliance Readiness
A safer and more accurate ODM phrase is often:
until the applicable external certification process is completed.
25 — EVT / DVT / PVT Operational Model
365PCB should define the stages clearly:
EVT
Prove the Architecture and Major Engineering Functions.
DVT
Prove the Near-Final Product Against Its Requirements.
PVT
Prove That the Production System Can Repeatedly Build the Validated Product.
This is simple enough for customers to understand but technically correct enough for engineers.
26 — EVT
Engineering Validation Test
EVT asks: Does the Intended Architecture Work on Real Custom Hardware?
27 — EVT Is Architecture-Centered
EVT can focus heavily on:
electrical architecture
subsystem integration
physical implementation
early design margin.
EVT Is Where the Schematic, PCB, Firmware, Mechanics, and Physics Meet.
28 — EVT Is Not PVT
EVT units may still include:
extra test points
debug headers
rework
engineering firmware.
That can be acceptable.
EVT Optimizes Engineering Visibility.
29 — But EVT Must Be Controlled
Every EVT unit should still have identifiable:
hardware revision
BOM
firmware
rework state.
Experimental Does Not Mean Untraceable.
30 — EVT Entry Criteria
Before EVT, ideally major:
concept feasibility
architectural decisions
have already been investigated.
EVT Should Not Be the First Time Anyone Asks Whether the Product Concept Is Possible.
31 — EVT Sample Configuration
Record:
EVT Result Belongs to a Configuration.
32 — EVT Power Validation
Questions include:
Do rails start correctly?
Do they remain stable?
Does sequencing work?
Is transient behavior acceptable?
Power Is the Infrastructure of EVT.
33 — EVT Processor Bring-Up
Validate:
critical peripherals.
Prove the Compute Platform.
34 — EVT Memory
For:
DDR
LPDDR
high-speed memory
bring-up should validate actual board-level implementation.
Memory Datasheet Compatibility Does Not Prove PCB Compatibility.
35 — EVT Interfaces
Validate required:
USB
Ethernet
CAN
communication interfaces
according to product requirements.
Interface Presence Is Not Interface Performance.
36 — EVT High-Speed Channels
Where relevant:
evaluate:
physical channel behavior.
The First Custom PCB Is the First Real Manufactured High-Speed Channel.
37 — EVT SI
At demanding performance levels:
compare: Design Model
with: Manufactured Structure.
Simulation Should Begin Converging With Measurement.
38 — EVT PI
Validate:
voltage delivery
droop
noise
transient behavior
against subsystem needs.
Fast Silicon Exposes Weak Power Architecture Quickly.
39 — EVT Analog
Validate:
ADC behavior.
Precision Must Be Measured in the Complete Signal Chain.
40 — EVT Sensor
Validate:
Sensor
AFE
ADC
Mounting
Firmware
Measurement Performance Belongs to the Complete Product.
41 — EVT RF
Validate:
radio function
RF path
matching
initial antenna behavior.
RF Simulation Ends Where Manufactured Geometry Begins.
42 — EVT Antenna
Use increasingly representative:
nearby materials.
Antenna Qualification Without Product Environment Is Incomplete.
43 — EVT Firmware
Firmware should exercise: Real Hardware Architecture.
But product UI/cloud maturity does not necessarily need to be complete.
44 — EVT RTOS
Validate:
task architecture
timing
resource use
where relevant.
45 — EVT Linux
Validate:
hardware interfaces.
EVT Is a Hardware–Software Integration Gate.
46 — EVT AI
If Edge AI exists:
validate: Sensor Data → Runtime → Accelerator → Inference → Product Decision.
Model Accuracy Alone Is Not EVT AI Evidence.
47 — EVT Cybersecurity
Validate architectural foundations such as:
secure boot
identity
key storage
update path
according to project requirements.
Security Architecture Should Be Proven Before DVT.
48 — EVT Mechanical
Validate:
PCB fit
connector alignment
mounting
assembly.
CAD Must Become Physical Geometry.
49 — EVT Thermal
Validate:
cooling path.
EVT Should Tell Us Whether the Thermal Architecture Is Fundamentally Viable.
50 — EVT Instrumentation
Keep sufficient:
to explain behavior.
Early Validation Needs Observability.
51 — EVT Design Margin
Don't only prove: Nominal Function.
Start asking: How Close Are We to the Boundary?
52 — EVT Margin Exploration
Depending on the project, engineering characterization can examine defined variations in:
using qualified procedures.
Find Weak Margin Before DVT.
53 — EVT Failure Is Valuable
If EVT discovers: thermal architecture inadequate
that may save:
field failure.
Early Failure Can Be Successful Engineering.
54 — EVT Issue Review
Classify findings into:
Architecture Change
PCB ECO
Firmware Fix
Mechanical Fix
Process Issue
Measurement Issue
Different Mechanisms Need Different Corrective Actions.
55 — EVT Exit
EVT should not exit because: deadline arrived.
Exit should require enough evidence that: Major Architecture Risks Are Closed or Controlled.
56 — EVT Exit Criteria Examples
Could include project-specific closure of:
critical power
core processing
required interfaces
major RF
major thermal
basic mechanical
firmware architecture.
Gate Criteria Should Be Written Before the Gate Review.
57 — EVT Output
The output is not only: Rev B Files.
It is:
Design
Evidence
Issues
Decisions
Updated Requirements
EVT Creates the Foundation for DVT.
58 — DVT
Design Validation Test
DVT asks a much harder question: Does the Near-Final Product Meet Its Defined Requirements?
59 — DVT Is Product-Centered
EVT proves: Architecture.
DVT proves: Product.
60 — DVT Requires Higher Configuration Maturity
Ideally DVT is much closer to:
Production PCB
Production BOM
Production Mechanics
Production Firmware
Production Materials
Fidelity Matters.
61 — DVT Prototype Hack Problem
A product cannot claim qualification if every DVT unit has:
hand-added wires
special hidden fixes
engineering-only cooling
that production will not contain.
Validate What You Intend to Manufacture.
62 — Production-Representative Configuration
This is one of the most important page principles: The Evidence Must Match the Configuration.
63 — DVT Configuration Baseline
Freeze/identify:
HW
FW
Mechanical
BOM
Calibration
Security
Test Configuration
DVT Is Configuration-Controlled Evidence.
64 — DVT Requirement Matrix
At DVT, the verification matrix should become one of the main project-control tools.
For every product requirement: Where Is the Evidence?
65 — Requirement Coverage
If there are: 300 requirements
but only: 220 closed, the product does not magically become validated because the demo looked good.
Validation Completeness Is Traceability Completeness.
66 — Functional Validation
Test complete:
operating modes
state transitions
interfaces
error handling.
Happy Path Is Only One Product Path.
67 — Startup
Validate:
68 — Shutdown
Validate:
normal shutdown
persistence
state.
Product Lifecycle Includes Turning Off.
69 — Recovery
Validate responses to:
recoverable fault.
Robust Products Have Defined Error Behavior.
70 — Boundary Conditions
Test:
minimum
maximum
transitions
where required.
Many Failures Live at the Boundary.
71 — Performance
Measure:
throughput
latency
accuracy
response time
according to product.
"Works" Is Not Performance Evidence.
72 — Power Consumption
Validate:
Power Budget Becomes Product Evidence.
73 — Battery Product
If applicable, validate:
operating time
power states
charging behavior
through the appropriate qualified product program.
Battery Life Is a System Result.
74 — Thermal DVT
Verify required temperatures under:
intended workload
intended enclosure
intended ambient conditions.
DVT Thermal Should Use the Product That Will Actually Be Sold.
75 — Sustained Performance
Especially for:
AI
FPGA
High-Performance Compute
test long enough to expose: Thermal Equilibrium / Throttling.
76 — RF DVT
Validate final:
radio
antenna
enclosure
coexistence
performance.
RF Product = Radio + Antenna + Mechanics + Firmware.
77 — OTA DVT
Validate:
update
interruption recovery
rollback
compatibility
according to Page 33 architecture.
OTA Failure Paths Belong in DVT.
78 — Cybersecurity DVT
Validate requirements such as:
authentication
authorization
secure boot
update rejection
production debug policy.
Security Controls Need Negative Test Evidence.
79 — Mechanical DVT
Validate final:
interfaces.
Mechanical Validation Needs Production-Like Materials.
80 — Environmental Validation
Environmental testing should follow: The Real Deployment Environment.
Not an arbitrary list of impressive tests.
IEC 60068-1 explicitly provides a framework for tailoring environmental test specifications to expected transport, storage and operational conditions.
81 — Temperature
Where required:
validate behavior at relevant defined:
operating conditions through appropriate qualified testing.
Room Temperature Is One Point — Not an Environment.
82 — Humidity
For relevant products, high-humidity resistance may be evaluated using applicable methods; the current IEC steady-state damp-heat method is IEC 60068-2-78:2025.
Environmental Testing Should Use Current Applicable Methods.
83 — Thermal Cycling
Repeated thermal transitions may expose:
interconnect
seal
mechanical
weakness.
One Hot Test Is Not Thermal-Cycle Reliability.
84 — Vibration
Where required, vibration qualification should represent: Expected Mechanical Environment.
Current IEC 60068-2-6 provides the standard sinusoidal-vibration method for assessing mechanical weakness/degradation at defined severities.
85 — Random Vibration
Some real environments are stochastic rather than sinusoidal.
Choose the Test Because It Represents the Environment — Not Because It Sounds More Severe.
86 — Shock
Shock and vibration are different phenomena.
Qualification Plans Should Keep Them Conceptually Separate.
87 — Drop
Portable products may require: product-specific drop evaluation.
Orientation and construction matter.
88 — Ingress
If an IP claim is required:
validate: Final Enclosure Assembly
rather than housing plastic alone.
89 — Chemical
Products exposed to:
cleaners
oils
industrial agents
may require compatible material validation.
90 — UV
Outdoor products may require: Weather / UV durability evidence
according to relevant requirements.
91 — Corrosion
Applicable products may require corrosion-resistance evaluation.
Environment Follows Application.
92 — EMC DVT
EMC is a major DVT domain because the final:
PCB
Enclosure
Cable
Firmware
Clocking
exist together.
EMC Is a Product Property.
93 — Pre-Compliance
Before formal compliance testing, engineering pre-compliance can identify: High-Risk Failure Modes.
94 — Formal Compliance
Where applicable, final certification should use:
as required by market.
Don't Confuse Engineering Pre-Scan With Formal Certification.
95 — Safety
Electrical/product safety requirements should be validated under the applicable product-specific standard and qualified procedures.
Safety Requirements Must Be Defined From the Market and Product Category.
96 — Reliability
Reliability validation is not simply: run it for a few days.
It should ask: Which Failure Mechanisms Need Evidence?
97 — Reliability Model
Potential mechanisms include:
solder fatigue
connector wear
thermal cycling
material degradation
moving-part wear.
Reliability Is Failure-Mechanism Engineering.
98 — Accelerated Testing
Where justified, accelerated tests can compress selected stress/time relationships.
But: Acceleration Must Preserve Relevant Failure Physics.
99 — More Stress Is Not Automatically Better Testing
An unrealistic stress may create: Failure Mechanism the Customer Will Never See.
That generates bad engineering conclusions.
100 — Reliability Sample Size
One sample surviving does not define: Population Reliability.
Sample quantity should follow:
statistical objective.
101 — Multiple Units
DVT should use enough units to reveal relevant: Unit-to-Unit Variation.
102 — Unit Distribution
Board A: great.
Board B: great.
Board C: marginal.
That is engineering information.
Variation Is Part of Product Behavior.
103 — Corner Units
Where relevant, validate combinations reflecting likely worst-case:
component
manufacturing
environmental
variation.
Qualification Should Search for the Boundary.
104 — Component Tolerance
A product designed around nominal component values may fail: Real Component Distribution.
105 — Manufacturing Tolerance
Mechanical: fit
Electrical: impedance
Thermal: interface thickness
can all vary.
Manufacturing Variation Is Part of DVT.
106 — Supplier Variation
If multiple approved component suppliers exist: Are They Functionally Equivalent in the Product?
107 — Alternate BOM Validation
An alternate part should be: Validated Against the Requirements It Can Affect.
Not merely matched by datasheet table.
108 — Firmware Regression
Every major firmware release should re-verify affected functionality.
New Feature Should Not Break Old Product Behavior.
109 — Hardware Regression
PCB ECO may affect:
mechanics.
"Small" ECO Does Not Automatically Mean Small Validation Scope.
110 — Regression Matrix
For every change: Which Requirements Could Be Affected?
That determines: Re-Test Scope.
111 — Impact Analysis
Change: capacitor supplier.
Potential impact:
power transient.
Change Classification Should Be Engineering-Based.
112 — Full Requalification vs Targeted Revalidation
Not every ECO requires repeating every test.
But: Re-Test Scope Should Be Justified.
113 — Design Freeze
DVT should move toward a controlled: Production Candidate Baseline.
114 — Freeze Does Not Mean Never Change Again
It means: Changes Now Require Formal Control and Impact Analysis.
115 — DVT Failure Review Board
For significant projects, failed validation items deserve structured cross-functional review.
Ask:
Root Cause?
Risk?
Fix?
Re-Test?
Failure Decisions Should Not Be Made in Isolation.
116 — Deviation
Sometimes a unit/test deviates from procedure.
Record it.
An Unrecorded Deviation Weakens Evidence.
117 — Test Anomaly
Instrument glitch: ≠ product failure.
But: Prove the Difference.
118 — No-Test Result
If configuration was wrong: Invalidate the Result.
Don't force it into pass/fail.
119 — Test Repeat
Repeating a failed test until it passes without understanding the first failure is: Not Validation.
120 — Reproducibility
If failure is intermittent: Increase Investigation.
Intermittent failures are often more dangerous than obvious failures.
121 — Measurement System
A test result depends on:
Device
Fixture
Instrument
Method
Operator / Automation
Measurement Is a System.
122 — Measurement Confidence
The newly published ISO 10012:2026 specifically requires measurement processes and equipment to be managed so results are fit for purpose and support product conformity.
This gives us another strong website statement: You Cannot Validate a Tolerance More Precisely Than You Can Reliably Measure It.
123 — Calibration
Test equipment should have suitable:
calibration
status
traceability
for the intended measurement system.
Instrument Display ≠ Measurement Confidence.
124 — Resolution
Measuring a very tight requirement with: Coarse Instrument Resolution, creates false confidence.
125 — Accuracy
Resolution and accuracy are: Not the Same Thing.
126 — Repeatability
Same:
should produce sufficiently consistent results.
127 — Reproducibility
Different:
should not change the conclusion excessively.
Production Testing Needs Measurement Reproducibility.
128 — Fixture Variation
A loose connector in the fixture can create: False Product Failures.
129 — Contact Resistance
Test fixture contacts wear.
Production Test Equipment Ages Too.
130 — Golden Unit
A characterized reference unit can support:
fixture verification
station correlation.
But: Golden Unit Is a Check Tool — Not a Replacement for Calibration or Test Limits.
131 — Test Software Version
Test system software itself needs: Revision Control.
132 — DVT Report
A professional DVT report can summarize:
Requirement
Method
Configuration
Result
Evidence
Deviation
Status
A Report Should Make the Release Decision Explainable.
133 — DVT Exit
DVT exits when: Required Product Evidence Is Sufficient for the Agreed Release Gate.
Not when: most tests passed.
134 — Open Issues
Open issues should be categorized:
Blocker
Accepted Risk
Deferred
Requires PVT Closure
Nothing Important Should Disappear Between Meetings.
135 — Residual Risk
Even after DVT: Risk Never Becomes Zero.
Engineering identifies and manages: Remaining Risk.
136 — DVT Output
The output should include:
DVT Hands Evidence to PVT.
137 — PVT
Production Validation Test
Now the question changes completely: Can the Production System Repeatedly Build the Validated Product?
138 — This Is the Most Important Distinction
EVT: Product Architecture.
DVT: Product Design.
PVT: Manufacturing System.
139 — PVT Is Not Another Prototype Build
PVT should increasingly use:
Test the Factory That Will Build the Product.
140 — Production-Intent PCB
PVT should use the intended:
fab process.
Engineering Sample PCB Is Not Enough.
141 — Production BOM
Use: Approved Production Components.
142 — Approved Vendor List
If AVL exists: Production Must Use the Controlled Supply Chain.
143 — Production Firmware
Do not ship PVT units with:
unless explicitly part of the defined PVT configuration.
Software Is Manufacturing Configuration.
144 — Production Security State
For secure products:
verify:
production key
device identity
debug policy
secure boot state.
PVT Must Prove Security Can Be Manufactured.
145 — Production Mechanical Parts
Use intended:
where applicable.
PVT Mechanical Geometry Must Reflect Real Process Variation.
146 — Production Tooling
Now validate:
fixtures
jigs
assembly tools
programming tools.
Tooling Is Part of the Manufacturing System.
147 — Work Instructions
Operators should build from controlled: Documentation.
Not from: "Ask Engineer Zhang how he built the sample."
148 — Assembly Sequence
PVT verifies: Can the intended production sequence actually work?
149 — Operator Ergonomics
Repeated assembly may reveal:
difficult reach
awkward insertion
risk of damage.
Production Human Factors Matter.
150 — Cycle Time
A product that takes: 90 minutes
to build when business plan expects: 10 minutes
has a manufacturing-readiness problem.
151 — Takt / Throughput
Production capacity should align with: Demand Requirement.
152 — Bottleneck
Potential bottlenecks:
Programming
Calibration
Manual Assembly
Functional Test
Burn-In
Identify the Slowest Operation.
153 — Test Cycle Time
A 20-minute FCT can dominate: Line Capacity.
154 — Parallelization
Sometimes multiple fixtures/stations can improve capacity.
Manufacturing Architecture Is Capacity Architecture.
155 — Programming Time
Firmware size / interface speed can become: Manufacturing Economics.
156 — Calibration Time
A long manual calibration process may become production bottleneck.
Product Architecture Can Affect Factory Throughput.
157 — Yield
PVT begins answering: What Percentage of Units Build Correctly Through the Intended Process?
158 — First-Pass Yield
A key question: How Many Units Pass Without Rework?
159 — Final Yield
Final yield can look excellent after massive rework.
But: Rework Can Hide Process Instability.
160 — FPY Matters
A 99% final yield with:
signals a very different manufacturing system from 99% FPY.
161 — Defect Pareto
Rank major defects.
Fix the Largest Sources of Yield Loss First.
162 — Defect Mechanism
Don't stop at: solder defect.
Ask:
Printing?
Placement?
Reflow?
Design?
Material?
PVT Should Convert Defects Into Process Knowledge.
163 — Design Defect vs Process Defect
If all units fail: Design may be wrong.
If random units fail:
Process variation may dominate.
But investigate before assuming.
164 — Process Window
A good manufacturing process should have: Enough Margin Around the Nominal Setting.
165 — Narrow Process Window
If tiny process variation creates failure: Product May Not Be Ready for Scale.
166 — DFM Comes Back
PVT frequently reveals: Design Decisions That Make Manufacturing Unnecessarily Difficult.
This is why Page 39 follows immediately after this page.
167 — DFA
Does production assembly remain:
mistake-resistant?
168 — DFT
Does test architecture provide:
reasonable cycle time?
169 — Production Test Coverage
Test strategy should target:
Manufacturing Risks and Product Requirements.
Not simply test everything because a test exists.
170 — ICT vs FCT
Different methods detect: Different Failure Classes.
The right strategy depends on:
risk.
171 — Boundary Scan
Can support selected digital/high-density designs where architecture supports it.
Testability Should Be Designed Before PVT.
172 — Programming Verification
After programming: Confirm the Correct Image Was Written.
173 — Firmware Hash / Build ID
High-value systems may link each product to: Exact Software Configuration.
174 — Calibration Traceability
Unit-specific calibration should be linked to: Unit Identity.
175 — Serial Number
PVT should establish reliable unit serialization if required.
Physical Product Needs Identity.
176 — Production Traceability
Current IPC-1782B establishes risk-based traceability requirements for electronic products across printed-board fabrication, assembly, parts, processes and mechanical assembly.
For365PCB, the strategic lesson is: Traceability Should Follow Risk — Not Be a Marketing Checkbox.
177 — Material Lot
For high-risk products, relevant material/component lot relationships may need preservation according to agreed traceability requirements.
Root Cause Needs History.
178 — Process Record
Potentially:
Lot
Machine
Program
Inspection Result
can become part of manufacturing evidence.
Production Generates Engineering Data.
179 — Assembly Standards
Current IPC assembly releases include J-STD-001J and IPC-A-610J, both released in 2024; J-STD-001J addresses soldering process/material requirements while IPC-A-610J addresses post-assembly acceptability.
Process Requirement and Acceptance Criteria Are Related — But Not the Same Thing.
180 — Inspection ≠ Process Control
A board can pass final inspection after an unstable process.
Stable Process Is Better Than Sorting Defects at the End.
181 — SPI
Solder paste data can reveal: Upstream Process Stability.
182 — AOI
AOI data can reveal: Placement / solder trends.
183 — X-Ray
Hidden joints may require appropriate inspection according to project risk.
Inspection Strategy Should Follow Failure Visibility.
184 — Statistical Thinking
PVT moves from: "Does this unit pass?"
toward: "What distribution does this process create?"
185 — Mean
Where is the process centered?
186 — Variation
How wide is the distribution?
Centered but wildly variable is still risky.
187 — Specification Limit vs Control Limit
These are conceptually different.
Specification
What the product requires.
Process Behavior
What manufacturing is actually producing.
Never Confuse Product Tolerance With Process Stability.
188 — Cp / Cpk Direction
For appropriate measurable CTQ characteristics, capability metrics can help assess:
relative to specifications.
Process Capability Requires Enough Representative Data.
Do not claim capability from three samples.
189 — Process Capability Is Characteristic-Specific
A factory does not have:
Cpk = 1.67.
A:
Specific Process Characteristic
has a measured capability under a defined process.
190 — CTQ
Identify:
Critical-to-Quality
characteristics.
Examples:
connector position
impedance
thermal interface
programming state.
191 — CTF
Critical-to-function characteristics deserve strong control.
Measure What Can Break the Product.
192 — Control Plan
For important characteristics define:
What
Where
How
Frequency
Reaction
Control Plan Turns Engineering Risk Into Manufacturing Control.
193 — Reaction Plan
What happens when process exceeds its allowed state?
Detecting Drift Without a Response Plan Is Not Control.
194 — Measurement System Analysis Direction
Before trusting production capability data: Make Sure the Measurement System Is Capable Enough to Distinguish Real Variation.
This aligns naturally with ISO 10012:2026's emphasis on validity/reliability of measurement results.
195 — GR&R Inputs
For selected critical measurements, repeatability/reproducibility analysis may be appropriate.
Don't Mistake Gauge Noise for Product Variation.
196 — Test Fixture Correlation
Station 1: passes.
Station 2: fails.
Which One Is Right?
197 — Station Correlation
Production test stations should produce sufficiently comparable conclusions.
Scale Requires Test Consistency.
198 — Golden Product
Reference unit can help detect: fixture drift.
But again: Golden Unit Is Not the Entire Measurement System.
199 — False Fail
Good product fails test.
Cost: rework delay.
200 — False Pass
Bad product passes test.
Risk: Customer Failure.
Usually much more dangerous.
201 — Test Limits
Test limits should account for:
product requirement
measurement variation
process distribution.
Test Limit Engineering Is Not Copying Datasheet Limits.
202 — Guardband Direction
Where warranted, internal manufacturing limits may be tighter than final specification to preserve margin.
Process Control Can Protect Customer Specification.
203 — Overly Tight Limits
But excessive guardband creates: False Fail and Cost.
Manufacturing Limits Need Engineering Justification.
204 — PVT Sample Size
Quantity should follow:
process questions.
There Is No Universal “100 Units = PVT.”
205 — One PVT Lot
One lot may not reveal:
different material
date
operator
variation.
Production Confidence Grows Through Repetition.
206 — Pilot Build
A pilot build can bridge: PVT
toward: Regular Production.
207 — Ramp
Production volume increases gradually.
Scale Is Another Validation Condition.
208 — Volume Changes Process Behavior
At low volume: engineer watches every unit.
At high volume:
automation
shift variation
tool wear
matter more.
Scale Can Reveal New Failure Modes.
209 — Production Ramp Monitoring
Watch:
FPY
Defects
Rework
Cycle Time
Test Failures
Ramp Is a Learning Phase.
210 — Tool Wear
Mold / fixture / nozzle / contacts can age.
Process Capability Is Time-Dependent.
211 — Maintenance
Production equipment needs controlled:
where applicable.
Manufacturing System Is a Product System Too.
212 — PVT Failure
If PVT fails:
do not force production because: DVT already passed.
DVT Proves Design. It Does Not Prove Factory Repeatability.
213 — PVT Design Feedback
PVT may require: Product ECO.
Example: connector tolerances too sensitive.
This is legitimate.
214 — PVT Process Feedback
Other issues need:
rather than design change.
215 — PVT Fixture Feedback
Sometimes: The Product Is Fine. The Fixture Is Wrong.
216 — Root-Cause Classification
Every failure should be classified correctly:
Design
Material
Supplier
Process
Fixture
Software
Operator
Measurement
Correct Classification Determines Correct Action.
217 — PVT Exit Criteria
Possible project-specific conditions include:
production BOM approved
production tooling validated
work instructions approved
test fixtures validated
major yield issues closed
traceability working
key CTQs under control.
Production Release Should Have Objective Gate Criteria.
218 — Production Release
Production Release means: The Product Definition + Manufacturing Definition + Test Definition Are Controlled Enough to Scale.
219 — Release Package
A mature production release can include:
Production Needs a Complete Definition.
220 — As-Designed
What engineering intended.
221 — As-Built
What manufacturing actually created.
These Must Converge.
222 — As-Tested
What exact configuration generated the evidence.
Validation Evidence Belongs to As-Tested Configuration.
223 — As-Released
What configuration is approved for production.
The Four States Must Remain Traceable.
224 — Change After Validation
A design change after DVT does not automatically inherit: All Previous Evidence.
225 — Change Impact Assessment
Ask: Which requirements could this change affect?
Then define: Revalidation Scope.
226 — Supplier Change
Supplier changes can affect:
electrical
mechanical
reliability
manufacturing
behavior.
Supply Chain Change Can Be Engineering Change.
227 — Material Change
A PCB laminate / plastic / TIM change can invalidate: Relevant Evidence.
228 — Firmware Change
Firmware can alter:
cybersecurity.
Software Can Invalidate Hardware Validation.
229 — Mechanical Change
Housing change can alter:
sealing.
One CAD ECO Can Have Multiphysics Impact.
230 — Regression Strategy
Create a standing: Product Regression Matrix.
This becomes more valuable every release.
231 — Automatic Regression
Software / HIL / fixture-based tests can automatically verify stable requirements.
Automation Makes Repetition Economical.
232 — Manual Regression
Some tests still require:
specialist judgment.
Automate Where It Improves Evidence — Not for Fashion.
233 — Verification Coverage Dashboard
For complex projects, project status can be summarized as:
Total Requirements
Planned
Passed
Failed
Open
Waived
Readiness Becomes Visible.
234 — Stoplight Without Evidence
A dashboard showing: 95% green
is meaningless unless every green cell links to: Real Evidence.
235 — Evidence Repository
Organize reports by:
requirement.
Future Engineers Should Be Able to Reconstruct Why a Product Was Released.
236 — Raw Data
Where useful, preserve:
not only exported screenshots.
237 — Data Integrity
Test results should remain linked to:
time.
Measurement Without Context Loses Value.
238 — Validation Digital Thread
Potential chain: Customer Need → Requirement → Design → Prototype → EVT Result → ECO → DVT Requirement Closure → Production Test → PVT Yield → Production Serial → Field Performance
Product Evidence Can Live Through the Entire Lifecycle.
239 — Field Data Is the Final Reality
Even a well-validated product eventually meets:
Real Customers.
240 — Field Feedback
If failure appears:
compare: Field Condition
against: DVT Condition.
Did We Validate the Right Environment?
241 — Requirement Gap
Maybe customer used product in an environment engineering never specified.
Sometimes Field Failure Reveals Missing Requirement.
242 — Validation Gap
Requirement existed, but test did not reproduce the real stress.
Sometimes Test Design Was Wrong.
243 — Process Gap
DVT unit worked.
Production unit failed.
Sometimes PVT / Process Control Was Insufficient.
244 — Design Margin Gap
Production variation remained within spec, but product still failed.
Sometimes Design Margin Was Too Small.
245 — Feedback Into Next Revision
Field Failure → Requirement / Validation Update → Design Improvement → Regression Test
Real-World Failure Should Improve the Validation System.
246 — Every Failure Should Improve the Test Plan
This is extremely important for365PCB.
If a customer failure reveals: A Previously Uncovered Failure Mechanism,
add it to: Future Validation.
247 — Validation Knowledge Base
Over years, build: Failure Mechanism → Test Method → Design Rule → Process Control
This Becomes Engineering Intellectual Capital.
248 — This Connects Directly to the 365PCB Advanced Manufacturing Technology & Reliability Institute
Prototype teaches: What might fail.
EVT teaches: Where architecture is weak.
DVT teaches: Whether product requirements are truly met.
PVT teaches: Whether manufacturing can repeat the result.
Production teaches: How the process behaves over time.
Field teaches: Which assumptions survived reality.
Therefore: Validation Should Become a Learning System — Not a Testing Department.
249 — Advanced Validation = Multi-Physics Validation
Complex electronics should not validate every discipline in isolation.
Because:
Real Products Fail at the Boundaries Between Disciplines.
250 — Cross-Domain Test
Example:
Maximum AI workload
High ambient
Wireless active
may expose a failure absent from each isolated test.
Combination States Matter.
251 — Stress Interaction
Two individually acceptable stresses may interact.
Validation Should Understand System-Level Combinations Where Risk Requires It.
252 — Worst Case Is Not Always "Everything Maximum"
Some worst cases occur at:
transition
intermediate load
cold start.
Find the Mechanism — Don't Guess the Corner.
253 — Mission Profile
For advanced products, define: How the Customer Actually Uses the Product Over Time.
This may include:
Temperature
Duty Cycle
Load
Vibration
Power Cycles
Connectivity
Mission Profile Can Drive Validation.
254 — Validate the Intended Life
A product operating: 24/7
has different requirements from one operating: 10 minutes/day.
Usage Is a Reliability Input.
255 — Customer Environment
Industrial cabinet.
Outdoor pole.
Vehicle.
Desktop.
Rack.
Wearable.
Environment Changes Everything.
256 — Market-Specific Validation
The applicable:
safety
EMC
environmental
cybersecurity
requirements vary with product category and destination.
Validation Architecture Should Know the Market Before DVT.
257 — Regulatory Test Planning Early
Do not finish DVT and only then discover: A Missing Safety Isolation Architecture.
258 — Pre-Compliance Early
Selected EMC / safety risks can be reviewed during EVT.
Compliance Is Cheaper When It Influences Design Early.
259 — Qualification Plan
A strong project should have a controlled plan describing:
What
Why
When
Sample Configuration
Acceptance
Qualification Should Be Planned Before Samples Arrive.
260 — Test Sequencing
Test sequence itself may affect results.
Example: A destructively stressed sample should not automatically be reused for an unrelated qualification without considering prior exposure.
Sample History Matters.
261 — Sample Allocation
Plan specific units for:
destructive testing.
Every Sample Should Have a Job.
262 — Destructive Tests
Some tests intentionally consume: Product Life.
Therefore: Don't Confuse Tested-to-Failure Hardware With Untouched Reference Hardware.
263 — Pre-Test Inspection
Know initial condition.
264 — Post-Test Inspection
Know: What Changed.
Environmental Test Without Post-Test Analysis Can Miss Latent Damage.
265 — Functional Test Before / During / After Stress
Depending on product requirements:
behavior may be evaluated:
environmental exposure.
Surviving Storage and Operating Correctly Under Stress Are Different Requirements.
266 — Latent Failure
Product passes immediately after test.
Days later: fails.
Reliability Can Contain Delayed Failure Mechanisms.
267 — Test Sequence Correlation
Environmental test can expose damage that: Functional Test Then Detects.
This is an integrated validation strategy.
268 — Failure Analysis
When validation fails: Preserve the Sample.
Do not immediately repair it.
269 — Failure Review
Capture:
Unit
Config
Test Point
Condition
Symptoms
Data
Failure Evidence Begins Before Teardown.
270 — Root Cause Before Fix
A fix without mechanism understanding can create: False Closure.
271 — Corrective Action
Design or process change should address: Root Cause.
272 — Verification of Corrective Action
Repeat relevant test.
A Fix Is Not Closed Until the Requirement Is Re-Verified.
273 — Regression
Then test: What the Fix Could Have Broken.
274 — FRACAS Direction
For larger reliability programs, a formal: Failure Reporting → Analysis → Corrective Action
loop can help manage repeated failures.
Failure Management Should Be Systematic.
275 — Risk Register Update
Validation result should update: Engineering Risk.
276 — FMEA Update
If a new failure mode appears: Add It to Risk Analysis.
277 — Control Plan Update
If manufacturing caused it: Add Process Control.
278 — DFM Rule Update
If geometry caused it: Improve DFM Knowledge.
279 — Test Coverage Update
If test missed it: Improve DFT / FCT.
280 — Requirement Update
If specification omitted it: Improve Requirements Engineering.
281 — This Is the Real Validation Loop
Failure → Root Cause → Design / Process / Requirement Change → Re-Test → Organizational Learning
Validation Should Improve More Than One Unit.
282 — What Does World-Class EVT / DVT / PVT Validation Look Like?
At the highest level: Customer Need → Requirements Engineering → Requirement IDs → Traceability → Risk Analysis → Verification Strategy → Verification Matrix → Acceptance Criteria → Prototype Evidence → EVT → Architecture Bring-Up → Electrical Characterization → SI / PI → RF → Thermal → Mechanical → Firmware → Security → Major Risk Closure → Engineering ECO → DVT → Production-Representative Hardware → Requirement Closure → Functional Validation → Performance → Environmental Validation → EMC → Safety / Compliance Readiness → Reliability → Cybersecurity → Regression → Multiple-Unit Variation → Production Candidate Freeze → PVT → Production BOM → Production Tooling → Production Software → Work Instructions → Fixtures → Manufacturing Test → Measurement System → Cycle Time → First-Pass Yield → Process Window → CTQ → Capability → Traceability → Control Plan → Pilot / Ramp → Release Review → Controlled Production
That is the difference between: Testing a Product
and: Building Evidence for Production Readiness.
Typical EVT / DVT / PVT Validation Deliverables
Depending on project requirements, a 365PCB ODM validation program may include:
Product Validation Strategy
Verification & Validation Plan
Requirement Review
Requirement Verifiability Review
Requirements Traceability Matrix
Verification Cross-Reference Matrix
Requirement-to-Test Mapping
Verification Method Definition
Acceptance Criteria Definition
Validation Configuration Definition
Test Sample Matrix
Sample Allocation Plan
Test Sequence Plan
Risk-Based Validation Plan
Mission-Profile Inputs
EVT Entry Criteria
EVT Exit Criteria
EVT Test Plan
EVT Configuration Baseline
EVT Engineering Samples
EVT Bring-Up
EVT Functional Testing
EVT Electrical Characterization
Power Validation
Power Sequencing Validation
Processor / Memory Bring-Up
Interface Validation
High-Speed Channel Validation Inputs
SI Validation Inputs
PI Validation Inputs
Analog Validation
Sensor Validation
RF Validation Inputs
Antenna Validation Inputs
Firmware Validation
RTOS Validation Inputs
Embedded Linux Validation Inputs
AI Runtime Validation Inputs
IoT Connectivity Validation Inputs
Secure Boot Validation Inputs
OTA Validation Inputs
Product Cybersecurity Validation Inputs
Mechanical Fit Validation
Thermal Architecture Validation
EVT Measurement Data
EVT Issue Tracking
EVT Failure Analysis
EVT ECO Inputs
EVT Closure Report
DVT Entry Review
DVT Configuration Baseline
DVT Requirement Matrix
DVT Functional Validation
DVT Performance Testing
DVT Power Validation
DVT Thermal Validation
Sustained-Performance Validation
DVT RF Validation
DVT Wireless / OTA Inputs
DVT Mechanical Validation
DVT Sealing / Ingress Inputs
Environmental Validation Inputs
IEC 60068 Test Planning Inputs
Temperature Validation Inputs
Humidity Validation Inputs
Thermal-Cycling Inputs
Vibration Inputs
Shock Inputs
Drop Inputs
Chemical-Resistance Inputs
Corrosion Inputs
UV Inputs
EMC Pre-Compliance Inputs
EMC Validation Inputs
Safety / Compliance-Readiness Inputs
Reliability Validation Inputs
Accelerated-Test Inputs
Multi-Unit Validation
Corner-Unit Inputs
Production-Tolerance Inputs
Alternate-Component Validation
Approved-Source Validation
Firmware Regression
Hardware Regression
Mechanical Regression
ECO Impact Analysis
Revalidation Planning
Test Deviation Management
Failure Review
Corrective Action Verification
DVT Requirement Closure
DVT Validation Report
DVT Exit Review
Production Candidate Baseline
PVT Entry Review
Production BOM Validation
Production Firmware Validation
Production Security-State Validation
Production Mechanical Validation
Tooling Validation
Assembly Fixture Validation
Test Fixture Validation
Programming Fixture Validation
Work-Instruction Validation
Operator Assembly Trial
DFA Validation
DFT Validation
ICT Inputs
FCT Inputs
Boundary-Scan Inputs
Programming Verification
Calibration Validation
Serial-Number System Validation
Product Traceability Inputs
IPC-1782B Traceability Inputs
Assembly Acceptance Inputs
J-STD-001J Inputs
IPC-A-610J Inputs
First-Pass Yield Analysis
Final Yield Analysis
Defect Pareto
Rework Analysis
Cycle-Time Analysis
Production Bottleneck Analysis
Test Cycle-Time Analysis
Process Window Evaluation
CTQ Definition
Critical-to-Function Inputs
Control-Plan Inputs
Reaction-Plan Inputs
Measurement-System Inputs
ISO 10012 Measurement Inputs
Test Equipment Control Inputs
Calibration Inputs
Fixture Repeatability Inputs
Station Correlation
GR&R Inputs
Process Capability Inputs
Cp / Cpk Inputs where appropriate
Pilot-Build Validation
Ramp Validation
PVT Failure Analysis
Production Release Review
Production Release Package
Open-Issue Register
Residual-Risk Register
Approved-Deviation Register
Validation Evidence Repository Inputs
Raw Test Data Management Inputs
As-Designed / As-Built / As-Tested Configuration Control
Requirement Closure Dashboard
Product Regression Matrix
Validation Digital Thread Inputs
Field-to-Validation Feedback Inputs
Validation Root-Cause Engineering
Validation Architecture Documentation
The actual validation depth should follow: Product Risk + Requirements + Complexity + Market + Environment + Failure Consequence + Production Volume + Product Lifetime.
Bring Us the Requirements — Not Just the Test List
You can begin with:
or simply:
Tell Us What the Product Must Prove Before You Are Willing to Manufacture It at Scale.
365PCB can help translate: Requirements → Verification Plan → Engineering Samples → EVT → DVT → PVT → Production Evidence.
Don't Just Run the Tests.
Define the Requirement.
Define the Configuration.
Define the Verification Method.
Define the Acceptance Criteria.
Build the Correct Sample.
Measure With a Trusted Measurement System.
Validate the Architecture.
Challenge the Product.
Test the Environment.
Test the Failure Paths.
Validate Multiple Units.
Understand the Variation.
Capture Every Failure.
Find the Root Cause.
Verify Every Fix.
Control Every Deviation.
Validate the Manufacturing Process.
Measure First-Pass Yield.
Control the Critical Characteristics.
Close the Requirements.
Release With Evidence.
365PCB EVT / DVT / PVT Validation connects: Requirements + Systems Engineering + PCB + Firmware + Mechanical + Thermal + RF + EMC + Reliability + Cybersecurity + Measurement + Manufacturing + Quality
into one coordinated evidence-building process.
Validation Is Not the Act of Running Tests.
It Is the Process of Building Evidence That the Product Meets Its Requirements in the Configuration That Will Actually Be Manufactured.
And:
EVT Proves the Architecture.
DVT Proves the Product.
PVT Proves the Production System.
English
