"What is the difference between regression testing and retesting?" It is one of the most common QA interview questions, from fresher roles to senior ones. Most candidates answer with a memorised definition. The interviewer nods, and learns nothing about how the candidate actually works.
The way to stand out is simple: answer with a short definition, then a real example from your own work. Here are the questions you are likely to hear, with answers you can adapt.
1. What is the difference between regression testing and retesting?
Weak answer: "Retesting is testing the failed test cases. Regression is testing the whole application."
Better answer:
"Retesting checks that a specific bug is fixed. I rerun the steps from the bug report, plus a few variations, on the build with the fix. Regression testing checks that the fix, or any other change, didn't break features that were already working. >For example, in my last project we fixed a bug where emails with a + sign couldn't log in. Retesting was logging in with those emails. Regression was checking sign up, password reset and profile updates, because they used the same email validation code."
Use an example from your own project. It shows you have done it, not just read about it.
2. Which comes first, retesting or regression?
"Usually retesting first. If the fix doesn't work, there's no point running regression on that build for that change. After the fix is confirmed, I run regression around the affected areas, and the wider regression suite before release. Smoke testing comes before both, to make sure the build is stable."
3. Can retesting be automated?
This checks whether you understand when automation pays off.
"It can be, but usually it isn't worth it, because retesting is often a one-time check for a specific fix. What I do is ask whether the bug deserves a permanent test. If it was serious, in a critical flow, or has come back before, I add a test for it to the regression suite, and that test is a good candidate for automation."
4. Why is regression testing a good candidate for automation?
"Because it repeats every build or release, the expected results are already known, and it covers stable features. Running the same checks manually every sprint is slow and people get tired and miss steps. Automating the core regression and running it in CI gives fast feedback on every change."
5. How do you decide which regression tests to run?
This is where you can show judgement.
"I start with impact analysis. I check what changed, from the ticket or PR, and ask the developer where else that code is used. Then I run three groups: tests for the directly affected areas, tests for features that depend on that code, and a quick pass on critical journeys like login and payment. Before a major release, or after a big upgrade, we run the full suite."
Mention risk: likelihood of breaking and impact if it does.
6. You have one day before release and your regression takes three days. What do you do?
There is no single right answer. The interviewer wants to see your thinking.
"I'd prioritise. First, the critical journeys. Second, areas directly affected by this release's changes. Third, areas with a history of bugs. I'd ask developers or other team members to help run some of the tests. Then I'd clearly share with the product owner what was tested and what wasn't, so the team can decide whether to release with that risk or delay. I wouldn't silently skip tests."
The last sentence matters. Interviewers value testers who make risk visible.
7. A bug you verified last sprint is back. How do you handle it?
"First I'd check whether it is really the same bug, with the same steps and root cause, or a new bug in the same area. If it's the same, I reopen the original ticket with fresh evidence and the build number. Then I'd look at why it came back, often a merge issue or a related change, and add a regression test for it so it gets caught automatically next time."
8. What is the difference between smoke, sanity and regression?
"Smoke is a quick, broad check that a new build is stable enough to test at all. Sanity is a quick, narrow check that a specific change or fix basically works. Regression is a deeper check that existing features still work after changes. In order: smoke, then sanity and retesting, then regression."
Mistakes candidates make
- Only giving definitions. Always add a short real example.
- Saying regression means testing "everything". Show that you select tests based on risk.
- Claiming to automate everything. It sounds unrealistic. Explain what you automate and why.
- Ignoring communication. Mention how you share results and risks with the team.
- Inventing experience. If you are a fresher, say so and use an example from a practice project, internship or course. Honest answers with clear reasoning beat made-up stories.
Takeaway
Interviewers ask about regression and retesting to see whether you understand why each exists and how you decide what to test. Give a short definition, add a real example, and show how you prioritise and communicate risk.
Preparing for QA interviews? Join the QAliber community to practise questions and learn from testers who have been through them.