Testing Templates & Grading Rules: What the Tester Sees

The test checklist a tester walks through and the rules that turn the picks into a grade aren’t hard-coded. Both live in tenant settings, with platform defaults as the fallback. /settings/core/testing/templates is the editor; /settings/core/testing is the overview that sits in front of it, with total testing volume, open items, items tested and graded today, active testers, the oldest pending item, the queue states pending, in progress, tested and graded, and the priorities low, normal and high. The overview is half management dashboard, half door.

One page, three sections

The templates page shows everything without tabs: Templates on the left, Auto-grade rules on the right, Grades full-width underneath. If the tenant has never saved an override, an inherited-configuration banner says so; the first save creates tenant-specific testing and grading behavior, and the banner goes away. The operations lead always knows whether the floor is running on defaults or on the tenant’s own rules.

Test checklist templates

Each device category has a checklist template: the tests the tester runs, which are required, and a label and description per test. Laptops get battery-health, screen, keyboard, ports and boot checks; servers get RAID, memory banks, power redundancy and network link; phones get camera, charging port and speaker. Your team picks a category, enables the template, adds or removes tests, marks tests required and edits the labels and descriptions. Put technician instructions in the description, not in the label, and keep required tests genuinely required — an optional test that everyone skips is a checkbox, not a check.

Grade criteria

The Grades section holds the criteria per dimension: functional condition, cosmetic condition, battery condition, data-security condition and the overall grade lines A to F. The thresholds themselves are grade bands — for functional, cosmetic and battery, each grade owns a minimum and maximum defect-weight range, configured at /settings/core/grading-rules. In the defaults a battery with weight 1–20 is B2 Acceptable and 21–50 is B1 Low Health. There are no percentage weightings between the dimensions and no hidden floor rule. The bands are the whole story, which is why a buyer can read them and a tester can predict them.

Auto-grade rules

Auto-grade rules are the ordered, first-match suggestions the engine makes from the checklist outcome and the battery reading: an auto-fail test that failed suggests F0, all required tests passing with no failures suggests F3, a battery at eighty percent or better suggests B3. Your team can add rules, remove them, reorder them and patch their values. The suggestion is a suggestion; the tester confirms the grade.

Who tests

The test screen is open to admin, manager, warehouse and operator. Operator is the default role on an invitation and the role that does the testing work, so a new hire can be invited on Monday and grading by Monday afternoon.

Why both layers

Different markets have different definitions. A broker who only sells refurbished consumer laptops needs different rules than a recycler who buys for parts. The two-layer system — platform defaults, tenant override — lets the platform ship sensible defaults while each tenant tunes to its reality. Change bands mid-batch only after telling the floor; the app applies the rule, the people still have to understand why today’s B looks like yesterday’s C.