Focused Tests e Change-Based Testing: em que se diferenciam e quando usar cada um
Last updated: June 25, 2026
Tanto os Focused Tests quanto o Change-Based Testing são add-ons que complementam as threat emulations recorrentes de um asset. Ambos executam validações delimitadas com o agente de IA da Strike e consomem do mesmo pool de testing units. A diferença está em como são disparados e em que se concentram: um Focused Test é uma validação manual e pontual sobre um objetivo que você define; o Change-Based Testing é uma validação automática que reage às mudanças de código nos seus repositórios.
Este artigo explica o que eles têm em comum, em que se diferenciam e quando convém usar cada um. Para os passos de configuração, consulte o artigo dedicado de cada funcionalidade, com link no final.
O que eles têm em comum
São add-ons. Não fazem parte do plano base; você os ativa contratando um pool de testing units. Sem o add-on, você não verá a funcionalidade no asset.
Compartilham o mesmo pool de testing units (também chamadas de execuções pontuais). Cada execução, seja Focused ou Change-Based, desconta 1 testing unit do mesmo pool. Isso dá flexibilidade para distribuir as execuções entre as duas funcionalidades conforme a necessidade do momento.
Usam o mesmo agente de IA da Strike e a configuração do asset.
Executam validações delimitadas, mais rápidas e leves do que uma threat emulation completa, focadas em um escopo específico.
Complementam, e não substituem, as threat emulations recorrentes. A validação contínua segue funcionando com o plano base e não é afetada.
Em que se diferenciam
Atributo | Focused Tests | Change-Based Testing |
|---|---|---|
Quem dispara | Você, manualmente | A Strike, automaticamente |
Trigger | On-demand, quando você decidir | Eventos do GitHub (por pull request ou por release) |
Frequência | Uma única execução (one-shot) | Uma execução por mudança detectada |
Escopo | Um objetivo (goal) que você define em texto livre | As mudanças de código incluídas no PR ou release |
Configuração | Você pode ajustar files, restrictions e credenciais apenas para aquela execução | Usa a configuração do asset |
Requisitos | Função Owner ou Operator | Função Owner ou Operator + acesso admin ao GitHub |
Caso de uso típico | Validar algo pontual e específico, agora | Encurtar a janela entre um deploy e sua validação |
Consumo | 1 testing unit por execução (pool compartilhado) | 1 testing unit por execução (pool compartilhado) |
Quando usar cada um
Use um Focused Test quando quiser validar algo específico no momento: um endpoint novo, um fluxo de login, um painel de admin ou qualquer área pontual que precise revisar sem esperar o próximo ciclo. Você define o objetivo e dispara a execução.
Use o Change-Based Testing quando tiver deploys frequentes e quiser que cada mudança relevante seja validada perto do momento em que é introduzida. Você configura uma vez e ele dispara sozinho a cada PR ou release, vinculando os achados à mudança que os originou.
Não é uma decisão excludente. Muitas equipes usam os dois: o Change-Based Testing para cobrir o fluxo contínuo de mudanças de forma automática, e os Focused Tests para validações dirigidas e pontuais. Como ambos consomem do mesmo pool, você pode dividir as execuções de acordo com o que precisar em cada momento.
O papel das threat emulations recorrentes
Nenhuma das duas funcionalidades substitui a camada de validação contínua. As threat emulations recorrentes mantêm uma visibilidade permanente e profunda sobre o risco do asset; os Focused Tests e o Change-Based Testing somam validações pontuais sobre essa base. O ideal é manter a cobertura recorrente ativa e usar esses add-ons onde mais agregam valor.