This is a scenario walkthrough of how the feature works. It is not a customer story.
The scenario
A team has roughly 2,400 UI and API tests. The full suite takes 45 minutes, so developers batch commits, feedback arrives cold, and when the suite fails at minute 43 the investigation starts an hour after the code was written. The team's instinct to run fewer tests is right. Doing it by hand is how coverage quietly dies.
How selection works
Smart Test Selection builds a dependency map between code and tests, then answers one question per change set: which tests could this change possibly affect? A commit touching a checkout component selects the tests that exercise that component, the flows that traverse it, and the API tests behind the endpoints it calls. That is commonly a few hundred tests instead of 2,400.
The full suite still runs nightly as a safety net. The per-commit loop drops from 45 minutes toward the 8–12 minute range. The 70–80% figure we quote is the arithmetic of selection ratios like these; your ratio depends on how coupled your codebase is, and the analyzer shows you every selection with its reasoning so you can audit it instead of trusting it.
For the manager reading this
Multiply your suite duration by your team's commits per day. That is the wait your team pays, every day. A 14-day trial is enough to measure your actual selection ratio on real commits, which turns the decision from a promise into your own number.
How we measured this
- The suite size and durations in this walkthrough are a scenario chosen for arithmetic clarity, not a measurement of any customer. The selection ratio on your own commits is the number the trial produces.