Endur release testing: what else changed?

Endur release testing starts with a list. Every release arrives with one: report definitions, regulatory reporting, queries, tasks, plugins, trade templates, simulation definitions, scripts, date sequences. Each item is deliberate. You know what you changed.

But the list answers only one question. The harder one is what else changed, and a list can’t help with that, because it only holds what someone expected. The same question applies to Findur and Allegro, and to any ETRM platform that changes over time.

The short answer is that a release can change more than its contents list. The way to find out is to compare the system before and after, using the same trades and the same market data.

What else can change in an Endur release?

The figures used are illustrative, but the pattern is the one that matters.

Take two versions of the same system: the unchanged one, which we’ll call master, and the changed one, the candidate. First, check that the starting point is identical. The trade population matches. The system configuration matches. The market data matches. Everything that goes in is the same, so any difference that comes out must have come from the release. That step matters. If the trades or the prices had differed, the gap could have a dozen explanations. With matching inputs, the release is the only suspect.

Then a simulation result differs. Master shows $14,821,610. The candidate shows $14,634,180. The gap is $187,430. Nobody placed a trade and nobody moved a price. Nobody decided the number should change, and yet it has.

The difference doesn’t stay where it started. A valuation like this could reach the P&L report, the risk report, account posting, and regulatory reporting. One underlying change, several possible consequences.

Here’s the same story in 45 seconds. The video shows Endur, but the question belongs to any ETRM team.

Why isn't a list of changes enough?

Checking that the screens open and the system runs only tells you the software works. It doesn’t tell you the numbers underneath haven’t moved. The logic that produces a number sits below the screen, and that’s where a change can hide. A spot check looks at a handful of trades, and the difference may sit in the one you didn’t pick. If you only test what’s on the list, what covers everything that isn’t?

None of this is a criticism of the people doing the testing. A release bundles a lot of change into one go, and a list is a sensible place to start. It just isn’t the whole picture.

How do you find out what changed?

Compare before and after, in a logical order, from the simple to the complex. The order matters, because comparing valuations tells you little if the market data underneath has moved.

Foundations come first: system settings, scripts and definitions. Then the trade lifecycle and end of day, comparing like-for-like results. Then multi-day, where business time moves forward, and events such as futures closeout, cascade and roll to physical are run and compared. At each stage, the outputs are checked too: documents, invoices, settlement and reporting.

This is the approach behind Triangle, Trinitatum’s test automation platform, which supports ION Endur, ION Findur and Allegro. It compares the changed system with the unchanged one and shows you where they differ. The result is a record of what was compared, what matched, and where the two differ, which a person can review.

A difference isn’t automatically a failure. Some are the expected result of the release, and a person decides which. What a comparison gives you is certainty about the change itself. It doesn’t claim the original was right, and it shouldn’t.

Why does it matter beyond the trading desk?

The transaction reports a firm files, the positions it monitors and the numbers in its financial statements are produced, in large part, by the ETRM system. A change that moves them without anyone deciding it should is the risk our white paper, The cost of finding out later, sets out. Its finding is that firms usually find out later, in a rejected report, a breached limit or an audit finding. A comparison made before go-live moves that moment earlier.

Four questions to ask before your next release

These are worth asking whether or not you use a tool.

1. If a number moved that wasn’t on the list of changes, how would you know?
2. Which outputs would you compare, and who owns each one?
3. Could you run the same check next time and get a like-for-like answer?
4. Could you show someone exactly what changed, and what you decided about it?

Back to the list. You know what you changed. The more useful question is what else did.