Test transitions across roles

Page tests are still useful, but a release suite for a multi-portal workflow has to follow transitions. Start from a known state, do something as one role, let the documented processing path run, and then look at the result as every affected role. Assert on the stored state and the integration evidence as well as on the visible text.

Include variations that shake out boundary failures:

• repeated submission with the same operation identifier
• a delayed or duplicated external event
• events delivered out of order
• a role removed between request and approval
• an expired session with a stale page still 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 your automated tests so they stay repeatable. Keep a smaller set of checks in the deployed environment for configuration, callback URLs, credentials and actual routing, because a mocked test can't tell you whether the external service is calling the right environment.

After a fix, rerun the original trace without changing the test data partway through. Then test the nearest opposite case, like an unauthorised role or a rejected external action. A repair that gets the happy path passing by relaxing a condition will often fail there.

Watch the observability while you're testing. Can an operator find the operation using the identifier the user was shown? Does a failed transition leave a record someone can see? Can support tell whether a retry is safe? If the system only works while a developer is reading the application logs, it isn't ready for routine release support yet.