Testing Productivity: Throughput Without Guesswork
How the testing productivity view shows queue health, operator pace, bottlenecks and the difference between busy and effective.
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 throughput, queue movement, completion pace, aging work and tester activity from real testing records. It helps an operations lead see whether the team is clearing the right work, whether a category is piling up, and whether retests are eating the day one quiet exception at a time.
How to read it
High completed count is good only when the queue is also moving and defect-heavy work is not being avoided. Slow P75 timing can mean a hard category, missing templates, blocked erasure evidence or too many interruptions. 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. Open the underlying assets before making a decision; charts are excellent at pointing, terrible at carrying context alone.