Testing & defects : des codes, des zones et des severities au lieu d’adjectifs
Comment le defect tracking structuré remplace « minor cosmetic » par des codes sur lesquels l’acheteur à Munich et le fournisseur à Copenhague sont d’accord.
« Grade B cosmetic » ne fonctionne que si tout le monde y met le même sens. Le defect tracking fait choisir le tester dans une liste structurée plutôt que de décrire les dégâts en prose, pour que l’acheteur à Munich et le fournisseur à Copenhague lisent le même signal.
La structure
Un defect est un code — LCD-03 pour un écran éclaté, SCR-01 pour des rayures légères — avec une catégorie (cosmetic, functional, battery, data, missing part), une severity (minor, moderate, major ou critical, chacune avec son facteur de poids) et les zones du châssis où il peut apparaître, parmi dix-sept : capot, écran, clavier, repose-poignets, fond de coque, ports, charnières et le reste de l’anatomie. Certains codes exigent une photo. La plateforme livre 38 codes de base, votre organisation peut ajouter par-dessus un jeu de defaults tenant, et Paramètres > Core > Codes défaut est l’endroit où vous ajoutez les codes dont votre propre atelier a sans cesse besoin.
La page de détail testing
/core/testing/[id] est l’endroit où le tester travaille, en quatre onglets. Tests contient la checklist propre à la catégorie — pass ou fail par item, notes de defect, tout passer, réinitialiser, sauver l’avancement, terminer. Notation contient functional, cosmetic, battery, data, la lettre globale et la disposition ; le defect picker y filtre par catégorie, l’engine suggère les grades functional et battery à partir de la checklist et de la mesure de batterie, avec un bouton Appliquer la suggestion pour chacun, et le tester choisit la lettre globale de A à F. Notes et photos et Historique complètent l’ensemble. La clôture est bloquée tant que des checks requis ou des champs de grade manquent. Ce n’est agaçant que jusqu’au jour où cela empêche un « ça a l’air bon » de partir sous l’étiquette « tested ».
La queue et l’en-tête du détail affichent le numéro de l’inbound order sous lequel l’asset est arrivé — ou son asset tag lorsqu’il n’y a pas d’order — jamais l’ID interne de l’item de queue. Personne, sur le terrain, n’a jamais demandé à un collègue des nouvelles de l’item 4f8a-c2.
Clôturer comme échoué
Un test requis mis en fail ne peut jamais déverrouiller « Terminer les tests » ; le bouton reste désactivé volontairement. À la place, dès qu’au moins un test requis a échoué, la page propose Clôturer comme échoué (sur mobile, c’est le bouton principal lui-même qui devient cela). Le tester choisit une destination — recycler et récupérer des pièces, mettre au rebut, ou retourner au client — et donne une raison d’au moins dix caractères. La resale n’est pas dans cette liste : un device en échec n’entre pas dans le stock vendable par cette porte. Les machines réparables restent dans la queue, sont réparées, et sont retestées. Après confirmation, l’item est testé avec le résultat failed, l’asset porte la destination choisie, la page de détail affiche un badge Failed, et le grading devient optionnel. Sans grade et avec une disposition autre que resale, l’asset reste en dehors du stock vendable.
Les notes et les photos appartiennent à l’asset
Une note ou une photo ajoutée dans l’onglet Notes et photos est enregistrée sur l’asset immédiatement — les mêmes notes et la même photo library que celles du record inventory — sous le nom de l’utilisateur connecté. Elle survit à un reload, apparaît sur le détail inventory et voyage dans l’evidence package. Supprimer demande une confirmation, et le message de succès n’apparaît qu’une fois que le serveur l’a enregistrée. Un onglet de preuves qui jette des preuves n’a rien à faire dans l’app.
Qui teste
L’écran de testing est ouvert aux rôles administrateur, manager, entrepôt et opérateur. Opérateur est le rôle par défaut sur une invitation et celui qui fait réellement les tests, d’où la clé de la porte.
Productivité
/core/testing/productivity est la vue opérations : throughput, un tableau par catégorie, et l’activity log. Le team lead peut répondre à « combien de laptops avons-nous testés le mois dernier » depuis la page, au lieu d’en faire un comptage manuel.