GitHub Actions now has a ready-made action for running FT tests, giving release owners a supported way to place functional execution inside GitHub workflows.
That addition matters because functional test execution is often managed outside the delivery pipeline, leaving unclear ownership for failures, results, and release gates. FT 26.3 also brings supported Python authoring, AI-assisted verification, broader application coverage, and operational improvements across Jenkins and Azure DevOps.
Put functional tests in the delivery workflow
The new GitHub Action allows teams to invoke FT tests from GitHub workflows. This enables a more consistent pattern for associating a build, test execution, result, and deployment decision in one delivery record.
For release governance, teams should define:
- Which workflows require functional-test gates
- Which repositories and branches may invoke shared test assets
- How credentials and test-environment access are controlled
- Where run evidence is retained for audit and incident review
- Who owns failures caused by environments versus application changes
Azure DevOps users gain the ability to run tests as a specific Windows user. This can matter where desktop applications, profile-specific settings, certificates, or access policies affect test behavior. The extension can also specify a workspace when connecting to a Functional Testing Lab server with multiple workspaces. Its resource task can retrieve workspace information alongside device and application information.
Jenkins teams can now order ALM test sets by name or ID and send run-result summary emails to specified recipients. Ordering by ID can reduce ambiguity when names are duplicated or naming standards have changed over time. Configurable notifications provide a direct route for putting execution outcomes in the hands of release stakeholders.
Move Python from pilot use to a managed standard
Python scripting, previously available as a beta capability, is officially supported in FT 26.3. New tests can be created as Python or VBScript tests, allowing organizations to introduce Python without forcing a wholesale rewrite of existing automation.
This is a portfolio-management change, not only a language choice. Teams should set standards for when Python is the preferred option, how common libraries are versioned, and how reviewers assess test code across both languages.
Implementation requires the FT Python Engine feature in the installation program and a supported 32-bit Python installation on the machine. Organizations that installed the standalone Python Engine from version 26.1 must remove it before installing 26.3.
A practical rollout plan includes:
- Baseline runner images and Python versions
- Create approved dependency and package-management rules
- Keep reusable test libraries under source control
- Define code-review criteria for Python and VBScript tests
- Test recovery scenarios, which now support Python
.prsfiles
The Automation Object Model now supports an optional Language parameter in Application.New, allowing automated creation of Python tests. That is relevant for teams that provision tests or frameworks programmatically.
Govern AI-assisted verification before scaling it
Smart Verify checkpoints introduce a generative AI method for describing image or property checks in plain language. UFT Aviator interprets the description using the organization's own large language model, reducing the need to write detailed verification logic for some test scenarios.
The capability requires a valid UFT Aviator license. It should be assessed as a controlled test-authoring capability, especially where application screens, object properties, or prompts may carry sensitive business context.
The Automation Object Model includes an LLM property in the Options object so teams can configure the Aviator connection programmatically. That supports repeatable setup, but it also means the connection configuration deserves the same change control as other pipeline integrations.
Recommended governance controls include:
- Approve LLM providers, models, and connection configurations
- Restrict who can change AI connection settings
- Review Smart Verify statements for critical release controls
- Record test artifacts and results used as release evidence
- Define fallback checks for high-risk or regulated workflows
Smart Verify can speed test design, but it does not remove the need to validate whether a checkpoint represents the intended business control. Test owners still owns that decision.
Extend coverage for enterprise platforms and operations
FT 26.3 formally supports testing Windows Forms applications based on .NET 5 and later. The support includes additional object types such as SwfPropertyGrid, SwfToolBar, SwfTable, and SwfStatusBar, access to native properties, a NetFactory Utility object, and .NET extensibility.
For application owners modernizing desktop estates, this moves an earlier technical-preview capability into supported coverage. Teams can now plan regression protection for .NET Windows Forms changes with clearer vendor support expectations.
PeopleSoft teams receive the PS-FLUID Add-in for testing PeopleSoft 9.2 and later in Microsoft Edge. It supports Fluid UI controls that were previously limited to IE mode. This can support browser-modernization programs while retaining automation coverage for critical HR, finance, and operational workflows.
API testing gains SSH activities for remote server administration through command execution and file or directory management. These activities make it possible to include controlled operational setup, validation, and cleanup steps within API-focused tests. Teams should apply least-privilege SSH accounts, rotate credentials, and maintain command allowlists where production-like systems are involved.
Improve result handling and secure data entry
The Test Batch Runner can now export API test results to PDF automatically. This is useful where release processes require a standardized report artifact, although teams should establish retention periods and access controls because result files can expose environment details or test data.
For Oracle testing, OracleTextField.SetSecure can send an encoded string to an edit field. This supports safer handling of sensitive input values in test logic, but encoded data remains subject to broader secret-management rules. Avoid placing credentials or sensitive values directly in repositories, logs, and exported reports.
What release leaders should do next
Prioritize adoption based on delivery bottlenecks and risk rather than enabling every capability at once.
- Pilot the GitHub Action or updated Azure DevOps tasks on one representative pipeline.
- Validate runner identity, environment permissions, and Functional Testing Lab workspace selection.
- Standardize the Python runtime and remove legacy standalone Python Engine installations.
- Evaluate Smart Verify with approved LLM connectivity and test evidence controls.
- Target .NET, PeopleSoft, or SSH enhancements where coverage gaps affect release confidence.
- Update run-report retention and notification rules for the new PDF and Jenkins options.
How Merito helps
Merito helps enterprise teams operationalize FT 26.3 without creating unmanaged variations across teams. We assess automation portfolios, define Python and AI governance standards, integrate functional tests into GitHub Actions, Jenkins, and Azure DevOps, and establish evidence, access, and reporting controls aligned to release risk.
The goal is a test operating model that gives delivery leaders clear accountability while allowing engineering teams to adopt the new capabilities at a measured pace.
Merito is an authorized OpenText reseller and services partner. Our OpenText FT team can scope licensing, sizing, and rollout for 26.3, and our enterprise upgrade services help you plan and validate the upgrade with minimal disruption to release schedules.
