Previously failed transactions

As mentioned above, the Dynamic ID process does a good job of ensuring that if, for example, a “Create Order” transaction fails during the playback, then subsequent Display or Change transactions for that same order are cancelled. However, some interdependencies between transactions are not so straightforward and this can lead to transaction failures during the playback which are not covered by the Dynamic ID process.

A good example of this is list processing, where a user calls up a list of available orders of a particular status (e.g., orders ready for fulfilment). It may be that when the user executed this transaction in production there were 15 orders in the list; however, during the playback one of the previous Create Order transactions failed, meaning that there are now only 14 orders in the list. If we try to double-click on the 15th order in the playback, we will get an error.

Batch jobs also provide a good example of where previously failed transactions may result in a playback error. Again, it may be that when the batch job ran in production there were 15 orders for it to process, but during the playback only 14 orders were processed because a previous transaction failed. This will be flagged by Testimony as a difference – and hence a script failure – as the batch job log will only contain entries for 14 records rather than the 15 that were expected.