Regression testing in Software Engineering - Step-by-Step Execution

Concept Flow - Regression testing

Start: Code change made (bug fix, feature, refactor)

↓

Identify affected modules

↓

Select regression test suite

↓

Run selected tests against updated code

↓

All tests pass?

Yes→Deploy with confidence

No↓

Identify failing tests

↓

Is failure a real bug or intended change?

↓

Real bug: Fix code

↓

Re-run regression suite

↓

End

This flow shows how regression testing verifies that new code changes do not break existing functionality by running a suite of previously passing tests.

Execution Sample

Software Engineering

Code change: Fix login timeout bug
Identify affected: auth module, session module
Select tests: 45 auth tests + 12 session tests + 20 smoke tests
Run suite: 77 tests executed
Results: 75 pass, 2 fail
Analyze failures: session_expiry_test, token_refresh_test
Diagnosis: timeout fix broke token refresh logic
Fix: Update token refresh to use new timeout value
Re-run: 77/77 pass

This sequence shows a regression testing cycle after a bug fix, where the fix inadvertently broke two related tests.

Analysis Table

Step	Action	Condition/Check	Result/Decision	Next Step
1	Developer fixes login timeout bug	N/A	Code changed in auth module	Identify affected modules
2	Identify modules affected by change	Dependency analysis	auth + session modules affected	Select test suite
3	Select regression test suite	Based on affected modules + smoke tests	77 tests selected	Run tests
4	Run regression tests	Execute all 77 tests	75 pass, 2 fail	Analyze failures
5	Analyze failing tests	Are failures real bugs or intended?	Real bugs — token refresh broken	Fix the code
6	Fix token refresh logic	N/A	Code updated	Re-run regression suite
7	Re-run regression suite	All 77 tests	77/77 pass	End — safe to deploy

💡 Regression testing confirmed the fix works without breaking existing functionality. The code is safe to deploy.

State Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	Final
code_state	Timeout bug present	Bug fixed, untested	2 regressions found	Regressions fixed	All tests pass
tests_selected	0	0	77	77	77
tests_passing	N/A	N/A	75/77	N/A	77/77
deploy_ready	No	No	No (failures)	No (untested)	Yes

Key Insights - 3 Insights

Why do we run regression tests after every code change?

Code changes can have unintended side effects on existing functionality. Regression testing catches these regressions before they reach production, as demonstrated in step 4 where the timeout fix broke token refresh.

How do you decide which tests to include in the regression suite?

Tests are selected based on the modules affected by the change plus smoke tests that cover critical paths. As shown in step 3, dependency analysis identifies that auth changes also affect the session module.

What is the difference between a real regression and an intended behavior change?

A real regression means the code change broke something unintentionally (fix the code). An intended change means the old test expectation is outdated (update the test). Step 5 shows this decision point.

Visual Quiz - 3 Questions

Look at the execution_table at step 4. What happened when the regression suite was run?

A All 77 tests passed

B 75 tests passed and 2 failed

C The test suite could not run

D Only smoke tests were executed

💡 Hint

Check the 'Result/Decision' column in step 4.

According to the variable_tracker, when does deploy_ready become Yes?

A After the initial code fix

B After selecting the test suite

C After all 77 tests pass in the final run

D After analyzing the failing tests

💡 Hint

Look at the deploy_ready row across all columns.

Why were session module tests included in the regression suite even though the fix was in the auth module?

A Session tests are always run regardless

B The session module depends on the auth module

C Session tests are faster to run

D The developer requested them manually

💡 Hint

Check step 2 where dependency analysis identifies affected modules.

Concept Snapshot

Regression testing verifies that code changes do not break existing functionality.
After every change: identify affected modules, select tests, run suite.
Failures are analyzed: real bugs get fixed, intended changes update tests.
The cycle repeats until all tests pass — then deploy is safe.
Automation makes regression testing practical for frequent releases.

Full Transcript

This visual execution shows regression testing in action. After a developer fixes a login timeout bug, the team identifies that both the auth and session modules are affected. A regression suite of 77 tests is selected and run. Two tests fail, revealing that the timeout fix broke the token refresh logic. The team fixes the code and re-runs the suite, getting all 77 tests to pass. Only then is the code considered safe to deploy. This cycle of change, test, fix, and re-test is the core of regression testing.