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.
English
