Estratégia é um orçamento de risco.

Uma estratégia de testes diz o que não será automatizado, o que precisa falhar o build e quais riscos você aceita de olhos abertos.

Comece pela mudança, não pelas ferramentas.

A pergunta útil é qual falha seria cara neste mês.

Quais usuários, dinheiro, dados ou obrigações se movem se este release estiver errado?

Qual checagem, se vermelha, faria você parar? Se a resposta é nenhuma, o pipeline é um relatório, não um gate.

Algum risco permanece. Uma estratégia que afirma o contrário é marketing.

A maior parte da suíte permanente deve ser rápida e específica. Jornadas são escassas.

Testes de unidade e componente que rodam antes da revisão, na mudança que os causou.

Contratos e exemplos de API para outro time não ser o seu ambiente de teste.

Um conjunto pequeno de ponta a ponta para os caminhos que constrangeriam a empresa, mais fumaça depois do deploy.

Uma estratégia que recusa tradeoffs vira uma lista de desejos.

Um stub é mais rápido e menos verdadeiro. Use quando o risco é o contrato. Use a dependência real quando o risco é a integração.

Dados semeados tornam a falha repetível. O caos com forma de produção pertence a um exercício exploratório ou de confiabilidade, de propósito.

Teste exploratório não é falha de automação. É como se encontra o risco que você ainda não sabia nomear.

Mesmo uma versão grosseira. As lacunas costumam ser de dono e de posição, não de vocabulário.