de quanto em quanto tempo a gente deveria testar?
uma vez por ano como base, e depois de qualquer mudança grande em autenticação, pagamentos ou hospedagem. se você publica mudanças o tempo todo, uma revisão trimestral mais leve costuma valer mais do que um grande teste anual.
pentest é uma fotografia. ele mostra por onde dava pra entrar nos dias em que a gente testou, no código e na configuração que existiam ali. cada deploy depois disso muda um pouco a foto, e alguns deploys mudam muito. a frequência certa é a que mantém o intervalo entre uma foto e outra menor do que a quantidade de mudança no meio.
a base
uma vez por ano, no escopo completo. é o que a maioria dos questionários de cliente e das seguradoras espera ver, e costuma bastar pra um sistema que muda devagar.
os gatilhos
algumas mudanças merecem um teste por conta própria, não importa quando foi o último:
- qualquer coisa que mexa em autenticação: um jeito novo de logar, login único, fluxo de recuperação de senha, um perfil de usuário novo
- qualquer coisa que mexa em pagamento ou cobrança
- troca de hospedagem, conta nova na nuvem ou uma mudança grande no jeito de fazer deploy
- uma API pública nova, ou uma integração nova com acesso a dados de cliente
esses testes podem ter escopo bem estreito. você não retesta a aplicação inteira porque adicionou um meio de pagamento; testa o fluxo de pagamento e o que ele toca, e o valor acompanha o escopo.
se você publica toda semana
um grande teste anual costuma encontrar um ano inteiro de problema acumulado de uma vez, e isso vira uma semana ruim pros seus desenvolvedores. uma revisão trimestral mais leve, só no que mudou naquele trimestre, pega as mesmas falhas enquanto ainda estão frescas e baratas de corrigir. entre uma revisão e outra, o seu próprio time consegue rodar a checklist de 14 pontos antes de cada lançamento importante.