Manual Tests vs. Automated UI Tests: Planning Them Separately, Not Sequentially

A note on how this came about: these are exploratory notes rather than a settled guide — written up from a back-and-forth working through the question rather than a from-scratch analysis, and treated here as a starting point for discussion rather than a fact sheet.

Automating manual tests after finalizing a feature

The question that started this: In a typical SDLC, test cases for manual tests get written during refinement. After development and manual testing wrap up, the team decides which manual tests could be replaced by automated UI tests. That sequencing feels a little off — a manually executed test case seems to operate on a different abstraction level, with a different focus, than an automated UI test. What’s the better approach, and what’s actually recommended here?

The instinct that something’s off is correct. Manual tests and automated UI tests serve different purposes and operate on different abstraction levels. Treating manual tests as a direct candidate list for automation after they’ve already been executed mixes those two worlds together, and it can lead to wrong automation priorities or just wasted effort.

Where they actually differ

Why “automate after manual testing” is the wrong sequence

• It risks automating tests that are valuable because they’re manual — exploratory paths lose their point once scripted.
• It misses the chance to design automation for robustness and maintainability, because manual test wording doesn’t always translate cleanly into automation.
• It produces retrofit automation instead of automation-by-design, which is usually the weaker outcome.

A better flow

Decide what should be automated at refinement time, or at the latest when development starts — not after manual testing is already done:

• Identify which paths are critical and which are stable enough to justify automation.
• Decide explicitly: this needs UI automation, that one stays manual.
• Write automation-specific acceptance criteria, or at least hints — “Automated UI test: log in as admin → create item → verify item in list.” Not every manual test maps 1:1 onto an automated one.
• After manual testing wraps up, use the findings to adjust the automation plan where something important surfaced — don’t derive the whole plan from those findings after the fact.

Think in layers while deciding: unit tests for business logic, API/integration tests for services and contracts, and UI automation reserved for what genuinely needs UI-level validation — actual user workflows, visual element presence. Keep automated UI tests focused and small; avoid one giant end-to-end test standing in for everything.

A practical transition

If a team already works the “decide after manual testing” way, evolving the process gently tends to work better than a hard cutover:

1. During refinement, explicitly ask: which tests do we plan to automate from the start, and does this make sense for UI automation or only manual testing?
2. During development, capture “automation notes” alongside tasks — candidates for UI tests, noted as they come up.
3. After manual testing, use the results only to catch gaps or refine the plan — not as the main source of automation decisions.

The short version: manual tests and automated UI tests should be planned separately, based on their different purposes and abstraction levels. Identify automation candidates during refinement, and use manual testing mainly to catch what automation planning missed — not as the primary source for deciding what to automate.

A lightweight workflow and checklist

The follow-up question: could this be sketched as a simple workflow diagram or checklist a team could actually adopt?

The workflow

1. During refinement

   • Review acceptance criteria.
   • Ask, for each story: what should be tested manually? What should be tested automatically, and at which layer — unit, API, or UI?
   • Tag work items accordingly: “needs UI automation,” “manual exploratory testing only,” “API test sufficient.”

2. During development

   • Developers add simple automation hints — “login flow needs UI automation.”
   • Where useful, sketch rough automation steps in technical notes.

3. During manual testing

   • Execute manual tests for exploratory behavior, UX quality, and edge cases that aren’t easily automated.
   • If manual testing surfaces important regressions or gaps, propose additional automation — don’t let this become the primary planning input.

4. After manual testing

   • Review the automation plan: confirm what was planned still makes sense, and add automation for genuine gaps — without automating everything blindly just because it was touched.

A checklist for work items

At refinement: Are acceptance criteria clear enough? Which paths should be automated? Is UI automation actually needed, or does unit/API testing cover it? Which parts genuinely require human judgment?

At development: Are automation candidates documented? Are stable IDs/selectors in place if UI tests are needed?

At manual testing: Were unexpected behaviors found? Do any findings require a new automated regression test?

Before closing the work item: Is the planned automation actually implemented, if agreed? Do manual tests cover whatever risk remains non-automatable?

The shape of it, visually

[Refinement] → [Decide: Manual vs Automation] → [Dev: Note Automation Hints]
   ↓                                    ↓
[Manual Test for UX/Edge Cases]      [Automation Implementation]
   ↓                                    ↓
[Review and Adjust Automation Plan] → [Done]

One phrasing tip worth keeping: phrase automation candidates differently than manual test cases. A manual test case might read “verify the UI color changes to green after success.” The automation candidate version: “validate success status is indicated visually, ignoring exact color unless it’s actually crucial.” Automation should target what matters, not copy-paste human steps into code.

A quick decision table

The next ask: a simple “automation decision table” for refinement — something like “if the feature is critical and the UI is stable, automate; otherwise, manual” — to keep discussions moving without turning into deep debates every time.

Scanned quickly: critical, stable, repetitive, and machine-checkable points toward UI automation. Non-critical, unstable UI, and something that needs human perception points toward manual testing.

Three rules of thumb for UI automation specifically: automate only the happy paths unless a specific bug demands otherwise; prefer many small tests over one giant end-to-end journey; invest in good selectors and avoid visual assertions unless they’re actually necessary.

A lightweight way to capture this during refinement:

Test Plan:
- Manual: Edge cases, UI polish verification
- Automated (UI): Basic workflow "Create item" → "Verify item listed"
- Automated (API): Validation of backend data storage

Writing it down this explicitly avoids the bigger decision discussion happening later, under more pressure.

Manual vs. automation-ready: the same feature, two styles

The last question in this thread: a small real-world example showing how a manual test case and an automation-ready test case differ in style for the same feature — often more illuminating side by side than in the abstract.

Example feature: “User can log in”

Manual test case:

Manual testers are free to also observe styling, loading times, typos, smoothness, and other usability factors along the way — that latitude is part of the point.

Automation-ready test case:

The difference, side by side

The key takeaway: manual test cases describe behaviors humans should validate intuitively. Automation test cases define technical facts that scripts can reliably assert. That’s why “automating a manual test” verbatim is usually the wrong move — the better path is writing purpose-built automation that focuses on technical validation, informed by but not copied from the manual version.