Small settings with a big impact — from image-anchor accuracy to getting the most out of the run history of your automated workflows.
All three hotkeys work at any time while recording, regardless of which window currently has focus.
Two settings determine how reliably a click target gets found again during playback:
Tip: If a step starts failing more often after an update to the target application, check the match score shown in the report first — often a slightly adjusted patch size or minimum match score fixes it, no need to re-record the step.
Enabling "Stop on error" pauses playback immediately at a failed step instead of letting the entire test case — with possible follow-on failures — run to the end. This is particularly useful whenever a single step needs to be traced precisely — whether during testing or while running an automated workflow in production — because the target application stays exactly in the state it was in when the error occurred.
After adjusting a test case, it doesn't have to be played from the beginning again: playback can be resumed from any step, so only the changed part of the flow needs to be re-checked.
Note: If "Stop on error" stays disabled, subsequent steps keep running against an already inconsistent state of the target application — the follow-on failures that show up in the report then say nothing about the actual root cause. For targeted debugging, combine "Stop on error" with resuming from the affected step.
Repeat runs aren't just for stability testing: the same feature can be used to have a recurring batch or routine task in your line-of-business application processed automatically, multiple times in a row — for example, running the same data-entry flow for an entire list of records. With 1 to 999 repeat runs and a live progress display, the same test case can be played back automatically across many runs — ideal for stability testing as well as for working through recurring business tasks in sequence.
Tip: For unstable UI states, also use the retry logic and the tolerance control in the image comparison — that prevents a single, briefly deviating state from unnecessarily breaking the whole series of repeat runs.
For larger projects, test cases can be organized in deeply nested folder structures, for example split by customer, module, or business area. Individual test cases or entire folders can be exported and handed to colleagues — the folder structure is fully preserved on import, so nobody has to rebuild the layout by hand.
Whether tracking down a bug after a fix or documenting a recurring business task, the history of past runs of a test case can be searched at any time. Two runs can be compared directly — for example the last run before a bugfix and the first one after — to see at a glance which step changed. Metadata and comments stored per run make sure that, even months later, it's still clear why a run was performed and what stood out.