The main Box Build testing types answer different questions, so they are not interchangeable. ICT (in-circuit test) and FCT (functional circuit test) confirm a unit was built and behaves correctly; burn-in and HALT/HASS are reliability tools that address whether it will keep working. Most confusion — and most wasted test spend — comes from treating them as one decision instead of picking the mix that matches the product’s risk and volume.
This guide explains each type in plain terms: what it checks, at what stage it applies, what it does not prove, and how to choose a coverage mix. It is written for engineers and buyers scoping a test plan for a Box Build program, where the OEM owns the product acceptance criteria and the integrator executes an agreed procedure and keeps the records.
The two questions testing answers
Every test in a Box Build flow serves one of two purposes:
- “Was it built right, and does it work?” — a pass/fail manufacturing acceptance check on each unit. ICT and FCT live here.
- “Will it keep working?” — a reliability check that stresses parts or a sample to surface latent or design weaknesses. Burn-in, HALT, and HASS live here.
Keeping those questions separate is the first step to a coverage plan you can defend, because it stops you from expecting a functional station to prove reliability, or a stress screen to catch a wiring error.
ICT — in-circuit test
ICT checks the electrical construction of a populated board or assembly: are the right components present, correctly oriented, the right value, and free of shorts, opens, and solder defects? It typically uses a bed-of-nails fixture that contacts defined test points and measures each net.
- Catches: assembly and component-level defects — wrong, missing, misoriented, or out-of-tolerance parts; shorts and opens.
- Does not prove: that the finished product performs its intended function as a system.
- Best when: the board or assembly has accessible test points and volume justifies a fixture; strong at isolating where a manufacturing defect is.
FCT — functional (circuit) test
FCT powers the assembly and exercises it the way the product works, checking that selected functions produce the expected outputs. On a Box Build, this is often the system-level acceptance test after final assembly — connectors mated, firmware loaded, real I/O stimulated.
- Catches: functional failures the unit shows when operating — a subsystem that does not respond, an out-of-limit measurement, a configuration or firmware mismatch.
- Does not prove: the internal construction detail an ICT would isolate, or long-term reliability.
- Best when: you need a go/no-go on real behavior. FCT coverage should be defined against product functions and credible assembly errors — build it from a coverage matrix, as covered in how to create a functional test plan, and run it as part of the functional testing capability.
Burn-in — infant-mortality screen
Burn-in runs units powered (often at elevated temperature) for a set period to precipitate early-life (“infant mortality”) failures before shipment, so weak parts fail on your bench instead of in the field. It is a screen, not a functional judgment: units are typically functionally tested before and after.
- Catches: early-life component failures that would otherwise appear in the first hours or days of field use.
- Does not prove: the design margin or that a good unit is defect-free — it removes weak units, it does not certify strong ones.
- Best when: field failures are costly and the product has an infant-mortality profile worth screening. Burn-in overlaps with broader environmental screening, described under environmental stress screening (ESS).
HALT and HASS — reliability, not acceptance
HALT (Highly Accelerated Life Test) and HASS (Highly Accelerated Stress Screen) are related but distinct, and both are frequently misapplied as production acceptance tests. They are not.
- HALT is a design activity: a sample is driven with escalating stresses (thermal cycling, vibration, and combinations) beyond normal operating limits to find the product’s weak points and design margins. The goal is to discover and fix limits, not to pass units. It runs on a few samples, usually during development.
- HASS is a production screen derived from HALT results: it applies stresses within a proven safe window to catch process- or component-induced defects on production units, without consuming useful life.
The key rule: HALT informs the design and sets the screen; HASS screens production within limits HALT proved safe. Neither replaces ICT or FCT, and HALT is never a per-unit acceptance gate.
The testing types at a glance
| Test | Question | Stage | Catches | Not for |
|---|---|---|---|---|
| ICT | Built right? | Per unit / board | Component & solder defects, shorts/opens | System function, reliability |
| FCT | Works right? | Per unit / final assembly | Functional & configuration failures | Construction isolation, reliability |
| Burn-in | Weak parts? | Per unit (sampled or 100%) | Early-life failures | Design margin, acceptance |
| HALT | Where are the limits? | Design (samples) | Design weaknesses & margins | Acceptance, per-unit pass/fail |
| HASS | Process drift? | Production screen | Process/component defects | Design discovery, acceptance judgment |
How to choose a coverage mix
You rarely need all five. Choose against risk, accessibility, and volume:
- Start from the failure risks and essential functions. Map each production check to a known failure mode or a function that must work — coverage does not have to be universal, but it must have a rationale.
- Use ICT when construction access and volume justify a fixture, and FCT for the system-level go/no-go. On many low-to-mid-volume Box Builds, a well-designed FCT plus visual/AOI at the board stage carries the acceptance load.
- Add burn-in only where an infant-mortality profile and field-failure cost justify it — it adds time and energy per unit.
- Treat HALT as a development investment and HASS as its production output — do not bolt HALT on as an acceptance test.
- State the boundary. Say what each test does not cover, so a pass result is never read as broader compliance. Whatever the mix, capture the records — see traceability and serialization for tying results to units.
FAQ
What is the difference between ICT and FCT?
ICT checks the construction of the assembly — that components are present, correct, and free of shorts and opens — usually through a bed-of-nails fixture. FCT powers the unit and checks that it functions as intended at the system level. ICT isolates where a manufacturing defect is; FCT confirms real behavior. They are complementary, not substitutes.
Is burn-in the same as HALT?
No. Burn-in runs units under power (often warm) for a set time to weed out early-life failures before shipment — it is a production screen. HALT drives a few samples with stresses beyond normal limits to find design weaknesses during development. Burn-in removes weak units; HALT improves the design.
Do I need all of these tests for a Box Build?
Usually not. Most programs combine an acceptance test (FCT, sometimes with ICT) with reliability screening only where field-failure cost justifies it. Choose the mix from the product’s risks, test-point access, and volume, and document why each check is included.
Can HALT or HASS be used as a production acceptance test?
HALT cannot — it deliberately exceeds operating limits to find weaknesses, so it is a design tool, not a per-unit gate. HASS is a production screen, but it screens for process defects within HALT-proven safe limits; it is not a substitute for functional acceptance testing.
Testing choices are ultimately a Box Build quality decision: match the type to the question, define coverage against real risk, and record the result. For the execution detail, see how to create a functional test plan and the functional testing capability, or start from what Box Build assembly is.
