Focused Tests y Change-Based Testing: en qué se diferencian y cuándo usar cada uno
Last updated: June 25, 2026
Tanto los Focused Tests como Change-Based Testing son add-ons que complementan las threat emulations recurrentes de un asset. Los dos ejecutan validaciones acotadas con el agente de IA de Strike y consumen de la misma bolsa de testing units. La diferencia está en cómo se disparan y en qué se enfocan: un Focused Test es una validación manual y puntual sobre un objetivo que tú defines; Change-Based Testing es una validación automática que reacciona a los cambios de código en tus repositorios.
Este artículo explica qué tienen en común, en qué se diferencian y cuándo conviene usar cada uno. Para los pasos de configuración, consulta los artículos dedicados de cada funcionalidad, enlazados al final.
Qué tienen en común
Son add-ons. No vienen en el plan base; se activan contratando una bolsa de testing units. Si no tienes el add-on, no verás la funcionalidad en el asset.
Comparten la misma bolsa de testing units (también llamadas ejecuciones puntuales). Cada ejecución, sea Focused o Change-Based, descuenta 1 testing unit del mismo pool. Esto te da flexibilidad para distribuir tus ejecuciones entre ambas funcionalidades según las necesidades del momento.
Usan el mismo agente de IA de Strike y la configuración del asset.
Ejecutan validaciones acotadas, más rápidas y livianas que una threat emulation completa, enfocadas en un scope específico.
Complementan, no reemplazan, las threat emulations recurrentes. La validación continua sigue funcionando con el plan base y no se ve afectada.
En qué se diferencian
Atributo | Focused Tests | Change-Based Testing |
|---|---|---|
Quién lo dispara | Tú, de forma manual | Strike, de forma automática |
Trigger | On-demand, cuando lo decides | Eventos de GitHub (por pull request o por release) |
Frecuencia | Una sola ejecución (one-shot) | Una ejecución por cada cambio detectado |
Scope | Un objetivo (goal) que defines en texto libre | Los cambios de código incluidos en el PR o release |
Configuración | Puedes ajustar files, restrictions y credenciales solo para esa ejecución | Usa la configuración del asset |
Requisitos | Rol Owner u Operator | Rol Owner u Operator + acceso admin a GitHub |
Caso de uso típico | Validar algo puntual y específico, ahora | Acortar la ventana entre un deploy y su validación |
Consumo | 1 testing unit por ejecución (bolsa compartida) | 1 testing unit por ejecución (bolsa compartida) |
Cuándo usar cada uno
Usa un Focused Test cuando quieres validar algo específico en el momento: un endpoint nuevo, un flujo de login, un panel de admin o cualquier área puntual que necesites revisar sin esperar al próximo ciclo. Tú defines el objetivo y disparas la ejecución.
Usa Change-Based Testing cuando tienes deploys frecuentes y quieres que cada cambio relevante se valide cerca del momento en que se introduce. Lo configuras una vez y se dispara solo ante cada PR o release, vinculando los hallazgos al cambio que los originó.
No es una decisión excluyente. Muchos equipos usan los dos: Change-Based Testing para cubrir el flujo continuo de cambios de forma automática, y Focused Tests para validaciones dirigidas puntuales. Como ambos consumen de la misma bolsa, puedes repartir tus ejecuciones según lo que necesites en cada momento.
El rol de las threat emulations recurrentes
Ninguno de los dos reemplaza la capa de validación continua. Las threat emulations recurrentes mantienen una visibilidad permanente y profunda sobre el riesgo del asset; Focused Tests y Change-Based Testing suman validaciones puntuales por encima de esa base. Lo ideal es tener la cobertura recurrente activa y usar estos add-ons donde aportan más valor.