Combining Regression Test Selection Techniques and Adjusting the Regression Test Suite (ISTQB CTAL-TA)
Introduction
In the ISTQB Advanced Level Test Analyst (CTAL-TA) syllabus, the Test Analyst plays an active role in risk-based testing. One of the most practical parts of this role is deciding which regression tests to run when time and resources are limited, and how to keep the regression test suite healthy over the life of a product. This guide explains what combining regression test selection techniques means, why it matters, how it works in practice, and how to answer exam questions on the topic with confidence.
Why Is This Topic Important?
Regression test suites grow with every release. New features add new tests, and defect fixes add confirmation and regression checks. Old tests are rarely removed. The result is a suite that becomes:
- Too large to run fully within a sprint, release window or overnight build.
- Costly to maintain, because every change to the system can break existing test cases or scripts.
- Less effective, because obsolete, redundant or low-value tests use up time that should go to high-risk areas.
Running everything every time is rarely possible. Choosing tests based only on intuition is risky. Combining selection techniques and adjusting the suite lets the Test Analyst:
- Focus regression effort on the areas with the highest product risk.
- Get the best possible risk coverage within fixed time and budget.
- Give stakeholders justified, traceable reasons for what was and was not tested.
- Keep the suite lean, current and maintainable, which matters most in Agile and CI/CD environments.
What Is It?
Regression test selection is the process of choosing a subset of the existing regression suite to execute after a change. Several individual approaches are commonly used:
1. Risk-based selection: choose tests that cover the areas with the highest likelihood and impact of failure.
2. Change-based (impact analysis) selection: choose tests that exercise code, components or requirements affected by the change, including indirect dependencies.
3. Requirements or coverage-based selection: choose tests to keep coverage of key requirements, business processes, user stories or code structures.
4. Defect history selection: choose tests for areas that have been defect-prone, show defect clustering or recently had fixes.
5. Usage or operational profile selection: choose tests for the features and workflows real users use most often.
6. Priority-based selection: choose tests by their assigned priority (for example business criticality or legal or safety relevance).
7. Experience-based selection: use tester and domain knowledge to identify fragile or historically troublesome areas.
Combining selection techniques means using two or more of these approaches together rather than relying on one. Each technique alone has blind spots:
- Change-based selection alone can miss side effects in untouched but critical areas.
- Risk-based selection alone can ignore a small change in a low-risk area that still breaks something.
- Defect history alone looks backwards and may miss new risks.
- Usage profiles alone may neglect rarely used but high-impact functions, such as year-end processing or disaster recovery.
Combining them gives a more balanced and defensible selection.
Adjusting the regression test suite means the ongoing maintenance of the suite itself so that it stays effective and efficient. Typical adjustments include:
- Adding tests for new features, newly found defects (including tests that would have caught escaped defects) and newly identified risks.
- Removing or retiring obsolete tests, such as tests for removed features or tests that no longer match the requirements.
- Consolidating redundant or overlapping tests that cover the same conditions.
- Updating tests whose expected results, data or steps have changed.
- Re-prioritizing tests as risk levels change, for example when an area becomes stable or a previously minor function becomes business-critical.
- Automating stable, frequently executed, high-value tests, and reviewing the automation for flaky tests.
How It Works
Step 1: Understand the change. Gather information on what has changed (code, configuration, environment, data, third-party components) and perform impact analysis. Use traceability between requirements, test conditions, test cases and code to identify affected tests.
Step 2: Revisit the product risk analysis. The Test Analyst re-evaluates the likelihood and impact of the identified product risks. Changes may raise the likelihood of failure in certain areas. Business impact may also have shifted since the last assessment.
Step 3: Apply multiple selection criteria. For example:
- Mandatory set: tests covering high-risk, safety-critical, regulatory or core business functions (often called a core or smoke/sanity regression set), always executed.
- Change-related set: tests that exercise changed and directly or indirectly impacted areas.
- Defect-prone set: tests in modules with a history of defects or recent fixes.
- Usage set: tests for the most frequently used workflows.
The union of these sets, adjusted for priority, forms the candidate selection.
Step 4: Prioritize within constraints. If the candidate set is still too large for the available time, order tests by risk level (highest first) so that the most important risks are covered even if testing stops early. Breadth-first coverage of high-risk areas is often preferred to deep testing of one area.
Step 5: Execute, monitor and report. Track which risks have been covered and which remain open (residual risk). Report this clearly to stakeholders so they can make informed release decisions.
Step 6: Adjust the suite. After execution and over time, analyze results:
- Tests that never fail and cover low-risk, stable areas may be candidates for lower priority, less frequent execution or retirement.
- Escaped defects from production show gaps, so new tests should be added.
- Frequently failing tests may point to unstable areas (raise priority) or to defective or flaky tests (fix them).
- Redundant tests found through coverage analysis can be merged.
This is a continuous feedback loop linked to the risk-based testing cycle of identification, assessment, mitigation and ongoing management of risk.
Example Scenario
An e-commerce system has a regression suite of 2,000 tests that takes five days to run. A release changes the discount calculation module and fixes a defect in the payment gateway. Only two days of testing are available. A combined approach would:
- Always run the core set covering checkout, payment and login (high-risk, high-usage).
- Run all tests linked through traceability to discount calculation and its dependent components, such as cart totals, invoices and tax.
- Run payment tests because of the recent fix and the defect history.
- Add tests for the most popular user journeys from the operational profile.
- Drop or postpone tests for low-risk, unchanged and stable areas such as the static help pages.
After the release, the Test Analyst adds a test for the payment defect, removes tests for a retired coupon feature and re-prioritizes discount tests as high risk for the next cycles.
Key Concepts to Remember
- No single selection technique is enough; combining them reduces blind spots.
- Risk is the main driver for both selection and prioritization in risk-based testing.
- Traceability is essential for impact analysis and change-based selection.
- The regression suite is a living asset that must be maintained continually, not just extended.
- Selection decisions and residual risk must be communicated transparently to stakeholders.
- Automation supports frequent regression runs but needs its own maintenance.
Exam Tips: Answering Questions on Combining Selection Techniques and Adjusting the Regression Test Suite
1. Look for the risk keyword. In the CTAL-TA exam, the best answer usually links test selection to product risk. If one option bases selection on risk and impact analysis and another bases it on convenience, test age or the tester's preference, choose the risk-based option.
2. Prefer combination over a single criterion. Questions often describe a situation where one technique alone falls short. Pick the answer that combines approaches, for example risk plus change impact plus defect history, rather than one that relies on one source of information.
3. Watch for absolute statements. Options such as always run the full regression suite, only test the changed code or never remove tests are usually wrong. Full regression is often impractical, change-only testing misses side effects, and suites must be pruned.
4. Recognize valid reasons to remove or modify tests. Correct reasons include obsolete functionality, redundancy, consistently low value in stable low-risk areas, and changed requirements. A test simply being old or taking a long time to run is not, on its own, a good reason to remove it if it covers a high risk.
5. Recognize valid reasons to add tests. These include new features, escaped or production defects, newly identified risks and changed business priorities. Adding a test for a defect that slipped through is a classic correct answer.
6. Remember traceability. If a question asks how to find which regression tests are affected by a change, the answer usually involves traceability between requirements or test basis and test cases, together with impact analysis.
7. Handle time-constrained scenarios correctly. When the scenario says there is not enough time, the right approach is to prioritize by risk so the highest-risk tests run first, and to report the untested areas and residual risk to stakeholders. Cutting testing silently or testing randomly is wrong.
8. Consider stakeholder involvement. The Test Analyst gives input on business and functional risk, but risk levels and acceptance of residual risk involve stakeholders. Answers that include consulting business stakeholders about impact are often strong.
9. Read scenario details carefully. K3 and K4 style questions include clues such as this module had many defects last release, this feature is used by 80 percent of customers or this function is legally mandated. Each clue points to a selection criterion (defect history, operational profile, criticality). The best answer uses all relevant clues.
10. Distinguish confirmation testing from regression testing. Retesting a fixed defect is confirmation testing. Checking that the fix did not break other areas is regression testing. Questions may test whether you know that both are needed after a fix.
11. Think continuous, not one-off. Answers describing regression suite maintenance as an ongoing, feedback-driven activity, aligned with re-assessment of risks during the project, are usually preferred over answers describing a one-time clean-up.
12. Eliminate distractors systematically. First remove answers that ignore risk. Next remove answers with absolute language. Then remove answers using only one criterion when the scenario clearly calls for several. The remaining option is usually correct.
Summary
Combining regression test selection techniques lets the Test Analyst build a focused, risk-driven regression set that balances change impact, business criticality, defect history and usage within real constraints. Adjusting the regression test suite keeps it relevant, lean and effective by adding, removing, updating and re-prioritizing tests as the product and its risks evolve. For the exam, consistently choose answers that are risk-based, combine multiple criteria, rely on traceability and impact analysis, avoid absolutes, and include transparent communication of residual risk.
