QA Engineer interview question
How do you use the test pyramid?
Keep most checks fast and close to logic, fewer integration tests at real boundaries, and a small end-to-end layer for critical journeys. The exact shape follows risk, but feedback should remain fast and failures attributable.
Direct answer
What a strong answer covers
How it works
The pyramid is a heuristic about cost and feedback speed: unit tests are cheap, fast, and precise about what broke, so there are many; integration tests at real boundaries such as a database or an HTTP contract are slower and there are fewer; end-to-end tests through the whole system are the slowest and flakiest and are reserved for the journeys that matter most. The shape bends to the risk profile: a thin UI over a complex domain needs mostly unit tests, an integration-heavy system needs more contract and integration tests. The invariants are that feedback on a change arrives in minutes and a failure points at one layer.
Example
A payments service has 1,200 unit tests covering the pricing and ledger logic in under a minute, 80 integration tests running the repository against PostgreSQL and the HTTP layer against a fake bank in three minutes, and 6 end-to-end tests that complete a real payment in a sandbox nightly. When the end-to-end suite grew to 60 tests and 45 minutes, the team pushed most of them down into integration tests with the same assertions and got the pipeline back under ten minutes.
Common mistakes
- Inverting the pyramid with hundreds of browser tests and almost no unit tests.
- Treating the shape as a rule rather than a consequence of cost and risk.
- Writing integration tests that mock the very boundary they were meant to exercise.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.