Techie BabajiLearn to Code. Build Real Skills.
Manual Testing · Specialised Testing

Regression Testing

Every change risks breaking something that used to work. Regression testing catches those side effects.

Intermediate 5 min Lesson 19 of 24
Before you start:Smoke and Sanity Testing
0/24 in Manual Testing
On this page · 5 min · Intermediate

On this page

  1. Learning objectives
  2. Explanation
  3. Code example
  4. Step by step
  5. Real-world use
  6. Common mistakes
  7. Best practices
  8. Remember this
  9. Practice exercise
  10. Mini quiz
  11. Related topics
  12. My notes
Reading time
5 min
Difficulty
Intermediate
Updated
Oct 29, 2026

Related tutorials

Interview questions

Learning objectives#

  • Explain regression testing
  • Distinguish retesting and regression
  • Select a regression suite by risk
  • Decide what to automate

Explanation#

Retesting confirms a specific fix works. Regression testing re-checks unchanged areas to make sure nothing else broke.

Full regression runs everything; selective regression picks tests related to the change plus high-risk, high-use features.

Regression suites grow quickly — automate the stable, repetitive cases and keep manual effort for new and changing areas.

Code example: Choosing regression tests for a change#

TextChoosing regression tests for a change Illustrative
Change: tax calculation updated for new GST slabs


Retest:            BUG-320 tax on electronics (the fixed bug)
Selective regression:
  • All checkout totals (tax affects totals)          High
  • Invoices and PDF receipts                         High
  • Refunds (tax reversal)                            High
  • Coupons + tax combinations                        Medium
  • Order history display                             Low
Not needed:        Profile photo upload, password reset
Expected output
A focused regression set covers everything the change could affect without testing the whole app.

This example is illustrative. Copy or download it and run it in your own environment; the expected output is shown above.

Step-by-step explanation#

  1. Retest the fix itself.
  2. Map which areas use the changed code.
  3. Prioritise by risk and usage.
  4. Skip unrelated areas unless doing a full regression.

Real-world use case#

Release candidates get a full automated regression run plus manual selective regression on changed modules.

Common mistakes#

Confusing retest with regression

Retest = the fixed bug; regression = everything around it.

Never pruning the suite

Remove obsolete tests and add cases for new bugs.

Best practices#

  • Impact analysis before selecting tests
  • Automate stable regression cases
  • Add a test for every escaped bug
  • Review the suite each release

Remember this#

Retest = the fix. Regression = the rest.

Select by impact and risk.

Automate the repetitive core.

Practice exercise#

Your task: A developer changed the password hashing library. Which areas need regression?

Show solution
Text Illustrative
Login, registration, password reset, change password, “remember me”, any API authentication.

Mini quiz#

Regression Testing quizMultiple choice Question 1 of 1

Checking that a fixed bug no longer occurs is called…

Score so far: 0/0

Want more? Practise all Manual Testing MCQs · Manual Testing interview questions

My notes#

Saved in this browser.

Progress is saved in this browser. Sign in to sync.