Skip to content

The Uncomfortable Truth

Many QA professionals wait too long to start automating tests. And the reason is not because they lack the ability to do it, but mostly the delay is due to the fact that they keep on waiting for a version of their work environment that rarely materializes into reality.

The most common arguments are:

  • “I’ll start automating when the project is more stable”;
  • “I need to understand the product better”;
  • “There is not enough time right now”;
  • “We need a proper framework before jumping in automating test cases”.

If you analyze them individually, they are not absurd, they are valid reasons. But collectively, they create a loop where automation is postponed and it always becomes next quarter’s problem.

So, the question remains:

When Should a QA Start Automating?

First, let’s see what delaying automation due to what originally were considered valid reasons, hides:

  • Manual regression keeps growing
  • Releases slow down slightly, then noticeably
  • Test cycles become repetitive, but “manageable”

Nothing is broken enough to force change.

So automation gets positioned, once again, as:

  • A “nice to have”.
  • A “future improvement”.
  • Or worse, a “big initiative” that requires perfect conditions.

And that framing is the problem.

There’s an implicit belief that automation has a proper starting point:

  • After the product stabilizes
  • After the team hires the right people
  • After the framework is designed
  • After deadlines calm down

But in reality, those conditions rarely align.

Projects don’t suddenly become stable – they evolve.
Deadlines don’t disappear – they shift.
Teams don’t feel ready – they adapt under pressure.

So if automation depends on ideal conditions, it simply doesn’t start.

Without realizing it, many QAs end up optimizing for short-term efficiency:

  • It’s faster to run the test manually this time.
  • It’s easier to re-check something than to automate it properly.
  • It feels safer to stay within known tools and workflows.

And that logic works – temporarily.

But over time:

  • Repetition increases.
  • Cognitive load builds up.
  • The same effort produces less impact.

The work doesn’t get harder – it gets heavier.

So, instead of asking “When should you start automating?” you should shift to “What is the cost of continuing without it?”. This shifts the conversation from readiness to trade-offs:

  • Comfort today vs. growth over time
  • Time spent repeating vs. time invested once
  • Stability now vs. scalability later

So if the signals are already there – repetition, slowdowns, growing effort – why do so many QAs still hesitate to start?

The Real Blocker

In the beginning of my QA career, I caught myself thinking “I’ll start automating tests when I feel ready“, and I know of other colleagues who had the same thoughts throughout their career. But what does ready really mean?

For me, it meant being able to handle an entire automation effort on my own: designing the framework, writing the tests and setting up pipelines.

Looking back, that expectation was unrealistic. I was setting the bar at a level that only comes after you already have experience—not before.

And that’s where the real blocker hides.

It’s not lack of opportunity.
It’s not even lack of time.
It’s defining “ready” as a point where failure is no longer likely.

So the question becomes: if you’re expecting yourself to already be good at something you’ve never done before, how do you ever begin?

Part of the answer is adjusting that definition.

Starting automation doesn’t mean building a perfect framework.
It means writing your first imperfect test.

It means:

  • not fully understanding what you’re doing
  • getting stuck
  • asking questions
  • rewriting things that don’t work

That’s not failure – that’s the process.

There’s also a social side to this hesitation.

Many QAs worry about:

  • how their code will look to developers
  • whether they’re asking “basic” questions
  • being judged for not knowing enough

But in reality, most teams don’t expect perfection from someone starting out. And the ones that do, have bigger problems than your first test script.

Progress in automation doesn’t come from avoiding mistakes.
It comes from accumulating them – and understanding them.

So instead of asking “What if I fail?”, a more useful question is “What exactly am I losing if I try?”.

Where to Start (without Overwhelming Yourself)

Once you move past the idea that you need to feel ready, a different question shows up – and it’s just as paralyzing: “Where do I even begin?“

Automation has a way of feeling bigger than it actually is. Frameworks, tools, languages, pipelines – it all shows up at once, and it creates the impression that you need to understand everything before doing anything.

In reality, that’s rarely how anyone starts.

