Test routine and unusual cases before changing automation

What this means for your practice

Maintain a small test set based on the actual workflow's normal and exceptional cases. Review results before release and keep unresolved issues visible to the decision owner.

A practical conversation with your supplier

Replay incomplete and repeated fictional events through the changed workflow. Check receiving records and notifications, not just the starting screen. Record limitations for the person deciding whether to release. The collection should help prevent known problems returning, rather than grow into an unreadable list of theoretical situations.

Plan the first improvement

Build the test collection from actual workflow decisions, using fictional details. Include normal activity, missing information, repeated events, changed records and unavailable connected services where relevant. For each example, describe the expected result in business language and name the person who can accept it. A test should check the receiving task or message, not stop when the starting screen says success. Keep previous failures in the collection when they reveal a meaningful risk of recurrence.

At the same time, remove obsolete examples when the workflow intentionally changes, recording why the expected behaviour is different. Ask the supplier to present unresolved limitations alongside successful checks before release. The decision owner should understand what remains uncertain and what fallback is available. After a real issue, consider whether the existing collection should have detected it or whether the workflow encountered a genuinely new situation. That distinction helps improve testing without simply adding a long list that nobody can explain or maintain.

How to check the result

Record problems introduced after release that the agreed examples should have detected.