Regression testing: re-running tests after a change to confirm existing functionality still works.
Why it matters:
- Software changes break things.
- New feature affects unrelated areas.
- Bug fix accidentally re-introduces another bug.
- Salesforce platform changes affect existing config.
When to regression test:
- After every release — full regression suite.
- After Salesforce platform releases (3 times/year) — confirm nothing broke.
- After integration changes — affected systems re-tested.
- After bug fixes — confirm fix doesn't break elsewhere.
- Continuously in CI/CD — every commit triggers smoke tests.
Approach:
1. Build regression suite.
- Comprehensive set of tests covering critical paths.
- Smoke tests (fast subset for quick checks).
- Full regression (deep coverage for major releases).
2. Automate where possible.
- Manual regression for 1000-test suite is impractical.
- Automation makes regression sustainable.
3. Maintain.
- Update tests as features change.
- Remove obsolete tests.
- Add tests for new features.
4. Run strategically.
- Smoke tests on every commit.
- Full regression weekly / before releases.
- After platform updates.
5. Triage failures.
- Distinguish test bugs from product bugs.
- Fix product bugs; update test bugs.
Common pitfalls:
- No regression suite — bugs find production.
- Stale tests — tests don't match current product.
- Manual-only regression — too slow; gets skipped.
- Flaky tests — failing intermittently; teams ignore.
Senior QA insight: regression suite is QA infrastructure. Invest deliberately. Pays back across every release.
The senior framing: without regression, every release is risky. With it, releases become routine.