"How do you structure a testing strategy?" is the question that separates people who know how to automate from people who know where to automate. The answer goes through two mental models every QA uses to distribute effort: the test pyramid (how much of each level) and the Agile Testing quadrants (what is still missing).

The test pyramid

Proposed by Mike Cohn, the pyramid says that the quantity of tests should be inversely proportional to their cost and slowness. A big cheap base, a small expensive top:

                 ╱╲
                ╱ E2E╲          few · slow · expensive · brittle
               ╱──────╲         (critical end-to-end flows)
              ╱ Integ.  ╲       some · medium
             ╱────────────╲     (modules/services talking)
            ╱     Unit      ╲   many · fast · cheap · stable
           ╱──────────────────╲ (isolated business rules)

   ← slower / more expensive / less isolated at the top
   ← faster / cheaper / more isolated at the bottom

• Unit (base): run in milliseconds and point to exactly where it broke. This is where the bulk of the coverage should be.
• Integration (middle): verify that parts talk to each other: database, API, services. Slower, but they catch what unit tests can't see.
• E2E (top): simulate the user across the whole system. They give the most confidence, but they're slow, expensive to maintain, and the first to become flaky. Reserve them for the flows that cannot fail.

The anti-patterns: ice cream cone and hourglass

When the pyramid flips, the team feels it firsthand. Recognizing these shapes is half the way to fixing the strategy:

Worth mentioning is Kent C. Dodds' testing trophy, popular in front-end: it fattens the integration layer because, in UIs, that's where the best return on confidence per cost lies. The pyramid and the trophy don't contradict each other; both say "don't depend on E2E for everything". The ideal shape depends on your context.

The Agile Testing quadrants

The pyramid answers "how much of each level", but not "am I testing the right things?". That's what the quadrants are for (Brian Marick, popularized by Lisa Crispin and Janet Gregory). They cross two axes: business × technology and supporting the team × critiquing the product.

             SUPPORT THE TEAM        │        CRITIQUE THE PRODUCT
                (guide the dev)      │         (evaluate the finished thing)
        ┌─────────────────────────┬─┴─┬─────────────────────────┐
  BUSINESS│  Q2  (business/support) │   │  Q3  (business/critique)│
  FACING  │  examples, prototypes,  │   │  exploratory testing,   │
          │  BDD/ATDD scenarios     │   │  usability, UAT         │
        ├─────────────────────────┼───┼─────────────────────────┤
  TECH    │  Q1  (technical/support)│   │  Q4  (technical/critique)│
  FACING  │  unit tests,            │   │  performance, load,     │
          │  integration, TDD       │   │  security, resilience   │
        └─────────────────────────┴───┴─────────────────────────┘
            automated                  manual / specialized
            (Q1 and Q2)               tools (Q3 and Q4)

• Q1 — technical, supports the team: unit and integration tests. The base of the pyramid, tied to TDD.
• Q2 — business, supports the team: examples and scenarios that define "done" before coding. This is the territory of BDD/ATDD.
• Q3 — business, critiques the product: exploratory testing, usability, user acceptance. A human eye on the finished product.
• Q4 — technical, critiques the product: performance, load, security. Quality attributes that functional automation doesn't cover.

Teams tend to live in Q1+Q2 and forget Q3 and Q4, and that's exactly where the problems the customer notices first leak out: slowness, confusing screens, failures under load.

The pyramid tells you whether the distribution of effort is healthy; the quadrants tell you whether there's a kind of quality nobody is looking at. One is about quantity, the other about coverage.

Using both together day to day

In practice: the pyramid guides where to write automation (push cases down whenever possible, since what can be tested at the unit level doesn't need E2E). The quadrants guide the planning conversation: "we have Q1 and Q2 covered, but when was the last time we ran a load test (Q4) or an exploratory session (Q3)?". Together, they avoid both the slow, brittle suite and the blind spot that only shows up in production.

Conclusion

Reciting "test pyramid" is easy; diagnosing an ice cream cone in your own pipeline and identifying which quadrant is uncovered is what shows seniority. They are two maps that, used together, turn "let's test a lot" into a quality strategy with a defined place for each type of test.