Testing-Templates & Grading-Regeln: was der Tester sieht

Die Test-Checkliste, die ein Tester durchgeht, und die Regeln, die aus den Klicks einen Grade machen, sind nicht hart verdrahtet. Beides liegt in den Tenant-Einstellungen, mit Platform-Defaults als Fallback. /settings/core/testing/templates ist der Editor; /settings/core/testing ist die Übersicht davor, mit Gesamtvolumen im Testing, offenen Items, heute getesteten und gegradeten Items, aktiven Testern, dem ältesten offenen Item, den Queue-Zuständen pending, in progress, tested und graded sowie den Prioritäten low, normal und high. Die Übersicht ist zur Hälfte Management-Dashboard und zur Hälfte Tür.

Eine Seite, drei Bereiche

Die Templates-Seite zeigt alles ohne Tabs: Templates links, Auto-Grade-Regeln rechts, Grades in voller Breite darunter. Hat der Tenant nie einen Override gespeichert, sagt ein Banner, dass die Konfiguration geerbt ist; die erste Speicherung erzeugt tenantspezifisches Test- und Grading-Verhalten, und das Banner verschwindet. Die Operations-Leitung weiß dadurch immer, ob die Halle auf Defaults läuft oder auf den eigenen Regeln des Tenants.

Test-Checklisten-Templates

Jede Gerätekategorie hat ein Checklisten-Template: die Tests, die der Tester ausführt, welche davon Pflicht sind, und ein Label und eine Beschreibung pro Test. Laptops bekommen Battery Health, Bildschirm, Tastatur, Ports und Boot; Server bekommen RAID, Speicherbänke, Netzteilredundanz und Netzwerk-Link; Telefone bekommen Kamera, Ladebuchse und Lautsprecher. Ihr Team wählt eine Kategorie, aktiviert das Template, ergänzt oder entfernt Tests, markiert Tests als Pflicht und bearbeitet Labels und Beschreibungen. Schreiben Sie Anweisungen für Techniker in die Beschreibung, nicht ins Label, und halten Sie Pflichttests wirklich verpflichtend — ein optionaler Test, den alle überspringen, ist eine Checkbox und keine Prüfung.

Grade-Kriterien

Der Bereich Grades enthält die Kriterien pro Dimension: funktionaler Zustand, kosmetischer Zustand, Batteriezustand, Data-Security-Zustand und die Gesamtgrade-Linien A bis F. Die Schwellen selbst sind Grade-Bänder — für functional, cosmetic und battery besitzt jeder Grade eine minimale und eine maximale Defect-Gewichtsspanne, konfiguriert unter /settings/core/grading-rules. In den Defaults ist eine Batterie mit Gewicht 1–20 ein B2 Acceptable und 21–50 ein B1 Low Health. Es gibt keine prozentualen Gewichtungen zwischen den Dimensionen und keine versteckte Floor-Regel. Die Bänder sind die ganze Geschichte, und deshalb kann ein Käufer sie lesen und ein Tester sie vorhersagen.

Auto-Grade-Regeln

Auto-Grade-Regeln sind die geordneten First-Match-Vorschläge, die die Engine aus dem Ergebnis der Checkliste und dem Batteriewert ableitet: ein fehlgeschlagener Auto-Fail-Test schlägt F0 vor, alle Pflichttests bestanden und kein Fehlschlag schlägt F3 vor, eine Batterie ab achtzig Prozent schlägt B3 vor. Ihr Team kann Regeln ergänzen, entfernen, umsortieren und ihre Werte anpassen. Der Vorschlag bleibt ein Vorschlag; den Grade bestätigt der Tester.

Wer testet

Der Testbildschirm steht Administrator, Manager, Lager und Operator offen. Operator ist die Standardrolle einer Einladung und die Rolle, die die Testarbeit macht, sodass jemand am Montag eingeladen werden und am Montagnachmittag graden kann.

Warum zwei Ebenen

Verschiedene Märkte haben verschiedene Definitionen. Ein Broker, der nur refurbished Consumer-Laptops verkauft, braucht andere Regeln als ein Recycler, der für Teile kauft. Das Zwei-Ebenen-System — Platform-Defaults, Tenant-Override — lässt die Plattform sinnvolle Defaults ausliefern, während jeder Tenant auf seine Realität nachjustiert. Ändern Sie Bänder mitten in einer Charge erst, nachdem Sie es der Halle gesagt haben; die App wendet die Regel an, die Menschen müssen trotzdem verstehen, warum das heutige B wie das gestrige C aussieht.