Testing templates & grading rules : ce que voit le testeur

La test checklist qu’un testeur parcourt et les règles qui transforment ses choix en grade ne sont pas codées en dur. Les deux vivent dans les paramètres tenant, avec les valeurs par défaut de la plateforme comme repli. /settings/core/testing/templates est l’éditeur ; /settings/core/testing est l’aperçu qui se tient devant, avec le volume total de testing, les items ouverts, les items testés et gradés aujourd’hui, les testeurs actifs, l’item en attente le plus ancien, les états de file en attente, en cours, testé et gradé, et les priorités basse, normale et haute. L’aperçu est moitié tableau de bord de gestion, moitié porte d’entrée.

Une page, trois sections

La page templates montre tout sans onglets : Templates à gauche, Auto-grade rules à droite, Grades sur toute la largeur en dessous. Si le tenant n’a jamais enregistré d’override, une bannière de configuration héritée le dit ; le premier enregistrement crée un comportement de testing et de grading propre au tenant, et la bannière disparaît. Le responsable des opérations sait toujours si l’atelier tourne sur les valeurs par défaut ou sur les règles du tenant.

Test checklist templates

Chaque catégorie d’appareil a un template de checklist : les tests que le testeur exécute, ceux qui sont obligatoires, et un libellé et une description par test. Les laptops ont des contrôles santé batterie, écran, clavier, ports et démarrage ; les serveurs ont RAID, barrettes mémoire, redondance d’alimentation et lien réseau ; les téléphones ont caméra, port de charge et haut-parleur. Votre équipe choisit une catégorie, active le template, ajoute ou retire des tests, marque des tests comme obligatoires et modifie les libellés et descriptions. Mettez les instructions pour le technicien dans la description, pas dans le libellé, et gardez les tests obligatoires réellement obligatoires — un test optionnel que tout le monde saute est une case à cocher, pas un contrôle.

Critères de grade

La section Grades contient les critères par dimension : état fonctionnel, état cosmétique, état de la batterie, état de sécurité des données et les lignes de grade global A à F. Les seuils eux-mêmes sont des grade bands — pour functional, cosmetic et battery, chaque grade possède une plage de poids de défauts minimum et maximum, configurée sur /settings/core/grading-rules. Dans les valeurs par défaut, une batterie de poids 1 à 20 est B2 Acceptable et de 21 à 50 est B1 Low Health. Il n’y a ni pondération en pourcentage entre les dimensions ni règle de plancher cachée. Les bandes sont toute l’histoire, et c’est pour cela qu’un acheteur peut les lire et qu’un testeur peut les prédire.

Auto-grade rules

Les auto-grade rules sont les suggestions ordonnées, à première correspondance, que le moteur tire du résultat de la checklist et de la mesure de batterie : un test auto-fail en échec suggère F0, tous les tests obligatoires réussis sans aucun échec suggère F3, une batterie à quatre-vingts pour cent ou plus suggère B3. Votre équipe peut ajouter des règles, en retirer, les réordonner et corriger leurs valeurs. La suggestion reste une suggestion ; c’est le testeur qui confirme le grade.

Qui teste

L’écran de test est ouvert aux rôles administrateur, manager, entrepôt et opérateur. Opérateur est le rôle par défaut d’une invitation et celui qui fait le travail de testing, si bien qu’une nouvelle recrue peut être invitée le lundi et grader le lundi après-midi.

Pourquoi deux couches

Des marchés différents ont des définitions différentes. Un broker qui ne vend que des laptops grand public reconditionnés a besoin d’autres règles qu’un recycler qui achète pour pièces. Le système à deux couches — valeurs par défaut plateforme, override tenant — permet à la plateforme de livrer des défauts sensés tout en laissant chaque tenant se caler sur sa réalité. Ne changez les bandes au milieu d’un lot qu’après en avoir parlé à l’atelier ; l’app applique la règle, les gens doivent encore comprendre pourquoi le B d’aujourd’hui ressemble au C d’hier.