Test Pyramid

The test pyramid is a rule of thumb: many fast, cheap checks at the bottom; few slow, brittle checks at the top. Unit and service/API tests carry most of the regression. UI end-to-end tests cover a short list of journeys that must not break. Exploratory testing sits beside the pyramid, not inside a slice of pie.

It is a shape, not a certification. Teams that “implemented the pyramid” and still cannot say what a release covered have a documentation problem — start with a test strategy or a QA audit.

The layers that earn their keep

Unit

Fast checks on logic you own. Engineering-owned. If a calculation or a permission helper can be wrong in isolation, it should not wait for a browser.

API / service

Contracts, errors, and data you would not see in a happy-path UI. See API testing and Postman when a collection is the right artefact. This layer is where shift-left usually pays first.

UI / end-to-end

A thin set: sign-in, pay, permission boundaries, the one admin path that ruins a Friday. Automate those with Playwright or Cypress — decide with Playwright vs Cypress, not a brand preference.

If the UI layer is the widest part of your suite, you have an ice-cream cone: slow, flaky, and late. That is the failure mode the pyramid exists to prevent.

What the poster leaves out

• Exploratory time. Scripts do not invent the bug you did not imagine. Budget it.
• Mobile native. The pyramid still applies; the UI tool is often Appium, not a desktop browser runner.
• Load. Performance is not a pyramid layer you “fill with more Selenium.”
• AI / LLM. Evaluation sets, rubrics, and metrics are a parallel track. Do not pretend a Playwright spec is LLM evaluation.

How to use the pyramid on a real product

1. List the journeys that lose money, data, or trust if they break.
2. Push every check that does not need a browser down a layer.
3. Cap UI automation. A prune list is part of the suite. See test automation.
4. Write the rule in the strategy: what lives where, who owns it.
5. Revisit after a painful flake week — the shape drifts.

We do not sell a “pyramid assessment” with a score. We will look at your CI and say whether you have a cone.

FAQs

Who invented the test pyramid?

The phrase is widely attributed to Mike Cohn’s work on agile testing. The useful part is the shape, not the citation.

Should 70% of tests be unit tests?

There is no sacred percentage. If your UI suite takes an hour and catches nothing a contract test would catch, you are too high in the cone. If you have no UI journeys at all, you are not testing the product users see.

Does the pyramid replace QA?

No. It tells automation where to sit. Humans still own exploratory work, accessibility, and judgement.

How do we start?

Book a QA consultation. Bring a CI run and the list of tests that failed last month. We will say which layer is overweight.