Episode 02: I Automated Before Testing. And Delayed the Delivery

Where it came from

This one showed up first as a passing comment from a teammate mid-year: I sometimes seemed to spend too long on automation before manual testing had even started. At the time, I brushed it off as a perception issue. By the next annual cycle, my lead had formalized it: agile efficiency and sense of urgency were the central development points for the year ahead. It wasn't perception. It was a pattern.

Where I went wrong

The logic felt solid: automate early, ensure coverage, make the process more robust. And it is a true logic - just applied in the wrong order. While I was building the automation suite, the task sat in Waiting QA. The developer was waiting. The sprint was moving. And when I finally delivered the test - full coverage, scripts running, evidence organized - time had already done its damage. The delivery had quality. The pace didn't.

What I failed to understand then: in a sprint context, feedback speed matters as much as coverage depth. A bug caught in manual testing on day one is worth more to the team than a complete suite delivered on day five. Automation serves validation - not the other way around.

What I learned

There's a difference between doing something well and doing it in the right order. I was doing it well. But the order was inverted. And in an agile context, order isn't a detail - it's strategy.

The right question isn't "how do I do this with more quality?" It's "what, done now, delivers the most value to this sprint?" Those are different questions. They have different answers. And for a long time I was answering the first one while thinking I was answering the second.

The other lesson was about external perception. When you're building automation infrastructure, the work is real, the effort is genuine - but whoever is watching from outside sees the ticket sitting still. They don't see the code growing. They don't see the scenarios being mapped. They see: Waiting QA, day three. Technical invisibility has a perception cost. And perception cost has a career cost.

How to fix it

The rule I adopted is simple: manual tests first, always. Automation starts only after the manual happy path is validated and the task is closed - or at least unblocked. That doesn't mean deprioritizing automation. It means sequencing it correctly: validation first, coverage after.

The timebox helps. When I define upfront how much time I'll spend on the manual phase before touching automation code, that limit becomes protection - against technical perfectionism, against the pull of the most interesting problem, against the tendency to build before validating.

The 5 practical steps

1. Set a fixed timebox for manual testing before opening the automation editor. Define the time. Honor it. Only then move to code.
2. Separate status on the board: "manually tested" and "automated" are different milestones. This makes progress visible to the team and prevents automation from blocking the task from being closed.
3. In planning: estimate manual testing and automation separately. When you split the estimates, you stop treating both phases as one - and start sequencing them for real.
4. Prioritize high business-impact tasks, not the technically interesting ones. The criterion for which task to pick up first shouldn't be "which automation will be most elegant" - it should be "what, if tested now, unlocks the most value for the sprint."
5. In the retrospective: review the ratio between automation time and manual testing time. Not to punish either - to calibrate. If the ratio is consistently skewed in one direction, it's worth understanding why.

📚 Further reading

• SCRUM: The Art of Doing Twice the Work in Half the Time (Jeff Sutherland) - The foundation of agile thinking on delivery speed and short feedback cycles.
• Essentialism (Greg McKeown) - For anyone who tends to do things well but in the wrong order: the book helps distinguish what is essential from what is merely interesting.
• The ONE Thing (Gary Keller) - The book's central question ("what's the one thing that, if done now, makes everything else easier or unnecessary?") is exactly the question that should guide task order in a sprint.
• The 80/20 Principle (Richard Koch) - On how a fraction of effort generates most of the results - and how to identify which fraction that is.
• The Deadline (Tom DeMarco) - A novel about project management that treats deadlines, quality, and sequencing with more humanity than any framework.

This episode isn't about automation being bad. It's about order. Automation done after manual validation is a multiplier. Automation done before is a bet - and an expensive one when the sprint has a deadline. The work kept being good. What changed was the sequence. And sometimes, changing the sequence is everything.

Back to Feedback is a series of 20 episodes based on real performance review feedback. Each episode turns a pattern identified over four years into a practical lesson for QA Engineers and tech professionals.

Previous episode: Episode 01 - The Knowledge I Kept to Myself Helped No One
Next episode: Episode 03 - coming soon.