Testing Productivity: Throughput Without Guesswork

Testing is where ITAD promises become measurable. A device is not “probably fine”; it has checks, defects, grades, erasure state and a next step. The productivity view exists because a full testing bench can look busy while the wrong work is getting stuck.

What the page shows

/core/testing/productivity summarizes the bench from real testing records, in three tabs: overview, testers and activity. The headline tiles give items tested today, this week and over 30 days, the average time per item, the overall pass rate, how many testers are active now and how many items are still pending in the queue. Below that sits a week-over-week comparison of throughput and average test time, a fourteen-day chart of daily throughput split into passed and failed, performance by device category, and a recent-activity feed of who started testing, completed testing or completed grading, with the result and the grade.

How to read it

A high completed count is good only when the queue is also moving and defect-heavy work is not being avoided. A rising average time can mean a hard category, missing templates, blocked erasure evidence or too many interruptions. The failed line on the throughput chart includes devices closed with “Complete as failed”, so a bad week for a supplier shows up as a bad week for that supplier rather than as a quiet dip in throughput. The chart is a conversation starter, not a stick with a dashboard theme.

Where it fits

The view sits next to the testing queue and asset-level test records. Use it for daily standups, staffing checks and process questions; it is built for team leads, while technicians mostly live in the queue and the detail screens. Open the underlying assets before making a decision; charts are excellent at pointing, terrible at carrying context alone.