Panaya

Panaya Test Automation 26.08.105: reduce migration and execution recovery delays

Panaya Test Automation 26.08.105 helps enterprise teams convert Worksoft SAP GUI exports into runnable, locator-based Panaya tests through a beta import capability. It also makes flaky-test patterns, AI-healed steps, draft executions, test-set dependencies, and timeout-expired runs more visible and manageable. For governed automation programs, the release improves migration planning, audit evidence, execution recovery, and maintenance of component-based scripts.

By Chris CarpenterTest AutomationSAP TestingQA
Panaya_Logo.svgPanaya Test Automation Transparent Logo.png
Panaya Test Automation 26.08.105: reduce migration and execution recovery delays cover graphic
Back to Panaya release updates
Release facts
VendorPanaya
ProductPanaya Test Automation
Version26.08.105
Published by MeritoAugust 3, 2026
Newer release covered26.11.103 (November 1, 2026)
Release historyPanaya Test Automation release history

Worksoft SAP GUI exports can now be converted into runnable, locator-based Panaya scripts in beta, giving release owners a practical route to assess and migrate existing automation assets rather than rebuilding every SAP flow manually.

Worksoft migration enters a controlled beta phase

The new import capability supports both flat and componentized Worksoft SAP GUI structures, with single and bulk import options. For organizations carrying a substantial Worksoft estate, this changes the migration discussion from a blank-sheet rewrite to a managed conversion and validation program.

The import is beta-only and requires access through Panaya Support. Release leaders should treat converted scripts as migration candidates, not automatically production-ready assets. A sensible control model includes:

  • Classifying scripts by business criticality and technical complexity
  • Comparing converted coverage against source artifacts
  • Running baseline executions in representative SAP environments
  • Reviewing locator behavior, parameters, and reusable components
  • Retaining approval evidence before retiring legacy scripts

This approach helps protect regression coverage while avoiding uncontrolled parallel maintenance across two automation platforms.

Faster detection of unstable tests

The test list now displays the status of the last ten automated runs as Passed, Failed, or Skipped bars, with the newest outcome highlighted on the right. Selecting a run opens its planned-run details; where a test has multiple planned runs, a neutral indicator directs users to the full test execution view.

For QA and DevOps leaders, this is a useful operational signal. Repeated failure patterns can be identified during release readiness reviews without first assembling data from multiple execution records. It also helps teams distinguish a single infrastructure issue from a test that needs engineering attention.

Use this view alongside defect trends and agent health data. A failed run alone is not proof of a script defect, but recurring status variation should trigger triage, ownership, and a documented remediation decision.

Recover large executions after agent queue expiry

Executions skipped because they exceeded the 24-hour agent timeout can now be rerun directly. Teams no longer need to restart a full execution merely because queued tests expired before an agent became available.

This matters for high-volume suites, shared execution infrastructure, and tightly timed release windows. It reduces avoidable rerun volume and preserves more of the original execution context.

Release owners should still measure timeout-expired runs as a capacity and scheduling signal. Repeated expiry can indicate insufficient agents, poorly distributed tags, overlapping schedules, or test suites that need segmentation. Recovery is useful; prevention remains the better operating model.

Improve traceability and review context

A new Test Sets tab shows every test set that uses an automated test and indicates whether that test participates in a dependency chain. This gives architects and test managers a clearer basis for impact analysis before changing a shared test.

The release also adds clickable component names in the Script tab. Reviewers can open referenced components in another browser tab, reducing navigation friction in large, component-based automation repositories.

These additions support stronger change governance:

  • Identify affected regression packs before modifying a test
  • Check dependency context before adjusting execution order
  • Review shared components without losing the calling script
  • Record impact decisions for audit and release approval

Make AI-assisted execution visible

When AI Self-Healing allows an instruction to pass, Run Results now display a clear indicator beside that instruction. This is an important transparency control: reviewers can see when a successful result depended on AI-assisted recovery rather than the originally recorded locator behavior.

Teams should define how healed steps are handled in their quality process. For example, a healed step in a low-risk user-interface check may be accepted with monitoring, while healing in a regulated approval flow may require review before release sign-off. The indicator provides evidence for that decision; it does not replace the decision.

Improve visual evidence and script maintenance

Compare mode in run details now includes improved navigation, a larger viewing area, and an interactive Slider view for examining visual differences between executions. This can shorten evidence review when teams need to establish whether a screen change is expected, cosmetic, or a functional regression.

ScriptBuilder also adds several maintenance improvements:

  • Add comments to Take Screenshot instructions to identify evidence needing attention
  • Copy and paste consecutive instruction groups within or across tests and components
  • Separate script-specific properties from default settings with direct navigation
  • Reference global parameters by name, with runtime resolution of the nearest match

Named global-parameter resolution supports reusable scripts across folder and project structures without editing each script. Governance still matters: parameter naming conventions, ownership, and change records are needed to prevent unexpected value selection in complex hierarchies.

Clarify draft execution status

Draft executions are now labeled across the run automation dialog, planned runs, run history, and Automation Executions page. Teams can more easily distinguish executions based on unpublished script changes from those using published test versions.

This helps prevent a common reporting problem: stakeholders interpreting a draft result as formal release evidence. Delivery governance should specify whether draft runs can support debugging only, pre-approval validation, or any defined release gate. The labels make that policy easier to apply.

How Merito helps

Merito helps organizations turn these capabilities into an operating model rather than a feature checklist. We can support Worksoft migration assessment, automation portfolio rationalization, agent-capacity planning, AI-assisted test governance, and evidence standards for regulated or high-risk releases.

For 26.08.105, the immediate priority is to pilot Worksoft conversion with measurable acceptance criteria, establish review rules for AI-healed steps, and monitor timeout recovery as an indicator of execution-platform capacity.

Merito is an authorized Panaya reseller and services partner. Our Panaya Test Automation team can scope licensing, sizing, and rollout for 26.08.105, and our enterprise upgrade services help you plan and validate the upgrade with minimal disruption to release schedules.

About Panaya Test Automation

Panaya Test Automation licenses, renewals, upgrades and implementation are available through Merito, an authorized Panaya reseller and services partner.

Frequently Asked Questions