O release é amanhã e você tem dois dias de teste pela frente. Como você lida com isso?

Mude para teste baseado em risco e torne o trade off visível em vez de silenciosamente cortar caminho. Ordene as áreas por probabilidade de falha vezes impacto, teste primeiro os caminhos de maior risco e use teste exploratório onde a cobertura roteirizada é lenta demais. Depois reporte com clareza o que foi coberto, o que não foi e qual é o risco residual, para que a decisão de release fique com quem é dono dela.

Eu paro de tentar rodar tudo e começo a ordenar. O objetivo numa janela apertada é comprar a maior redução de risco por hora, não percorrer a suíte em ordem. Então eu olho o que de fato mudou e o que aquilo toca, e depois classifico as áreas por probabilidade de falha vezes impacto se falhar. Pagamento e autenticação são testados mesmo que a mudança esteja longe deles, porque o prejuízo é ilimitado. Um ajuste cosmético numa tela de configurações não é. A regressão automatizada roda em segundo plano enquanto eu uso as minhas mãos para teste exploratório das áreas que mudaram, porque exploração guiada por charter cobre terreno muito mais rápido do que escrever e executar casos roteirizados quando o tempo é curto. E aí, o que mais importa, eu reporto com honestidade. Isto foi o que eu cobri, isto foi o que eu não cobri, este é o risco residual em linguagem simples: nós não testamos o caminho de reembolso no mobile, e se ele estiver quebrado, os clientes não conseguem o dinheiro de volta. Eu não bloqueio o release e eu não abençoo em silêncio. A pessoa responsável toma a decisão com informação real, e eu garanto que essa decisão fique registrada.