Ask any programme director what keeps them awake before a major ERP release and very few will say the new features. New functionality is specified, built, demonstrated and signed off. It is visible, and visible risk gets managed.

The damage usually comes from somewhere else. A change to a pricing condition that also touched intercompany billing. A tax configuration update that quietly altered how one country's postings were determined. An interface whose payload gained a field. None of it was in scope, all of it was in the blast radius.

Why coverage decays

Most organisations built a regression pack once, usually during the original implementation, and it has been eroding ever since. The business changed, the configuration changed, and the test scripts did not. Steps refer to screens that moved. Test data has gone stale. Expected results encode assumptions that were revised three years ago.

What is left is a suite that takes weeks to execute, that a shrinking number of people understand, and that everyone privately suspects is not testing very much. When the timeline compresses, and it always compresses, that suite is the first thing to be sampled rather than run.

The economics are what force the shortcut

Manual regression testing is expensive in the one resource an ERP programme has least of, which is the time of people who genuinely understand the process. The person best placed to confirm that an intercompany posting is correct is usually also the person the programme needs for design decisions that week.

So testing gets rationed. The team tests what changed, plus whatever the most anxious stakeholder insists on, and hopes the rest holds. Sometimes it does.

Building a suite that survives

A few principles tend to separate regression packs that stay useful from those that rot.

  • Derive tests from process, not from screens. Scripts written against a user interface break every time the interface moves. Scripts written against a business outcome survive upgrades.
  • Own your test data. A suite that depends on a particular customer record existing in a particular state will fail for reasons that have nothing to do with the code.
  • Test the integrations hardest. In a multi-system estate, the majority of production defects surface at boundaries, not inside a single application.
  • Make execution cheap enough to be routine. A suite that is expensive to run will be run rarely, and a suite that is run rarely is a suite that no longer reflects the system.

Where automation genuinely helps

Generating test cases from user stories and existing configuration, then executing them without occupying your best process people for a fortnight, changes the calculation. It moves regression from an event that happens near go-live to something that happens continuously, which is the only version that actually catches the quiet defect.

The objective is not a higher test count. It is to stop discovering in production the things that were true all along.