When a small change is made to an application, one thing usually follows:
Run the regression suite.
It makes sense. We want to make sure the change didn't break anything somewhere else. But recently I started thinking about something:
Do we really need to run every test after every code change?
Imagine a test suite with 2,000 tests. A developer makes a change to the payment flow.
Maybe only a part of those tests are directly related to payment. Some others might depend on checkout or orders. And many of the remaining tests may have very little connection to that change. Yet we still run the entire suite.
That's where I started looking into Test Impact Analysis.
The idea is fairly simple: instead of treating every test as equally relevant, can we understand which tests are actually connected to a particular change? That sounds useful, especially when regression suites become large. But I think there is another side to it.
If we run fewer tests, we need to be confident that we didn't skip something important.
This is something I started thinking about more while exploring AI-assisted testing. At X360 AI Tech, I came across an approach where requirements, test coverage, execution, and results are connected instead of treating test execution as an isolated step.
That made me look at regression testing a little differently. It made me think that AI’s value may not always be about creating more tests or running them faster. Maybe it’s also about helping us understand which tests actually matter for the change we just made.
At the same time, I’d want the uncertainty to be visible when AI isn’t confident, rather than silently skipping tests.
For me, the goal isn’t simply: Run fewer tests.
It’s: Run the right tests, and understand why they were selected.
That's something I'm still exploring.
Top comments (0)