In regression testing practice, how should regression test cases be written, and what are the main criteria for selecting and designing them after changes are made?

Introduction / Context:
Regression testing ensures that new changes do not unintentionally break existing functionality. Interviewers ask about regression test case design to evaluate whether you are able to think in terms of risk, impact analysis and maintainable test suites. Well chosen regression tests help teams move quickly while still keeping confidence in software stability.

Given Data / Assumptions:
- The product is evolving through multiple builds or releases.
- New features, bug fixes or configuration changes are frequently introduced.
- Time and resources for regression testing are limited, so prioritisation is needed.
- The question focuses on conceptual criteria, not concrete test case examples.

Concept / Approach:
Regression test cases should be derived from a combination of risk analysis, change impact analysis and business criticality. Typically, testers identify modules and flows that are touched by recent changes, as well as core user journeys that must always work. Regression tests must be stable, well documented and repeatable so that they can be run automatically or manually across builds. Selecting too many low value tests wastes time, while selecting too few misses defects.

Step-by-Step Solution:
Step 1: Recall that regression testing is about checking existing functionality after changes. Step 2: Remember that high risk and business critical areas must be prioritised. Step 3: Consider that good regression tests remain valid over many releases and are designed for repeat execution. Step 4: Review the options and look for one that combines impact based selection, risk based prioritisation and repeatability. Step 5: Option a matches these principles, so it is the correct choice.

Verification / Alternative check:
As an alternative check, imagine a payment application where a change is made to the discount logic. Regression tests should cover not only the new discount scenarios but also existing payment flows, refund flows and invoice generation. Tests should be selected because they are likely to reveal defects if something breaks, and they should be reusable whenever the payment module changes again. Option a is consistent with this reasoning.

Why Other Options Are Wrong:
Option b incorrectly limits regression testing to new features and ignores existing behaviour. Option c suggests never updating regression tests, which is unrealistic and dangerous because the product evolves. Option d removes all consideration of risk and impact, which makes regression suites inefficient and unpredictable.

Common Pitfalls:
One common pitfall is adding every test ever written to the regression suite, which leads to long execution times and low value. Another mistake is failing to retire outdated tests when features are removed or redesigned. Maintaining a lean but powerful regression set based on the criteria described in option a helps keep testing sustainable while still providing strong protection against unexpected side effects.

Final Answer:
They should focus on areas impacted by recent code or configuration changes, cover critical business flows and high risk features, and be designed for repeatability so that they can be executed whenever a new build is available.