QA Dashboards: Building One People Still Open in Month Three
Every team builds a QA dashboard in the first month and stops opening it by the third. The charts aren't wrong — nobody ever decided what any of them was supposed to change.
8 posts
Every team builds a QA dashboard in the first month and stops opening it by the third. The charts aren't wrong — nobody ever decided what any of them was supposed to change.
A QA report that tries to serve the whole company serves nobody. The useful question isn't what to include — it's who is reading, what they'll do next, and whether the number will still say the same thing next month.
Almost every QA team starts in a spreadsheet, and most stay longer than they meant to. The interesting question isn't whether Excel is 'wrong' — it's which specific thing breaks first, and what you lose on the way out.
UAT has different testers, a different goal and a different output than QA testing. You rarely need a dedicated UAT feature to run it well — you need to know which ordinary parts to assemble, and where the fit genuinely stops.
Most defect workflows fail in one of two directions: too many states nobody maintains, or too few to answer 'who has this now?'. The interesting decisions are about ownership and handover, not the diagram.
"We're 80% executed" is the number everyone reports and almost nobody can act on. Tracking a cycle well means knowing what's left, who holds it, and which results aren't finished being results.
Test documentation isn't written for the person who wrote it. It's written for whoever runs it in eight months — and almost every decision about detail, structure and reuse follows from taking that seriously.
Every regression suite grows and almost none of them shrink. The management problem isn't writing the tests — it's deciding what belongs, what runs this cycle, and what to do about the ones nobody trusts.