Six examples from everyday use — as a starting point to adapt to your own application, not as a rigid template.
Instead of manually clicking through every important flow after each release, GUI Test Studio replays the previously recorded test case automatically. If the layout shifted slightly, the image-anchor search still finds the click targets — and if a step fails anyway, the color-coded live log immediately shows where.
A marked screen region is saved as a reference image and compared pixel by pixel against the current state on every replay. If the deviation is too large, the step fails, a diff image is generated and shown directly in the HTML report — ideal for layout, icons and static text.
Instead of a rigid image comparison, Claude judges the screenshot against a freely worded instruction and returns a verdict with reasoning — useful for states that can't be captured with fixed reference images (e.g. changing amounts or text).
During a long-running test case (e.g. cycling through an application for hours), GUI Test Studio logs CPU, RAM, threads, handles and modules every two seconds. If RAM usage exceeds the project-specific threshold for the detected process bitness (x86/x64), the display turns red — a clear early warning of a possible memory leak, long before the application crashes.
Some exceptions are caught internally by the target application and only logged, without anything showing up on screen. GUI Test Studio continuously scans the target application's log/crash directory for error patterns and additionally captures .NET exceptions directly via ClrMD with a real, symbolicated stack trace — both automatically get attached to the most recently executed test step in the log.
Detected changes of the active window/dialog and the focused control are automatically logged in the diagnostics panel — indented by window level. This lets you attribute a reported exception directly to the interaction step that triggered it, instead of just seeing a raw stack trace.