Posts
Why Testing Is the #1 Retro Complaint (and It's Not Flaky Tests)

Matt Lewandowski
Last updated 19/07/20267 min read
29,015
testing & QA complaint cards
1 in 5
retros contain a testing complaint
0.9%
of them mention flaky tests
What's actually inside a testing complaint
QA as a function (capacity, handoffs)
23.9%
Automation and coverage gaps
8.5%
Test environments and test data
8.3%
Bugs escaping to production
4.9%
Regression testing
4.3%
Slow tests and CI
3.0%
No time to test
1.6%
Manual testing burden
1.4%
Flaky tests
0.9%
Rare complaints get the votes
- Flaky tests: 1.18 votes per card. The rarest sub-theme is the most voted, at nearly double the average. When someone finally writes the flaky-test card, the whole room piles on.
- Manual testing burden: 0.85. Few cards, strong agreement.
- Bugs escaping to production: 0.71. Above average, for obvious reasons.
Teams praise testing almost as much as they complain about it
The AI era hasn't moved the needle (yet)
What to do with this on Tuesday

- Fix when work reaches QA, not QA itself. Handoff timing is the most common thing written next to QA. Pulling testers into refinement and starting test design alongside development attacks the actual complaint. Our guide to writing acceptance criteria covers the clarity half of that problem.
- Treat the flaky-test card as an alarm. It's rare, and when it appears the room votes for it. That's the profile of a problem that's been quietly tolerated too long. Give it an owner and a date the same day; action items with an owner complete 2.7x more often.
- Don't let coverage complaints die of familiarity. Automation gaps are written constantly and voted on rarely, the classic profile of learned helplessness. If the same coverage card has appeared three retros running, it stopped being feedback and became a project.