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

“Grade B cosmetic” funktioniert nur, wenn alle dasselbe darunter verstehen. Defect Tracking laesst den Tester aus einer strukturierten Liste waehlen, statt den Schaden frei zu beschreiben, damit der Buyer in Muenchen und der Supplier in Kopenhagen dasselbe Signal lesen.

Die Struktur

Jeder defect record hat vier Felder: code (einer von 44 — dent, crack, missing-key, dead-pixel, battery-degraded, port-damaged und so weiter), zone (eine von 17 — lid, base, screen, keyboard, palmrest, port-area-left, vent-rear und so weiter), severity (1–4, wobei 4 critical ist und mindestens overall grade D erzwingt), und eine optionale note für die seltenen Fälle, in denen Freitext wirklich etwas hinzufügt.

Was es ermöglicht

Weil defects strukturiert sind, kann die Plattform Dinge tun, die Prosa nicht kann. Die auto-grade engine liest die defect list und berechnet einen suggested grade. Buyers, die nach "no critical defects on the screen" suchen, können listings nach zone+severity filtern. Insurance und lease-return chargebacks rechnen per-defect gegen die damage matrix des Vertrags, statt dass ein tester "moderate damage, suggest €50 deduction" schreibt und auf Widerspruch wartet.

Die testing detail page

/core/testing/[id] ist der Arbeitsplatz des testers. Ein defect picker (filterbar nach zone), ein grade dropdown für jede dimension (functional, cosmetic, battery, data), und der auto-grade button, der die Auswahl zum overall A-R grade kombiniert. Der tester bestätigt oder überschreibt. Die audit row wird geschrieben. Das asset wechselt in die nächste pipeline stage.

Productivity

/core/testing/productivity ist die operations view: tester throughput, durchschnittliche Zeit pro asset, defect-distribution nach category. Das Operations Team kann “wie viele Laptops haben wir letzten Monat getestet” auf der Page beantworten, ohne daraus eine manuelle Zaehlung zu machen.