Defect analysis, in one paragraph
Defect analysis is the practice of classifying a defect by severity and tracing it back to its actual cause in the production process — as opposed to simply rejecting or reworking the defective units and moving on. Root cause analysis is the specific technique used to find that actual cause: a machine setting, a material batch, an untrained operator, a worn tool — rather than stopping at the visible symptom. Without it, the same defect routinely reappears in the next production run, because whatever actually caused it was never addressed.
Classifying defects by severity
This classification isn't academic — AQL sampling plans set different acceptance thresholds for each severity level, meaning a batch can pass on minor defects while a much smaller number of critical defects is enough to fail the entire inspection.
The 5 whys: tracing a defect to its cause
The 5 Whys is a simple, effective root cause technique: starting from the observed defect, keep asking "why did this happen," using each answer to prompt the next question, until the chain reaches an actual actionable cause rather than a restatement of the symptom. It typically takes three to five iterations to get there.
Defect: a batch of plastic housings has visible surface bubbling
Why #1: Why does the housing have bubbles? Trapped moisture in the plastic pellets during molding.
Why #2 and #3
Why #2: Why was there moisture in the pellets? They weren't dried before use. Why #3: Why weren't they dried? The drying step was skipped for this run.
Why #4: the actual root cause
Why #4: Why was drying skipped? The operator running that shift wasn't trained on the drying procedure for this material. That's an actionable root cause — a training gap — not just "bad plastic."
The fishbone (ishikawa) diagram: covering every angle
For defects with a less obvious cause, a fishbone diagram organizes potential causes into standard categories so an investigation doesn't fixate on the first plausible explanation:
- Method — was the process itself followed correctly?
- Machine — was equipment calibrated, maintained, or worn?
- Material — was the input material within spec for this batch?
- Manpower — was the operator trained and following procedure?
- Measurement — was the inspection or testing method itself accurate?
- Environment — did temperature, humidity, or workspace conditions play a role?
What happens after a failed inspection or audit?
Identifying a root cause only has value if it leads to a documented corrective action: what caused the defect, what specifically is being changed, and how the fix will be verified in the next production run. A supplier's assurance that "we will pay more attention" is not a corrective action — a specific process change, retraining record, or equipment fix that can be checked against the next batch is. Requesting this in writing, and checking for it at the next inspection, is what actually prevents recurrence.
Tracing defects from the China side
Root cause investigation is far more effective when someone can walk the actual production line, review the specific batch's materials and process records, and talk to the operators involved — not just look at a photo of the defective units. LifaSourcing.com coordinates this kind of on-the-ground defect investigation through quality control coordination and inspection coordination, so a rejected batch results in an actual fix, not just a reworked shipment and the same defect next time.
Mistakes this guide prevents
- Accepting rework without asking why the defect happened. The current batch gets fixed; the cause doesn't.
- Stopping at the first plausible explanation. Use the 5 Whys or a fishbone diagram to check you've reached an actual cause.
- Accepting a vague assurance instead of a documented corrective action. Ask what specifically is changing and how it will be verified.
- Treating every defect the same regardless of severity. Critical, major, and minor defects warrant different responses.
- Not checking whether the fix actually held in the next production run. Verification closes the loop; a promise alone doesn't.