Selecting and Prioritising Regression Tests

Not every test case belongs in your regression suite. If you add every new test without thinking, the suite grows heavy and slow, and people lose trust in running it regularly. The real skill is deciding which tests bring the most value for guarding against regressions and which can stay outside the core pack.

Choosing the Right Regression Tests #

Good regression candidates include critical user journeys, high-risk edge cases, areas with frequent change, and scenarios that have failed in the past. You can also use impact analysis from developers and architects to identify modules most likely to be affected by recent changes. The idea is to protect the intersection of business importance and technical risk.

# Simple prioritisation table

Test Case                        | Business Impact | Failure History | Change Frequency | Priority
---------------------------------|-----------------|-----------------|------------------|---------
Place order with primary payment | High            | Medium          | High             | P1
Apply discount code              | High            | High            | Medium           | P1
Edit user profile                | Medium          | Low             | Medium           | P2
Change language preference       | Low             | Low             | Low              | P3

When selecting regression tests, involve both business and technical perspectives. Product owners can highlight which features matter most to customers and revenue. Developers and architects can point to areas where the code is complex, fragile, or undergoing heavy change. QA brings knowledge of past defects and testing patterns.

Balancing Depth and Breadth #

A regression suite cannot cover every detail of the system, so it must balance depth in critical flows with breadth across modules. Many teams use a tiered approach: a small smoke suite for very fast validation, a medium-sized core regression suite for regular runs, and an extended suite for more thorough checks when time allows. Each tier is built from the same prioritisation principles but tuned for different time budgets.

Common Mistakes #

Mistake 1 — Treating all tests as equally important #

If every test is P1, you effectively have no prioritisation at all.

❌ Wrong: Marking every scenario as critical without considering risk or usage.

✅ Correct: Use clear criteria for impact, history, and change frequency to rank tests.

Mistake 2 — Never removing tests from the regression pack #

As the product evolves, some tests become less relevant or fully covered elsewhere.

❌ Wrong: Keeping outdated scenarios and duplicate checks in the main regression set forever.

✅ Correct: Regularly review and retire low-value tests so the suite stays lean and meaningful.