This article explains the hybrid regression testing approach our QA team uses on large projects, determining what needs to be tested and how thoroughly. The approach combines impact analysis and risk assessment to define the regression scope and appropriate testing depth. We use AI to support the analysis, while final decisions remain with our QA engineers.
Introduction
As software products grow, regression testing becomes more difficult to balance with the release speed without compromising quality. Testing too broadly can slow down delivery and increase costs, while keeping testing scope too narrow can lead to critical defects slipping into production. The challenge is not how to run more tests, but to determine what needs to be tested and where QA effort will have the greatest impact. Let’s explore how our QA team balances these risks.
What Is Regression Testing?
Regression testing is often described as retesting existing functionality after changes have been made. The key question is how much of the existing functionality needs to be retested. For example, a seemingly small change to shared authentication logic may affect login, user permissions, session management, and other application functionality. At the same time, a larger change isolated to a specific module may have little or even no impact on the rest of the system.
This is where a QA team should decide what to test, how thoroughly to test it, and how to verify the release quality. And this is where the notion of regression testing approach comes in.
Common Regression Testing Approaches
At a high level, we can distinguish the following regression testing approaches by scope:
Complete Regression Testing
Complete regression testing re-runs the entire test suite; it offers maximum coverage, but is resource-intensive and time-consuming. In practice, exhaustive testing is neither feasible nor possible within real-world business timelines.
Selective Regression Testing
Selective regression testing executes only the tests related to changed functionality and areas potentially affected by those changes. This is often impact-based or experience-based regression because, in practice, it depends on QA’s understanding of the system. The tricky part is that a seemingly small change in shared business logic can affect completely different parts of the product.
Risk-Based Regression Testing
Risk-based regression testing prioritizes tests based on business-related factors like user impact, frequency of use, and the cost of errors, among others. For example, if a release affects both the checkout flow and a rarely used profile setting, the checkout flow must receive higher regression priority.
Hybrid Regression Testing Approach
This is the approach we currently use and consider the most practical for a modern QA team.
It combines impact analysis and risk-based prioritization to define the regression test selection.
We identify what was changed and what could be affected, evaluate business and technical risks, and then select the appropriate regression scope.
This regression strategy can then be executed:
- manually;
- through automated tests;
- or using a combination of both.
Hybrid Regression Testing Approach in Practice: Project Context
Our experience working on large and complex projects has shaped the hybrid regression testing approach our team uses today. Before looking at how this approach works in practice, let’s first consider the scale of one of the projects where we applied it.
By “large,” we mean:
| Dimension | Count |
| Independent git repositories | 6 |
| Deployable applications | 4 (2 APIs + 2 web apps)6 Lambdas1 Python service |
| Source lines (hand-written, excl.generated & migrations) | ~239,000 |
| GraphQL operations (queries + mutations + subscriptions) | 312 |
| REST endpoints | 125 across 43 controllers |
| Next.js pages | 95 |
| Database entities (tables) | 66 |
| NestJS modules / services | 100 / 308 |
| React components | ~1,100 .tsx files |
| Third-party external systems | 5 |
| Production tenant databases | 8 |
Our Hybrid Regression Testing Process
Our regression testing approach has evolved over time and now involves the following steps.
Step 1 — Identify the Impacted Functionality
We identify every module affected during the sprint.
- Directly modified modules
- Shared components
- Dependent services
- APIs and integrations
- Database changes
- Permissions and roles
- Common business logic
- Cross-module dependencies
Deliverable: a map of impacted functionality.
Step 2 — Define the Impact and Risk
The important point is that not all modules from Step 1 need thorough testing, which is a common mistake. A module can technically be affected but still require only minimal regression, while another indirectly affected module may need extensive testing because it is business-critical.
For every affected module, we evaluate:
- How directly is it connected to the change?
- Is shared business logic involved?
- How critical is the functionality for users?
- How frequently is it used?
- What is the historical defect rate?
- What happens if this functionality fails?
- Has this area caused production issues before?
Deliverable: a prioritized list of impacted areas.
Step 3 — Identify the Testing Depth
For every impacted area, we ask the following questions:
- Is full functional validation required?
- Was the functionality already thoroughly tested as part of the feature/task?
- Will smoke testing provide enough confidence?
- Should integration scenarios be executed?
- Are edge cases worth revalidating?
- Would exploratory testing add value?
- Should performance be revalidated?
- Should security-related scenarios be revalidated?
Deliverable: a defined level of regression coverage for each impacted area.
Step 4 — Define the Regression Scope
Based on Steps 1, 2, and 3, we decide what to test in the current regression cycle, and what can be safely excluded.
These steps are integrated into our testing pipeline, where a local Claude AI agent works through them step by step and returns a to-do checklist for each regression cycle.
How AI Supports Regression Testing
The use of AI agents enables us to turn potentially large and complex change sets into a structured, prioritized scope that a QA engineer can later review and execute. AI makes regression planning more efficient and helps us avoid spending time on testing low-risk functionality.
Important: AI supports the process, but the final validation remains with the QA team, which reviews the results using product knowledge, business context, and testing experience.
Our next step as a team is to automate as much of this process as possible and make it accessible to every QA engineer, while keeping resource requirements and costs under control.
Final Thoughts
In large-scale software projects, we don’t focus on running as many tests as possible but make informed decisions on where testing effort will have the greatest impact. Our hybrid approach helps us focus regression on the functionality that matters most to users and the business, while spending less effort on low-risk area testing.
Now, AI gives us another layer of support. It helps us analyze a large and complex change set much faster, identify potential areas of impact, and turn that analysis into a structured regression scope.
However, we don’t see AI as replacing QA decision-making. Quite the opposite. The more information we can process, the more important it becomes to have someone who understands the product well enough to challenge the results, recognize hidden risks, and make the final call.
Hire a Dedicated QA Team at SysGears
At SysGears, our QA engineers work with complex software systems where regression scope needs to be carefully prioritized rather than simply expanded. We can help assess your current QA process, improve regression planning, increase test automation, and build a testing strategy that fits your product and available resources.
