Guardians of Stability: Regression & Re-test
What This Module Is About
Every sprint, developers fix bugs and add features. Every sprint, the risk of breaking something that used to work goes up.
This is where you come in. 🛡️
Re-testing and regression testing are the two most fundamental activities of manual QA work — and they're often confused, merged, or skipped entirely. This module gives you the clarity to do them right.
Re-testing is focused: "Is this specific bug actually gone?" You follow the exact steps from the original bug report and see if the problem still exists.
Regression testing is broad: "Did fixing that bug break anything else?" You check the areas around the change — and sometimes areas that seem completely unrelated but share code or data with what was modified.
The butterfly effect is real in software. A typo fix in a CSS file can break a JavaScript component that read a specific class name. A database query tweak in the login module can slow down the dashboard by 2 seconds. This module teaches you to think in ripples.
What You'll Learn in This Module
- ✅ The precise difference between re-testing and regression testing
- 🐛 How to use the original bug report as your re-test script
- 🦋 Why "unrelated" changes can break "unrelated" features
- 📋 What a regression checklist is and how to use one
- ⚖️ How to choose between full, partial, and prioritized regression
Module Lessons
- Re-test — I'll Check That Again — The exact workflow for verifying a closed bug, and what to do when the fix didn't stick
- Regression Test — The Butterfly Effect — How to identify which areas to test after any code change
- Regression Strategy — How to Stay Sane — Full vs. partial vs. prioritized regression and when to use each
🏅 Complete all three lessons to earn the Stability Guardian badge — for QAs who make sure nothing breaks in the shadows while the team is focused on the spotlight.