Testing & Defects: 44 Codes, 17 Zones, 4 Severities

“Grade B cosmetic” only works when everyone means the same thing by it. Defect tracking makes the tester pick from a structured list rather than describe the damage in prose, so the buyer in Munich and the supplier in Copenhagen read the same signal.

The structure

Each defect record has four fields: code (one of 44 — dent, crack, missing-key, dead-pixel, battery-degraded, port-damaged, and so on), zone (one of 17 — lid, base, screen, keyboard, palmrest, port-area-left, vent-rear, and so on), severity (1–4, where 4 is critical and forces a minimum overall grade of D), and an optional note for the rare cases where prose actually adds something.

What it enables

Because the defects are structured, the platform can do things prose can’t. The auto-grade engine reads the defect list and computes a suggested grade. Buyers searching for "no critical defects on the screen" can filter listings by zone+severity. Insurance and lease-return chargebacks calculate per-defect against the contract’s damage matrix instead of a tester writing "moderate damage, suggest €50 deduction" and waiting for somebody to argue.

The testing detail page

/core/testing/[id] is where the tester works. A defect picker (filterable by zone), a grade dropdown for each dimension (functional, cosmetic, battery, data), and the auto-grade button that combines the picks into the overall A-R grade. The tester confirms or overrides. The audit row is written. The asset moves to the next pipeline stage.

Productivity

/core/testing/productivity is the operations view: tester throughput, average time per asset, defect-distribution by category. The operations team can answer “how many laptops did we test last month” from the page instead of turning it into a manual tally.