🧭 When to Automate, When Not To

When to Automate, When Not To: It makes sense to use GPS every day on your commute to work — the route is fixed, and GPS repeatedly tells you the most efficient order over time.

It makes sense to use GPS every day on your commute to work — the route is fixed, and GPS repeatedly tells you the most efficient order over time. But blindly trusting GPS down a narrow alley you've never been to before is risky — that requires your own observation (a closed sign, noticing the street is one-way). So why are both "correct" approaches? Because GPS (automation) exists for REPEATED, predictable routes; your observation (manual/exploratory testing) exists for NEW and uncertain situations. In Java this resembles the difference between a pre-written unit test suite (automation) and manually debugging a new feature (exploration) — both are necessary, just at different times. In QA engineering, the real cost of getting this distinction wrong is this: if you automate a feature too early, before it has settled, your test breaks with every small UI change, and you spend your time FIXING the test instead of finding real bugs.

🎬 A New Feature's First Day

Behavior Still Changing

A feature ships for the first time — nobody yet knows all the questions to ask about it.

A human explores it: tries unexpected inputs, pushes boundaries, asks "what if I do this?". This is something a script cannot YET do.

In the first weeks the feature may still be changing — text shifts in the UI, the flow gets small tweaks. Automation written at this stage BREAKS with every change.

A few releases later, behavior stabilizes — the UI and flow rarely change anymore.

THIS is exactly the right time to automate — a script that checks stable behavior over and over, without a human getting tired.

Decision Order: Automate or Stay Manual?

Is this check asked every release, or just once? If once, automation is wasted effort.

Is the behavior stable?

If the UI/flow is still changing fast, the script you write breaks next release — wait for it to stabilize first.

Is it a visual/subjective judgment?

Subjective questions like "does this design look good?" are not suited to automation — they need a human eye.