Você tem dois engenheiros e um produto no ar. Testar tudo não cabe na semana, e deixar a suíte para sexta-feira vira desculpa para não testar. A pirâmide existe para colocar o esforço de teste onde ele devolve mais.
Base: testes de unidade
Mike Cohn descreve a pirâmide em Succeeding with Agile (2009): muitos testes de unidade, alguns de serviço, poucos de ponta a ponta. Regra de cálculo, validação de entrada e desconto de cupom entram em testes que rodam em milissegundos. Kent Beck escreve o mesmo caminho em Test-Driven Development by Example (2002): você escreve o teste para o comportamento que o produto não tem.
Meio: fronteiras entre sistemas
Você cobre aqui o pagamento que responde 402, o banco que recusa dado inválido e o webhook que chega duplicado. Você descobre aqui onde a produção quebra. Google avisa em Software Engineering at Google (O'Reilly, 2020) que o teste de ponta a ponta custa caro para manter, então você guarda os casos valiosos para o caminho de compra e o caminho de login.
Topo: três jornadas
Você mantém testes de tela em três jornadas: cadastro, pagamento e emissão de nota. Todo o resto sobe um nível. Se a suíte de tela passa de dez minutos, o pipeline fica lento e o time passa a pular o teste.
