The ROI filter — automate when
- It runs often (regression, smoke, every release)
- The feature is stable (not redesigned every sprint)
- A miss is costly (payments, login, checkout)
- Score = frequency × stability × cost-of-failure
Keep it manual
- Exploratory testing — judgment can't be scripted
- One-time verifications (migrations, hotfix checks)
- Rapidly changing UI — wait for the churn to settle
- Subjective checks: looks right? feels smooth?
- Captcha / anti-bot — designed to defeat you
The test pyramid
/\ UI / E2E — few, slow, fragile
/ \
/----\ API / integration — some, fast
/ \
/--------\ Unit tests — many (developers)
You work in the top two layers.Manual case -> automated test
1. Go to login page -> driver.get(url)
2. Enter credentials -> sendKeys(...)
3. Click Sign in -> click()
Expected: dashboard shown -> assertTrue(...)
The Expected Result column IS the assertion.
Vocabulary in 20 seconds
regression = re-check existing behavior after changes
smoke = tiny critical-path suite, every build
E2E = full user journey through the real UI
flaky = passes/fails randomly -> trust killer
coverage = % touched -> measures quantity, not value
Say this in the interview
- "I automate by ROI: frequency × stability × cost of failure"
- "I keep UI suites small and push checks down the pyramid"
- "Exploratory stays human — scripts only check what you predicted"
- "A trusted small suite beats a big flaky one"
Anti-patterns
- Automating everything — flaky big suite < trusted small suite
- Translating manual cases 1:1 — automate shorter + sharper
- Chasing 100% coverage — risk-based selection wins