Why do teams automate tests, and what should not be automated?
What the interviewer wants to hear
- Fast, repeatable feedback on every change
- Supports frequent releases and regression testing
- Frees testers for exploratory work
- Do not automate one-off, unstable or purely visual judgement checks
- Automation has maintenance cost
Model answer
Automation gives fast, repeatable feedback. When tests run on every pull request in CI, developers learn within minutes that a change broke checkout, instead of finding out days later from manual regression. This makes frequent releases safe and lets manual testers spend time on exploratory testing, where humans add the most value. Automated tests also run the same way every time and can cover many data combinations. But not everything should be automated. Features that change every sprint, one-time checks, usability and visual design judgement, and tests that are very hard to make stable often cost more to maintain than they save. Every automated test has a maintenance cost, so I choose tests with high value and stable behaviour, and I prefer automating at the API or unit level when possible.
Can you answer it under time pressure?
Take a timed easy round and get scored on every answer.
More easy Automation Test Engineer questions
- Explain the Page Object Model and its benefits. Are there any downsides?
- What is the difference between implicit waits, explicit waits and auto-waiting?
- How do you run automated tests in a CI pipeline?
- When would you write an API test instead of a UI test?
- How do you choose locators for UI tests, and what makes a locator fragile?
- Explain the test pyramid. How does it guide what you automate?
- When you automate tests for a REST API endpoint, what do you check?
- What makes an automated test good?
- Compare Selenium and Playwright. When would you choose each?