Explain the test pyramid. How does it guide what you automate?
What the interviewer wants to hear
- Many unit tests, fewer integration/API tests, few E2E tests
- Lower levels are faster, cheaper and more precise
- E2E tests cover only critical journeys
- Avoid the ice-cream cone of mostly UI tests
- Push each check to the lowest level that can catch it
Model answer
The test pyramid says most automated tests should be fast unit tests at the bottom, a smaller layer of integration and API tests in the middle, and only a few end-to-end UI tests at the top. Lower tests run in milliseconds and point straight at the broken code. UI tests are slow, need a full environment and break for many reasons, so a suite made mostly of them, the ice-cream cone, gives slow and noisy feedback. When I plan automation I ask what the lowest level is that can catch each risk. Validation rules go in unit tests, service behaviour and error codes in API tests, and only critical journeys like sign-up and checkout get E2E tests. The pyramid is a guide, not a law, but it keeps the suite fast and trustworthy.
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?
- 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?