Define success before recording
Write down the starting screen, the input and the evidence that the task completed. For a report export, success means the expected output exists and is correct; selecting Export alone does not prove that.
Choose a small test task first. Use sample data and identify the errors or delays you can reproduce.
Put checks around important actions
A short sequence with clear checks is easier to inspect than a long recording full of timing assumptions.
- Target the intended window before interacting.
- Wait for a recognisable ready state.
- Perform the action using a suitable target.
- Check the expected result before moving on.
- Handle a known error or timeout with an explicit outcome.
Retry only when repeating is appropriate
A retry can help when an expected element is briefly absent. It can also duplicate a submission if the first request completed but its confirmation was delayed.
Set a finite retry count and check the result of the original action first. Add a time or loop limit so an unexpected screen cannot keep the workflow running indefinitely.
Test the assumptions, then expand
Try slow responses, moved windows, empty inputs and known error states. Check OCR reads against their source. Review the actual output rather than judging success only by the last action in the sequence.
Once the workflow behaves correctly on one PC, document its setup and validate any additional devices. Shared profiles and central monitoring can help manage deployment, but they do not replace testing the application environment.