Testing & defects: 44 codes, 17 zones, 4 severities

“Grade B cosmetic” ne fonctionne que si tout le monde y met le même sens. Le defect tracking fait choisir le testeur dans une liste structurée plutôt que de décrire les dégâts en prose, afin que l’acheteur à Munich et le fournisseur à Copenhague lisent le même signal.

La structure

Chaque defect record a quatre champs: code (un parmi 44 — dent, crack, missing-key, dead-pixel, battery-degraded, port-damaged, etc.), zone (une parmi 17 — lid, base, screen, keyboard, palmrest, port-area-left, vent-rear, etc.), severity (1–4, où 4 est critical et force un overall grade minimum de D), et une note optionnelle pour les rares cas où la prose ajoute vraiment quelque chose.

Ce que cela permet

Parce que les defects sont structurés, la plateforme peut faire des choses que la prose ne peut pas faire. L'auto-grade engine lit la defect list et calcule un suggested grade. Les buyers qui cherchent "no critical defects on the screen" peuvent filtrer les listings par zone+severity. Les chargebacks d'assurance et de lease-return se calculent per-defect contre la damage matrix du contrat au lieu qu'un tester écrive "moderate damage, suggest €50 deduction" et attende que quelqu'un conteste.

La testing detail page

/core/testing/[id] est l'endroit où le tester travaille. Un defect picker (filtrable par zone), un grade dropdown pour chaque dimension (functional, cosmetic, battery, data), et le bouton auto-grade qui combine les choix en overall A-R grade. Le tester confirme ou override. L'audit row est écrite. L'asset passe au pipeline stage suivant.

Productivity

/core/testing/productivity est la vue opérations: tester throughput, temps moyen par asset, defect-distribution par category. L’équipe operations peut répondre à “combien de laptops avons-nous testés le mois dernier” depuis la page, sans transformer la question en comptage manuel.