Test transitions instead of isolated pages

Page tests remain useful, but a release suite for a multi-portal workflow needs to follow transitions. Begin in a known state, perform an action as one role, allow the documented processing path to run, and inspect the result as every affected role. Assert stored state and integration evidence as well as visible text.

Include variations that expose boundary failures:

• repeated submission with the same operation identifier;
• a delayed or duplicated external event;
• an event delivered out of order;
• a role removed between request and approval;
• an expired session with a stale page open;
• a partial integration response;
• an item moved to another account or ownership scope;
• a timestamp close to a business-day boundary.

Control time, queues and external responses in automated tests so they remain repeatable. Keep a smaller set of deployed-environment checks for configuration, callback URLs, credentials and actual routing. A mocked test cannot prove that the external service is calling the correct environment.

After a fix, rerun the original trace without changing the test data halfway through. Then test the nearest opposite case, such as an unauthorised role or a rejected external action. A repair that makes the happy path pass by relaxing a condition often fails there.

Pay attention to observability during the test. Can an operator find the operation using the identifier shown to the user? Does a failed transition create a visible record? Can support tell whether retry is safe? If the system works only while a developer is reading application logs, it is not ready for routine release support.