Regression Test — The Butterfly Effect

Learning Objectives

By the end of this lesson, you'll be able to:

• 🦋 Explain the butterfly effect in software and why regression testing exists
• 🔍 Identify which areas to test after a code change
• 🗺️ Understand the concept of impact analysis
• 🚫 Distinguish regression testing from re-testing

The Big Idea

Edward Lorenz asked: can a butterfly flapping its wings in Brazil cause a tornado in Texas?

In software, the answer is yes. A typo fix in a CSS label can break the JavaScript selector that reads that label. A database index optimization in the user module can cause a 3-second slowdown on the dashboard. A change to the API response structure can silently break a mobile app feature that parses that response.

This is why regression testing exists. Every time code changes, there's a risk that something that worked before stops working. Even if the change seemed completely unrelated.

What Is Regression Testing?

Regression testing is the process of verifying that existing functionality still works correctly after a code change.

Key characteristics:

• It's triggered by any code change — a bug fix, a new feature, a refactor, a configuration update
• It covers areas beyond the changed code — the changed area plus its neighbors and integration points
• Its goal is to catch unintended side effects — not to verify the new feature (that's functional testing) and not just the specific fix (that's re-testing)

The core question: "Did we break anything that used to work?"

The Butterfly Effect in Action

Let's trace a real-world ripple:

The "small" change: A developer renames the CSS class .btn-primary to .btn-main throughout the app to align with a new design system.

The hidden ripple:

1. The checkout page has a JavaScript file that reads document.querySelector('.btn-primary') to attach a click handler to the "Place Order" button
2. After the rename, the selector returns null
3. The "Place Order" button is still visible — but clicking it does nothing
4. Orders stop being placed

The impact: A CSS rename broke the checkout flow. The developer didn't touch the JavaScript file. They didn't touch the checkout page. But the butterfly flapped its wings.

Regression testing would have caught this — if the QA ran the checkout flow after the CSS change.

What to Regression Test After a Change

This is the most important skill: impact analysis — figuring out what could possibly be affected by a change.

The Three Rings

Draw three mental rings around any change:

Ring 1 — Direct area: The thing that was explicitly changed. → Test it directly (this is also your re-test if it was a bug fix)

Ring 2 — Adjacent features: Features that share code, data, UI components, or workflows with the changed area. → Test these next. They're the most likely to have broken.

Ring 3 — Integration points: APIs, databases, third-party services, or event systems that interact with the changed area. → Spot-check these. Less likely to break, but breaks here are catastrophic.

Practical Examples

Change: Login form validation logic updated

Ring 1: The login form itself — valid/invalid credentials, error messages Ring 2: Registration (shares password validation), password reset (shares email validation), SSO (shares session creation) Ring 3: API endpoints called by login, session cookies, analytics events

Regression vs. Re-test: The Key Difference

A common mistake: treating regression testing as just "re-testing all the old bugs." Regression is broader — it's about functional stability after change.

Pro Tips

💡 Ask developers "what did you touch?" before starting regression. A developer who just fixed a bug knows which files they modified. Start there and expand outward.

💡 Prioritize by risk, not by feature size. A change to the payment module needs more regression than a change to the "About Us" page, even if the "About Us" page is bigger.

💡 Every regression test you document today is a time-saver tomorrow. If you write down which areas you tested and why, you build a regression checklist over time. Lesson 2.3 covers this.

Summary

• 🦋 Regression testing exists because code changes have ripple effects that affect unrelated features
• 🔍 Use the three rings model: direct area → adjacent features → integration points
• 🎯 Goal: "Did we break anything that used to work?"
• 🚫 Regression ≠ re-test: regression is broader, covers more area, and is triggered by any change
• 📋 Impact analysis is the skill that makes regression testing effective

Up next: Lesson 2.3 — Regression Strategy: how to decide between full, partial, and prioritized regression without losing your mind. ⚖️