Focused Tests and Change-Based Testing: how they differ and when to use each
Last updated: June 25, 2026
Both Focused Tests and Change-Based Testing are add-ons that complement an asset's recurring threat emulations. Both run scoped validations with Strike's AI agent and draw from the same pool of testing units. The difference lies in how they are triggered and what they focus on: a Focused Test is a manual, one-off validation against a goal you define; Change-Based Testing is an automatic validation that reacts to code changes in your repositories.
This article explains what they have in common, how they differ, and when to use each. For the setup steps, see the dedicated article for each feature, linked at the end.
What they have in common
They are add-ons. They are not part of the base plan; you activate them by contracting a pool of testing units. Without the add-on, you won't see the feature on the asset.
They share the same pool of testing units. Each run, whether Focused or Change-Based, deducts 1 testing unit from the same pool. This gives you the flexibility to distribute your runs across both features as your needs change.
They use the same Strike's AI agent and the asset's configuration.
They run scoped validations that are faster and lighter than a full threat emulation, focused on a specific scope.
They complement, rather than replace, the recurring threat emulations. Continuous validation keeps running on the base plan and is not affected.
How they differ
Attribute | Focused Tests | Change-Based Testing |
|---|---|---|
Who triggers it | You, manually | Strike, automatically |
Trigger | On-demand, whenever you decide | GitHub events (per pull request or per release) |
Frequency | A single run (one-shot) | One run per detected change |
Scope | A goal you define in free text | The code changes included in the PR or release |
Configuration | You can adjust files, restrictions, and credentials for that run only | Uses the asset's configuration |
Requirements | Owner or Operator role | Owner or Operator role + GitHub admin access |
Typical use case | Validate something specific, right now | Shorten the window between a deploy and its validation |
Consumption | 1 testing unit per run (shared pool) | 1 testing unit per run (shared pool) |
When to use each
Use a Focused Test when you want to validate something specific in the moment: a new endpoint, a login flow, an admin panel, or any particular area you need to review without waiting for the next cycle. You define the goal and trigger the run.
Use Change-Based Testing when you have frequent deploys and want every relevant change validated close to the moment it's introduced. You set it up once, and it triggers on its own with each PR or release, linking findings to the change that introduced them.
It's not an either/or decision. Many teams use both: Change-Based Testing to cover the continuous flow of changes automatically, and Focused Tests for targeted, on-demand validations. Since both draw from the same pool, you can split your runs according to what you need at any given time.
The role of recurring threat emulations
Neither feature replaces the continuous validation layer. Recurring threat emulations keep permanent, in-depth visibility over the asset's risk; Focused Tests and Change-Based Testing add point validations on top of that base. The ideal setup is to keep recurring coverage active and use these add-ons where they add the most value.