A Regression Testing Strategy That Survives ERP Releases

The defining problem with testing an ERP is that nothing is isolated. A change to how a sale is recorded moves inventory, changes a customer's balance, and shows up in a report that finance signs off on. Test the screen that changed and you will miss the defect entirely.

You also cannot re-test everything before every release. So the real skill is deciding what to re-test — deliberately, and in a way you can defend when something slips through anyway.

Map the data, not the screens

Before writing a single test case, work out which modules share which records. For a real-estate ERP that meant tracing questions like:

• When a sale is recorded, which tables change?
• Which reports read those tables?
• Which other module can also modify the same rows?

The output is a rough dependency map, and it changes how you read a changelog. "We changed the discount calculation" stops being one screen and becomes: the sales entry screen, the customer balance, the commission calculation, and three reports.

That map is the most valuable artefact you will build, and it lives in a document, not in your head — because you will hand it to whoever tests this after you.

Tier your test cases by consequence

Not every test deserves equal time. I sort into three tiers:

Tier 1 — money and data integrity. Anything that calculates an amount, changes stock, or writes a financial record. These run every single release, no exceptions. A rounding error here reaches an invoice.

Tier 2 — core workflows. The end-to-end paths the business runs on: create a customer, record a sale, generate the invoice, take a payment. These run every release too, but as a workflow pass rather than field-level checks.

Tier 3 — everything else. Layout, filters, sorting, export formatting, help text. These rotate — a different slice each release — so everything gets covered over a few cycles without being re-tested every time.

When time runs short, Tier 3 is what gets cut. Deciding that in advance is much better than deciding it at 9pm the night before a release.

Choose the regression set from the change, not from habit

For each release I look at what actually changed and pull in:

1. Every Tier 1 case. Always.
2. Tier 2 workflows that touch the changed modules, traced through the dependency map.
3. The specific cases for each bug fixed in this release — and the neighbouring cases around each fix.
4. Whatever Tier 3 slice is up in the rotation.

Point 3 is where the value is. A fix is a change, and changes break things. The case that most often fails is not the one that was fixed but the one immediately beside it — fixed-amount discounts breaking after percentage discounts were repaired.

Verify at the database, not the interface

In ERP testing this is not optional. The interface routinely displays a correct-looking number that was computed on the fly while the stored record is wrong — and it is the stored record that flows into next month's report.

So for every Tier 1 case, the verification step is a query, not a screenshot. Record a sale, then check the sale row, the inventory movement, and the customer balance are all consistent with each other. Learning enough SQL to do this yourself, rather than asking a developer, roughly doubles the number of defects you can find.

Keep a defect-driven suite

Every production defect that reaches a user is a gap in the regression set. So each one earns a permanent test case, added at the tier its severity deserves.

Over a year this becomes the most valuable part of the suite, because it is not built from what someone imagined might break — it is built from what actually broke, in this system, with this team.

Write down what you did not test

The regression report should say what was covered, what was not, and why. "Tier 3 export formatting was not re-tested this cycle" is a professional statement of scope. Silence implies you tested everything, and when a defect surfaces in an untested area, silence is what makes it look like a miss rather than a documented trade-off.

This is the difference between a tester who is trusted and one who is blamed. Nobody can test everything. The person who says clearly what they did and did not cover is the person whose sign-off means something.

Automate the boring end first

Full UI automation on an ERP is a large investment and often a poor first one — the screens change and the tests break. What pays back quickly is automating the verification:

• SQL scripts that check data consistency across modules and report anomalies
• Postman collections asserting the API contracts behind the screens
• Saved query sets that reconcile a report's output against its source tables

That gets you repeatable, fast checks on exactly the layer where the expensive defects live, without maintaining a brittle click-through suite.

The summary

Regression testing on an ERP is a prioritisation exercise, not a completeness exercise. Map the dependencies, tier by consequence, choose the set from what changed, verify in the database, feed every escaped defect back into the suite, and document what you left out. That is a strategy you can run under deadline pressure and still defend afterwards.