Every ETRM/CTRM team has a regression test pack. Most teams privately suspect theirs isn’t covering enough.
That suspicion is usually right. Regression packs tend to grow through accretion: a release introduces a new feature, someone writes a test, the test joins the pack and nobody takes anything out. Over time the pack gets bigger without getting more useful. Coverage of what the business actually does today drifts out of sync with what’s actually in the pack.
The question “what should a regression test pack cover?” is less about what to add and more about what the pack needs to prove.
Here’s a working scope for teams running Endur, Findur or Allegro.
A regression pack has one job: to prove that the things that worked before the change still work after it.
Not that the system is bug-free. Not that the change itself is correct (that’s acceptance testing). Not that the system can handle peak load (that’s performance testing). Just: did anything that was working before stop working now?
That focus matters because it reshapes what belongs in the pack. If a test isn’t checking something that worked before and might not after, it isn’t a regression test. Which is a surprisingly useful filter when you start applying it to packs that have grown over the years.
Six scope areas cover most ETRM/CTRM release readiness. Each one has a different failure mode, and leaving any of them out is where regression packs come apart.
1. Trade lifecycle coverage. Every trade type the business books, from initial capture through confirmation, settlement, delivery, invoicing and accrual. Not every trade type the system supports; every type the business uses. The pack should fail if any step in a lifecycle stops working for any live trade type.
2. Position aggregation. How trades roll up into positions, at every level the business monitors: book, desk, portfolio, limit basis, regulatory reporting basis. A regression pack that passes at the trade level but doesn’t check aggregation catches half the breaks.
3. Valuation and risk outputs. The numbers that feed financial reporting, risk limits and collateral. The pack should check that the outputs match the previous version for a representative set of positions, within an agreed tolerance. Anything outside tolerance is a candidate break, even if the calculation is “technically correct”.
4. Integrations and feeds. Market data in, confirmations out, downstream feeds to risk, finance, settlement and regulatory reporting. Integration regression is often the weakest layer because it depends on another system also behaving the same way. Worth testing with both production-like data and edge cases.
5. Static data integrity. Counterparties, products, calendars, settlement instructions. These change rarely but when they drift, the consequences are subtle. A regression pack should assert that key static data still resolves correctly and still produces expected downstream behaviour.
6. Business workflows end-to-end. Trade capture to settlement for the main product types. User role to permission to action. The scenarios the business actually runs, not just the components the system is built from. End-to-end flows catch the integration-point breaks that unit-level tests miss.
Scope is one thing. Reusability is another. A regression pack that covers all six categories but has to be rebuilt before every release is barely a pack at all. Three characteristics separate reusable packs from one-shot ones.
A regression pack isn’t where everything belongs. Three things worth deliberately excluding:
A regression pack doing its job produces three signals at release time:
Triangle, our test automation software, is purpose-built for building and maintaining the kind of regression pack this guide describes. It generates tests from your current Endur, Findur or Allegro configuration (so the pack stays current without manual effort), runs them at the API layer across the full population (so coverage is deep, not sampled) and produces time-stamped evidence as a byproduct of every run.