DEV Community: Lucas Ferreira

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

Lucas Ferreira — Sun, 05 Jul 2026 16:38:02 +0000

Back to Feedback — Episode 2 of 20

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

Set a fixed timebox for manual testing before opening the automation editor. Define the time. Honor it. Only then move to code.
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.
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.
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."
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.

Episode 01: The Knowledge I Kept to Myself Helped No One

Lucas Ferreira — Tue, 23 Jun 2026 01:51:40 +0000

Back to Feedback — Episode 1 of 20

This is the first post in a series I've been building for a while: Back to Feedback. The premise is simple — take four years of real performance review feedback and turn each recurring pattern into a practical lesson for software quality professionals. No theory. Just "here's what actually happened, and here's what I did about it."

I'm starting with the pattern that, in hindsight, sits at the root of almost everything else: knowledge sharing.

Where it came from

This one showed up across multiple review cycles, in different words, from different people. The first time, it came as a gentle nudge — something along the lines of "you could inspire others to do what you're doing." Later, a technical talk I gave on quality metrics was specifically called out as a positive example. But also as a one-off. Something that happened once and didn't become a habit.

The clearest signal came when the same colleague gave me the same advice in two separate review cycles, one year apart: "share your automation ideas more." That's not a coincidence. That's a pattern I wasn't seeing.

Where I went wrong

I did share knowledge — reactively. Someone would ping me with a question, I'd help. Someone would get stuck, I'd explain. What I didn't have was a proactive, recurring practice of transferring what I knew — partly because I was on a team of Senior engineers, and I assumed they probably already knew most of what I knew, since we were at the same level.

The practical result: knowledge I had accumulated stayed with me. The team depended on finding me, rather than having asynchronous access to what I'd already solved, documented, or learned. I wasn't hoarding anything deliberately — I just hadn't understood that withholding knowledge by omission has the same effect as withholding it by intention.

What I learned

Knowledge that only lives in your head isn't a team asset. It's a team risk.

That sentence sounds harsh, but it's literally true: if only one person knows how to handle a specific type of problem, the whole team becomes vulnerable whenever that person is unavailable — in a meeting, on vacation, or after they leave. Centralizing knowledge without meaning to is still a single point of failure.

The subtler lesson took longer to absorb: being a technical reference doesn't mean knowing the most. It means making the team know more. When I gave that metrics talk, the recognition I received came from people who rarely gave me feedback in day-to-day work. That told me something important — the visibility of your knowledge creates recognition that raw competence alone never will.

How to fix it

The solution isn't "be more generous" or "try to share more." That's an intention, not a system, and intentions collapse under the weight of a busy sprint.

What works is building a fixed cadence for sharing, across different formats and frequencies: something lightweight and weekly (a short post in the team channel), something more structured monthly (a talk or a write-up), and something quarterly aimed outside the immediate team (a public post, like this one). When sharing becomes a routine, it stops depending on motivation or memory — it just happens.

The 5 practical steps

Create a fixed space for weekly learnings. Pick a channel or thread and post one thing you learned that week — no matter how small it seems. The format matters less than the consistency.
Document before moving on. Every time you learn a new tool, technique, or process, write a short summary of "what I learned and how I applied it" before switching to the next problem. This turns individual learning into reusable material for everyone.
One technical session per semester. Pick a topic your team doesn't fully own yet and propose a short session — even 15 minutes is enough. The goal isn't a polished presentation. It's knowledge transfer.
Publish externally, monthly. Turning real work situations into public content (like this series) forces you to structure what you've learned in a way others can actually use — and creates a visible record of your growth over time.
Build a shared reference repository. Keep an organized space — a shared doc, a wiki, a code repo — with templates, scripts, and checklists that any teammate can access without having to ask you first. The goal is removing yourself as the bottleneck.

None of these require exceptional talent. They require only one thing I didn't have: scheduled repetition.

📚 Further reading

Building a Second Brain (Tiago Forte) — a practical system for capturing and organizing knowledge so it stays accessible later, not just in your memory at the moment you learned it.
Ultralearning (Scott Young) — useful for understanding how to structure your own learning so it's ready to be taught to others from the start.
Atomic Habits (James Clear) — the theoretical foundation for turning "share knowledge" from an intention into an automatic routine.
The Power of Habit (Charles Duhigg) — explains why systems beat willpower, especially for behaviors that require consistent repetition.
Show Your Work! (Austin Kleon) — the central argument of this book is exactly this: making the process visible — not just the final result — is what builds recognition and reputation over time.
The Knowledge-Creating Company (Ikujiro Nonaka & Hirotaka Takeuchi) — a classic reference on how organizations (and individuals within them) convert tacit knowledge into shared knowledge.

What do you know today that your team doesn't know you know?

This was episode 01 of the Back to Feedback series.

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