A much more effective approach is to shrink the problem to something almost trivial. Instead of thinking about “automation” as a whole, think about a single test you already know by heart. A flow you’ve executed so many times that you no longer need to think about it. Something stable, predictable, almost boring.

That’s your entry point.

Not because it’s impressive, but because it removes variables. You’re not learning the product and automation at the same time – you’re just learning how to translate something familiar into code.

If your current project allows it, start there. Pick one simple scenario, automate it locally, and see what breaks. Don’t worry about pipelines, don’t worry about structure, don’t worry about whether it’s “the right way”. At this stage, the only thing that matters is making the connection between manual and automated.

And if your project doesn’t give you that space – because things are too chaotic, or there’s no support – that’s fine too. A small personal project works just as well. In some ways, even better. It removes pressure and lets you experiment without consequences.

What tends to slow people down here isn’t complexity – it’s over-ambition. There’s a strong temptation to start by building a proper framework, to get the architecture right from the beginning, to do things “as they should be done”.

But that’s just another form of delaying the real work.

You don’t need a framework to write your first test.
You need a starting point that’s small enough that you can’t overthink it.

A Practical Technical Mindset

You don’t need to think like a developer to start automation – but adopting a few principles early will save you frustration later.

Prioritize readability over cleverness.

Your tests should be easy to understand, even if they’re not elegant. Anyone, your future self included, should be able to quickly see what the test does, what it verifies, why it failed. If you can tick these boxes, you’re on the right track.

Accept that your first solutions won’t scale.

And that’s fine. Trying to build something “future-proof” too early often leads to: unnecessary complexity, harder debugging and slower progress.
Your first automation work is not your final system. It’s your learning ground.

Be careful with flaky tests

There are a few things that damage trust in automation faster than unreliable tests, and those are when a test: fails randomly, depends on unstable data, or breaks for unclear reasons.

It’s better to have fewer reliable tests than many questionable ones.

Common Mistakes That Slow You Down

Most QAs don’t struggle because automation is too difficult.
They struggle because they unknowingly take paths that make it harder than it needs to be.

Waiting to “learn enough”

You can spend months watching tutorials and still feel unprepared. And you’ll experience this feeling throughout your career – the more you learn on a topic, tool, programming language, the more you realize that it’s just the tip of the iceberg, and that’s fine.
Automation is learned by doing, not by preparing endlessly. So make sure that you also practice what you’re learning.

Copy-pasting without understanding

It’s tempting to reuse frameworks or snippets from others, or use AI tools to write the code for you.
But if something breaks and you don’t understand why, you’re stuck or even worse, you can make your framework vulnerable from a security point of view.
Use external resources – but treat them as learning tools, not shortcuts.

Automating the wrong things

Not everything should be automated. Avoid automating test cases designed for highly unstable features, tests that change frequently or edge cases with little long-term value.

Start with tests that are stable, repeatable, meaningful. Your regression suite is a good starting point to look for candidates.

Measuring the wrong success

More tests ≠ better automation. A few well-chosen tests that catch real issues are far more valuable than a large suite nobody trusts.

What Success Looks Like in QA Automation

There’s a subtle but important shift that needs to happen.

Automation is often seen as a role upgrade – “I want to become an automation QA”, but a more useful perspective is – “I want to become a QA who solves problems more effectively”.

Automation is just one of the tools that helps you do that.

Success is not represented by building a perfect framework, knowing every tool or writing hundreds of tests.

Success looks like: reducing repetitive work, increasing confidence in releases, freeing up time for in-depth testing. And, over time, making your work more sustainable.

Closing Thoughts

There’s rarely a clear moment when you feel fully ready to start something new.

Automation is no different.

The moment usually looks like:

  • a test you’ve run too many times.
  • a task that feels unnecessarily repetitive.
  • a small frustration you’ve learned to tolerate.

That’s your signal.

You don’t need a perfect plan.
You don’t need full confidence.

You just need to start small – and accept that figuring things out is part of the job.

The best time to start automating was when the repetition began.