Problem Solving
Problem solving is the CPRSA domain that tests whether you can diagnose automation failures and design automations that fail safely. Strong candidates isolate the failing layer before changing code.
Diagnose by layer
Application layer: the target app is not running, has a modal dialog, is on a locked session, or has changed version. Adapter layer: match rules no longer find the control, targets are ambiguous, or a popup opened a new window. Automation layer: an unhandled exception, wrong variable type, loop condition, or shared global container value. Runtime layer: credentials expired, package version mismatch, or Robot Manager queue assignment. Work from the outside in: reproduce, read the log, then test the match in the Interrogator.
Make failures visible and recoverable
Use Try/Catch around risky steps, throw a BusinessException for a rule violation and a SystemException for a technical fault, and log the work item ID and step name. Replace fixed sleeps with WaitForCreate, WaitForVisible, or WaitForReady. Add bounded retries with a counter, and keep work items idempotent so a retry does not duplicate a transaction.
Worked example
A web automation fails intermittently at Submit because a session-timeout modal appears. The old design used a two-second sleep and a loose Submit match rule that also matched a hidden button. Reasoning: the sleep does not wait for the modal, and the loose rule matches the wrong control. Fix: add WaitForCreate on the modal, handle it, re-interrogate Submit with a more specific match rule using control type, parent, and visible text, and wrap the step in a retry. Test with a forced timeout.
Traps
- Adding longer sleeps instead of real waits.
- Catching all exceptions and swallowing them.
- Using loose match rules that match the first similar control.
- Not re-interrogating after an application patch.
- Testing only the happy path.