"Como você estrutura uma estratégia de testes?" é a pergunta que separa quem sabe automatizar de quem sabe onde automatizar. A resposta passa por dois modelos mentais que todo QA usa para distribuir esforço: a pirâmide de testes (quanto de cada nível) e os quadrantes de Agile Testing (o que mais falta cobrir).

A pirâmide de testes

Proposta por Mike Cohn, a pirâmide diz que a quantidade de testes deve ser inversamente proporcional ao seu custo e lentidão. Muita base barata, pouco topo caro:

                 ╱╲
                ╱ E2E╲          poucos · lentos · caros · frágeis
               ╱──────╲         (fluxos críticos ponta a ponta)
              ╱ Integ.  ╲       alguns · médios
             ╱────────────╲     (módulos/serviços conversando)
            ╱   Unitários   ╲   muitos · rápidos · baratos · estáveis
           ╱──────────────────╲ (regras de negócio isoladas)

   ← mais lento / mais caro / menos isolado em cima
   ← mais rápido / mais barato / mais isolado embaixo

• Unitários (base): rodam em milissegundos, apontam exatamente onde quebrou. É onde o grosso da cobertura deve estar.
• Integração (meio): verificam que partes conversam — banco, API, serviços. Mais lentos, mas pegam o que o unitário não vê.
• E2E (topo): simulam o usuário no sistema inteiro. Dão a maior confiança, mas são lentos, caros de manter e os primeiros a ficarem flaky. Reserve para os fluxos que não podem falhar.

Os anti-patterns: cone de sorvete e ampulheta

Quando a pirâmide inverte, o time sente na pele. Reconhecer esses formatos é meio caminho para corrigir a estratégia:

Vale citar o troféu de testes de Kent C. Dodds, popular no front-end: ele engorda a camada de integração por entender que, em UIs, é ali que está o melhor retorno de confiança por custo. Pirâmide e troféu não se contradizem — ambos dizem "não dependa de E2E para tudo". O formato ideal depende do seu contexto.

Os quadrantes de Agile Testing

A pirâmide responde "quanto de cada nível", mas não "estou testando as coisas certas?". Para isso existem os quadrantes (Brian Marick, popularizados por Lisa Crispin e Janet Gregory). Eles cruzam dois eixos: negócio × tecnologia e apoiar o time × criticar o produto.

             APOIAM O TIME          │        CRITICAM O PRODUTO
                (guiam o dev)        │         (avaliam o pronto)
        ┌─────────────────────────┬─┴─┬─────────────────────────┐
   VOLTADO│  Q2  (negócio/apoio)    │   │  Q3  (negócio/crítica)  │
   AO     │  exemplos, protótipos,  │   │  testes exploratórios,  │
   NEGÓCIO│  cenários BDD/ATDD      │   │  usabilidade, UAT       │
        ├─────────────────────────┼───┼─────────────────────────┤
   VOLTADO│  Q1  (técnico/apoio)    │   │  Q4  (técnico/crítica)  │
   À      │  testes unitários,      │   │  performance, carga,    │
   TÉCNICA│  integração, TDD        │   │  segurança, resiliência │
        └─────────────────────────┴───┴─────────────────────────┘
            automatizados              manuais / ferramentas
            (Q1 e Q2)                  especializadas (Q3 e Q4)

• Q1 — técnico, apoia o time: unitários e integração. A base da pirâmide, ligada ao TDD.
• Q2 — negócio, apoia o time: exemplos e cenários que definem o "feito" antes de codar. É o território de BDD/ATDD.
• Q3 — negócio, critica o produto: teste exploratório, usabilidade, aceite do usuário. Olho humano sobre o produto pronto.
• Q4 — técnico, critica o produto: performance, carga, segurança. Atributos de qualidade que automação funcional não cobre.

Times costumam morar em Q1+Q2 e esquecer Q3 e Q4 — e é exatamente aí que vazam os problemas que o cliente percebe primeiro: lentidão, telas confusas, falhas sob carga.

A pirâmide te diz se a distribuição de esforço está saudável; os quadrantes te dizem se há um tipo de qualidade que ninguém está olhando. Uma é sobre quantidade, a outra sobre cobertura.

Usando os dois juntos no dia a dia

Na prática: a pirâmide guia onde escrever automação (empurre casos para baixo sempre que possível — o que dá para testar no unitário não precisa de E2E). Os quadrantes guiam a conversa de planejamento — "temos Q1 e Q2 cobertos, mas quando foi a última vez que rodamos um teste de carga (Q4) ou uma sessão exploratória (Q3)?". Juntos, evitam tanto a suíte lenta e frágil quanto o ponto cego que só aparece em produção.

Conclusão

Saber recitar "pirâmide de testes" é fácil; saber diagnosticar um cone de sorvete no seu próprio pipeline e identificar qual quadrante está descoberto é o que demonstra senioridade. São dois mapas que, usados juntos, transformam "vamos testar bastante" numa estratégia de qualidade com lugar definido para cada tipo de teste.

"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.