What makes an automated test good?
What the interviewer wants to hear
- Tests one clear behaviour with a descriptive name
- Independent and repeatable, creates its own data
- Deterministic, no fixed sleeps
- Meaningful assertions that fail with clear messages
- Fast and easy to read and maintain
Model answer
A good automated test checks one clear behaviour and has a name that says what is expected, so a failure is understood at a glance. It is independent: it creates or requests the data it needs and does not rely on other tests running first, so it can run alone, in any order or in parallel. It is deterministic, which means no fixed sleeps, no reliance on the real clock and no random data that can collide. Its assertions check the outcome that matters, not just that the page loaded, and when they fail they show useful messages, screenshots or traces. It is also as fast as possible, ideally at the lowest test level that can catch the risk. Finally, it is easy to read: setup, action and expected result are visible without digging through layers of helpers.
Can you answer it under time pressure?
Take a timed easy round and get scored on every answer.
More easy Automation Test Engineer questions
- Why do teams automate tests, and what should not be automated?
- 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?
- Compare Selenium and Playwright. When would you choose each?