A few years into this job, I noticed a pattern in myself that I didn’t like.
Every sprint ended the same way. Devs wrapped up their tickets with a day or two to spare. QA got the build the night before the deadline, tested until midnight, and still got asked in standup the next morning why ‘testing is taking so long.’
I started answering that question by working faster. Skipping lunch. Testing on weekends ‘just to catch up.’ For a while it worked, in the sense that releases went out on time. It did not work in the sense that I was quietly burning out. I told myself it was a discipline problem, that a better tester would just manage their time.
It wasn’t a discipline problem. It was a structural one, and I only saw that once I stopped being the one drowning in it.
The Math Was Never in Our Favor
Here’s the part nobody says out loud in planning meetings: QA is almost always the last stage before release, and almost always the stage asked to compress when everything upstream ran late.
A feature can slip a week in development and nobody blinks. It just becomes ‘in progress’ for another sprint. The same feature slipping a day in QA becomes a release risk. Testing doesn’t get more time when development takes longer. It gets less, because the deadline doesn’t move and someone has to absorb the overrun.
I’ve sat in enough retros to know this isn’t unique to any one team. It’s structural. If testing is positioned as the last gate rather than a continuous activity, it will always be the shock absorber for every other team’s schedule slip.
‘We’re Agile, We Don’t Need Dedicated Testers’
I’ve heard some version of this sentence more than once, usually from someone who genuinely believes it, not someone being dismissive. The logic sounds reasonable: agile teams move fast, developers write their own tests, quality is ‘everyone’s responsibility.’
In practice, ‘everyone’s responsibility’ quietly becomes ‘no one’s responsibility’ the moment there’s schedule pressure. Developers under a deadline write tests for the happy path and ship. Edge cases, regression risk, and the parts of the system nobody remembers the reasoning behind: that’s what a dedicated tester actually covers. Cutting that role doesn’t remove the work. It just removes the person who was doing it, and the gap shows up in production a few weeks later, attributed to something else entirely.
I’m not precious about the word ‘QA’ in a job title. I am precious about someone, anyone, being explicitly accountable for the boring, unglamorous parts of quality that don’t fit neatly into a single developer’s sprint ticket.
Flaky Automation Makes It Worse, Not Better
Automation is supposed to buy testers time back. In a lot of teams I’ve seen (including my own, before we fixed it), it does the opposite.
A suite full of tests nobody trusts doesn’t reduce manual work. It adds a new job: babysitting reruns, triaging red builds that turn out to be nothing, explaining to devs why they should ignore the failure that’s blocking their merge. That’s pure overhead layered on top of the actual testing work, and it’s invisible in any velocity metric. Nobody puts ‘reran the flaky suite four times’ in a sprint report.
If your test suite is unreliable, your headcount problem is worse than it looks on paper, because a chunk of the QA capacity you think you have is actually going toward maintaining false confidence.
What Actually Changed Things for Us
Not a wellness webinar. Not ‘just say no’ advice, which sounds good and is nearly impossible to act on when you’re one person in a room full of people who’ve already agreed to a date. What actually moved the needle were boring structural changes:
- Testing entered the sprint at the same time as development, not after, so it wasn’t racing a deadline set by someone else’s estimate
- A shared definition of done that explicitly included test coverage, so ‘done’ from a dev’s side and ‘done’ from QA’s side stopped being two different finish lines
- We killed flaky tests instead of tolerating them, which sounds unrelated to burnout until you realize how much invisible labor a broken suite creates
- Someone above us started asking ‘did QA have enough time?’ as a standing question in planning, not an afterthought when something broke
None of this required more people. It required treating testing as a scheduling input instead of a buffer that silently absorbs everyone else’s delays.
The Reframe That Helped Me Personally
For a long time I measured my own performance by how much pressure I could absorb without anything breaking. That’s a losing game: the pressure has no ceiling, and it will always expand to fill whatever capacity you’re willing to give it.
The question isn’t ‘can I handle more?’ It’s ‘why does this keep landing on me, and what would have to change so it doesn’t?’
That second question is uncomfortable because it points at process, not effort. But effort was never the actual bottleneck. I could not work hard enough to fix a schedule that structurally assumed QA would compress.
Final Thought
If you’re a tester reading this and recognizing yourself in it: it is not a personal failing that the current process runs you into the ground. Burnout in this field is common enough, and predictable enough in its causes, that it’s a systems problem wearing an individual costume.
You can’t fix a structural problem by trying harder inside it. You can only fix it by naming it out loud, to the people who control the schedule, and asking them to change the structure instead of asking you to absorb more of it.