Testing & Defects: Codes, Zones and Severities Instead of Adjectives
How structured defect tracking replaces “minor cosmetic” with codes the buyer in Munich and the supplier in Copenhagen agree on.
“Grade B cosmetic” only works when everyone means the same thing by it. Defect tracking makes the tester pick from a structured list rather than describe the damage in prose, so the buyer in Munich and the supplier in Copenhagen read the same signal.
The structure
A defect is a code — LCD-03 for a shattered screen, SCR-01 for light scratches — with a category (cosmetic, functional, battery, data, missing part), a severity (minor, moderate, major or critical, each with a weight factor) and the body zones where it can occur, out of seventeen: lid, screen, keyboard, palmrest, bottom cover, ports, hinges and the rest of the anatomy. Some codes require a photo. The platform ships 38 stock codes, your organization can seed a set of tenant defaults on top, and Settings > Core > Fault codes is where you add the codes your own bench keeps needing.
The testing detail page
/core/testing/[id] is where the tester works, in four tabs. Testing holds the category-specific checklist — pass or fail per item, defect notes, pass all, reset, save progress, complete. Grading holds functional, cosmetic, battery, data, the overall letter and the disposition; the defect picker there filters by category, the engine suggests the functional and battery grades from the checklist and the battery reading with an Apply suggestion button for each, and the tester chooses the overall grade from A to F. Notes & photos and History complete the set. Completion is blocked while required checks or grade fields are missing. That is only annoying until it stops “probably fine” from shipping as “tested”.
The queue and the detail header show the inbound order number the asset arrived under — or its asset tag when there is no order — never the internal ID of the queue item. Nobody on the floor has ever asked a colleague about item 4f8a-c2.
Complete as failed
A required test set to fail can never unlock “Complete testing”; the button stays disabled on purpose. Instead, once at least one required test has failed, the page offers Complete as failed (on mobile, the primary button itself becomes that). The tester chooses a destination — recycle and harvest parts, scrap, or return to the client — and gives a reason of at least ten characters. Resale is not on that list: a failed device does not enter sellable stock by this door. Repairable machines stay in the queue, get repaired, and are tested again. After confirmation the item is tested with result failed, the asset carries the chosen destination, the detail page shows a Failed badge, and grading becomes optional. With no grade and a disposition other than resale, the asset stays out of sellable stock.
Notes and photos belong to the asset
A note or photo added on the Notes & photos tab is saved on the asset immediately — the same notes and photo library the inventory record uses — under the name of the logged-in user. It survives a reload, shows on the inventory detail, and travels into the evidence package. Deleting one asks for confirmation, and the success message appears only after the server has stored it. An evidence tab that throws away evidence does not belong in the app.
Who tests
The testing screen is open to admin, manager, warehouse and operator. Operator is the default role on an invitation and the role that does the actual testing, which is why it has the door key.
Productivity
/core/testing/productivity is the operations view: throughput, a table per category, and the activity log. The team lead can answer “how many laptops did we test last month” from the page instead of turning it into a manual tally.