Regression Testing
Use when asked to verify that a change hasn't broken existing functionality — test-case selection, defect reporting/resolution, retesting — the discipline that makes safe, frequent releases possible, closely tied to test-driven development's refactor-safety guarantee (see test-driven-development).
Regression testing confirms that changes or updates to a software application don't introduce new bugs into functionality that previously worked — retesting the whole system, or a targeted subset, to verify existing behavior still holds and that the new change hasn't caused an unintended negative impact elsewhere.
When it's run
After any software update or change, and often also on a regular ongoing cadence as part of routine quality assurance — not only reactively after a specific change, since a change in one area can have unintended effects in a seemingly unrelated one.
The process
- Test plan creation — define the scope: which features/ functionality will be tested and by what method.
- Test case selection — draw from existing test suites, or create new cases specifically for this regression pass, covering a range of functionality and scenarios broad enough to actually catch an unintended side effect.
- Test execution — run the selected cases against the updated software.
- Defect reporting — document and report anything found to the development team.
- Defect resolution — the team fixes identified issues.
- Retesting — verify the fix actually resolved the issue and that the software behaves as intended afterward.
Why automation matters here specifically
Regression testing is the textbook case for automation: the same tests run repeatedly, unchanged, against every new version — exactly the repetitive, mechanical work automation suits best, and exactly what Test Driven Development's accumulated test suite provides as a byproduct: every TDD cycle adds another regression check for free.
Common pitfalls
- Selecting too narrow a regression scope — testing only the directly changed feature misses side effects in other, seemingly unrelated areas the change actually touched.
- A large, unautomated regression suite — a suite that requires extensive manual re-execution on every change either doesn't get run often enough, or consumes disproportionate time relative to the change size.
- Not retesting after a fix — confirming the original defect is gone isn't enough; the retest should also confirm the fix itself didn't introduce a new regression.
- Treating regression testing as separate from ongoing test-suite maintenance — an out-of-date regression suite (testing behavior the application no longer has, or missing coverage for newer features) gives false confidence.
Learn more
- Test Driven Development for how a regression suite accumulates as a natural byproduct of test-first development.
- End to End Testing, Integration Testing, Unit Testing for the levels a regression suite typically spans.