A failure notice is one of the more stressful emails a project produces, and it usually lands at the worst possible moment. The questions behind it are always the same three: what actually failed, who is responsible for fixing it, and does any of this still fit the shipping date.
A failed test item is a result, not a verdict. Nothing about it removes your product from a market or ends the project. What happens next depends far more on why the product failed than on the failure itself, so the first job is not to fix anything - it is to find out which of three quite different situations you are in.
A failed test item is a measurement, not a rejected application
In plain terms: the laboratory tested a defined configuration of your product against a standard, compared the measurement with the limit in that standard, and the measurement was outside it, or a construction requirement was not satisfied. The item is recorded as not compliant with that clause.
That produces information, not a rejection. The words people mix up in this situation each mean something specific, and the failure only touches one of them:
- Test report - the laboratory's record of what was tested, under which conditions, and what was measured. This is the document a failing item appears in.
- Certificate - issued by a certification body or authority under a defined scheme. A failed test item does not produce one, but it also does not stop you applying again after the product is corrected.
- Declaration of Conformity - drawn up and signed by the manufacturer (or the importer or authorised representative in the market, depending on the rules). It is not issued by the laboratory and it is not a test result.
- Certification - the authorisation process itself. For US radio transmitters, for example, that route runs through a Telecommunication Certification Body and results in an FCC ID; most unintentional radiators instead use the manufacturer's own Supplier's Declaration of Conformity.
It helps to separate two things people describe as the same event. A test item that failed inside a project you commissioned is a technical problem. A filing that an authority or certification body has returned with questions is usually a completeness problem, and it is answered with the body that raised it, not with a redesign.
The first thing to ask for is the measured data
"It failed EMC" is not enough to decide anything. Ask the laboratory for:
- Which test item and which clause of which standard, and the version of the standard applied
- The limit and the measured value - not just that it was over, but by how much, and at which points
- The test conditions: operating mode, worst-case configuration, cable arrangement, adapter used, firmware build, number of samples on test
- Whether the result was repeatable when the item was run again
- Whether the sample was opened, loaded or modified during earlier destructive checks
With those numbers, an engineer can usually tell within a day whether the fix is a small component change or a structural problem. Without them, the natural reaction is to start swapping parts, which is how a two-week issue becomes a two-month one.
Ask what was in the tested configuration as well. It is not unusual to find the sample was run with a different power adapter, a second-source display, or a firmware build that predates the production release - in which case the failure may not be about the product you intend to sell.
Three different problems that all get called "a failure"
1. The sample does not match the production build
This is the most common cause, and the cheapest to resolve. Typical forms: the adapter used on the test bench was the one at hand rather than the one that ships; a production filter or ferrite bead was not fitted on the engineering board; the firmware was a debug build with logging or a different switching frequency; the enclosure was a 3D-printed mock-up without the metal insert that the tooling version has.
Nothing is wrong with the design, and nothing needs to change on the production line. What has to change is the sample: send units that match what will be manufactured, and the retest is normally limited to the failed items. This is also why sample verification before testing saves more time than it costs - a mismatch caught in the first hour is a postponement, not an invoice.
2. The test setup or the applied standard does not match the product
Laboratories are not infallible, and a failure that is inconsistent with your own pre-compliance data or with how the product behaves in the field is worth a second look. The usual causes: the product was exercised in a non-worst-case mode (idle rather than continuous transmit, or half load rather than full load); an older version of the standard was applied; the sample had already been disturbed by an earlier safety inspection and was re-assembled slightly differently; a cable length or routing used in the setup was not the one specified.
Raise it with data rather than argument - send your pre-test results and point at the discrepancy. Reputable laboratories will review the configuration, and if the setup was wrong they will repeat the item. That review costs a day; guessing at a fix for a problem that does not exist costs considerably more.
3. The design genuinely does not meet the limit
If the measurement is reproducible and the configuration matches production, the product needs a real change. This is the case that costs engineering time, and the one where the quality of the laboratory's technical feedback matters most: it is the difference between changing one component value and replacing an entire sub-assembly on a hunch.
What usually changes on the product
Most fixes in electronics fall into a small number of categories: filtering on the interface or the line where the problem was measured; cable routing or length, where cables are part of the shipped product; grounding and PCB layout changes; firmware parameters such as switching frequency, duty cycle or output power; shielding or enclosure openings; and in some cases the power supply itself, when the adapter is the noisy part.
Every one of those is a change to the tested configuration. That single sentence is the reason a "free" fix is never free in documentation terms. The report describes hardware and firmware that no longer exist, and the difference has to be closed either with a retest or, in limited cases, with a documented engineering rationale that the laboratory is willing to put in writing.
On radio products, watch how fixes interact. A firmware change made to reduce emissions can move output power or modulation settings, which are radio parameters in their own right. A change to the power supply can affect both emissions and immunity. Fix one item and you may have invalidated another, which is why the retest scope should be decided after the change is defined, not guessed at before.
Retest scope: normally not the whole project again
When the change is well understood and documented, most laboratories propose a partial retest - repeat the items the change can affect, and keep the ones it cannot. Roughly:
| What changed | What normally goes back on test |
|---|---|
| One component or filter on a single interface | The item that failed, plus closely coupled items - conducted disturbance and radiated emissions are often reviewed together |
| The power supply or adapter | Items that depend on the supply, plus the safety construction checks that relate to it |
| Firmware affecting radio behaviour | Radio items, plus emission items that depend on transmit behaviour |
| PCB layout, shielding or antenna | Emissions and radio items as applicable, and the safety creepage and clearance checks if layout changed near them |
| The build changes after a full passing set | Often the formal set repeated - at that point no document in the file describes a product that was actually measured |
Ask for the re-scope in writing before the modification is carried out, so engineering knows what the change is likely to trigger. Doing it the other way round - change first, ask afterwards - is how projects discover they have to re-test an item nobody budgeted for. If your original quotation did not state how retests are handled, that clause is worth confirming now; our breakdown of what a testing quotation includes explains how retest terms are usually written and what a re-quote triggers.
What the failure does to your report and your declaration
Only the final passing documentation belongs in the technical file and in what you send to a buyer or marketplace. Preliminary and failed runs are internal data: keep them, they are useful evidence of how the design was validated, but they are not the documents that support a Declaration of Conformity.
Two practical points we see clients get wrong. First, if the laboratory issues a report for the failed run, do not forward it to your customer or upload it in a marketplace compliance request. You will be asked to explain a superseded document and it will slow down the review; wait for the revised report showing the passing result. Second, once the product has been modified, the report, the technical file and the Declaration of Conformity all have to describe the same build. A declaration still describing the pre-fix hardware is worse than no declaration, because it is inaccurate by your own hand.
Situations that come up again and again
The adapter on the bench was not the shipping adapter. A mains-powered device failed a conducted emission item. The wiring under test used a spare adapter from another project because the production adapter had not been shipped in the sample box. The same unit passed once tested with the correct supply. Total cost: one retest slot and a week, rather than a redesign.
The failure notice arrived without data. The first message was a single line saying an item had failed. Engineering spent a week selecting different filters before anyone asked for the measurement. Once the actual data arrived - one narrow frequency band, a few dB over - the fix was a single component change and a partial retest of the affected item.
The board was changed before the scope was agreed. After an emissions failure, a client modified the supply circuit and updated the firmware in the same revision. The firmware change altered a radio parameter, so radio items came back into scope, and the layout change touched a safety clearance item. Nothing was wasted, but the retest and the schedule were both larger than the fix alone would have required - the sequencing caused that, not the failure.
A failing preliminary report was sent to the buyer. A client forwarded early data to a customer to show progress. The compliance team on the other side read it as a non-compliant product and put the order on hold. Preliminary runs are for your own engineering decisions, not for communication.
What to do in the first three days
- Get the measured data - item, clause, limit, measured value, margin, conditions, repeatability.
- Confirm the tested configuration - which adapter, which firmware, which sample build, how many units.
- Classify the cause - sample mismatch, test setup, or genuine design issue. The next step is completely different in each case.
- Ask for the retest scope in writing before deciding which modification to make, and ask what other items the planned change could affect.
- Confirm the commercial terms - whether a retest cycle is included, how a second failure is handled, and what counts as a new project scope.
- Book the retest slot early - the sample and the schedule are usually the real constraint, not the test itself.
Handled in that order, a failure usually costs a retest and a delay. Handled in the opposite order - modify first, investigate afterwards - it costs both plus a second redesign.
How we run a failure case
A failure is the point in a project where a laboratory's engineering input is worth the most, so we treat it as a technical discussion rather than a status update. In practice that means four things. The measurement data reaches you with the test conditions attached, not as a one-line notification. Our engineers say what they believe caused it and which of the three categories above it falls into, including when the answer is that the sample was not representative. The retest scope is put in writing before you commit to a modification, so engineering knows what the change is likely to trigger. And where a change is confined and well justified, the unaffected items from the original run are carried over instead of repeating a set that already passed.
Before testing starts, the same discipline applies in the other direction: we review the sample, the manual, the label and the intended configuration against the scope, because most failures that we see coming are configuration mismatches rather than design faults. A failure that is spotted at sample receipt costs a postponement. The same failure found in the shielded room costs a retest slot and a revised schedule.
That is the working method behind how we handle testing projects in Shenzhen, and the item-by-item scope for the standards involved sits in our testing and certification services pages.
If you have just received a failure notice, send it over with the measured data and the change your team is considering.
We will tell you whether it looks like a sample mismatch, a test setup issue or a genuine design problem - and what retest scope each of those would trigger - before you commit to a modification.