UFT One
Micro Focus's enterprise automation platform for desktop, web, mobile, and API testing. The legacy standard for enterprise QA.
Overview
UFT One (Unified Functional Testing), formerly HP QuickTest Professional (QTP), is an enterprise test automation platform owned by OpenText (formerly Micro Focus). It supports desktop, web, mobile, and API testing with a keyword-driven and script-based (VBScript) approach. UFT One is particularly strong for legacy enterprise applications — SAP, Oracle, Siebel, and mainframe terminals.
UFT One is the most expensive and comprehensive test automation tool on the market. It is typically found in large enterprises with long histories of Micro Focus tooling and complex application portfolios.
What it's used for
UFT One is the right choice when:
- Legacy enterprise applications: SAP, Oracle, Siebel, and mainframe automation.
- Multi-technology testing: Desktop, web, mobile, and API in one platform.
- Enterprise governance required: Professional support, compliance, and audit trails.
- Existing Micro Focus ecosystem: Integration with ALM Octane and LoadRunner.
Pros & Cons
Pros
- Broadest technology support of any automation tool
- Strong legacy application support (SAP, Oracle, mainframe)
- Professional support and enterprise SLAs
- Keyword-driven tests accessible to non-programmers
- Integration with ALM Octane for test management
Cons
- Extremely expensive — enterprise licensing only
- Windows-only for test development
- VBScript is outdated compared to modern languages
- Heavy resource requirements
- Smaller talent pool — fewer professionals know UFT than Selenium
Platforms & Integrations
UFT One runs on Windows. It supports web browsers, Windows desktop apps, mobile devices, and terminal emulators.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Enterprise | Custom | All modules, professional services, dedicated support |
NZ Context
UFT One is used by a small number of large NZ enterprises with legacy systems and existing Micro Focus contracts. It is rarely seen in NZ startups or modern SaaS companies. For NZ professionals, UFT One skills are valuable but niche — opportunities are limited to large enterprises with significant automation budgets.
Alternatives
- TestComplete — More affordable alternative with similar desktop/web/mobile coverage.
- Tosca — Modern enterprise alternative with model-based testing.
- Selenium + other tools — Free stack for web testing. Requires assembly.
When to choose UFT One
A quick decision guide for NZ teams evaluating enterprise GUI test automation options.
| Choose UFT One when… | Choose something else when… | Combine with… |
|---|---|---|
| You are already deep in the OpenText/Micro Focus ecosystem — ALM Octane for test management, LoadRunner for performance, and you need a single vendor support contract. | Your application portfolio is modern web or API-first. Playwright, Cypress, or RestAssured will outperform UFT One at a fraction of the cost and with a much deeper talent pool. | ALM Octane for test planning and defect traceability, and LoadRunner for performance testing if you need an end-to-end OpenText quality suite. |
| Your core application is a legacy SAP, Oracle, or Siebel system with no REST API surface to drive automation through a lower layer. | Your team writes Python, Java, or TypeScript day-to-day. Forcing VBScript on modern developers causes attrition and slow test authoring. Consider Tosca or TestComplete instead. | SoapUI/ReadyAPI (also OpenText) for API and service testing that sits alongside UFT One's GUI layer in a hybrid pipeline. |
| Regulatory or audit requirements demand a commercially supported, enterprise-licensed tool with documented chain of custody — common in NZ financial services and government procurement frameworks. | You are building a greenfield CI/CD pipeline. UFT One's Windows-only runtime and per-seat licensing model does not fit modern container-based build infrastructure without significant workarounds. | Azure DevOps or Jenkins for pipeline orchestration — UFT One has mature plugins for both, letting you trigger test runs as a pipeline stage without abandoning your CI tooling. |
| Your QA team includes non-programmers who need to author and maintain tests. The keyword-driven framework lowers the barrier to entry compared to code-first tools. | Hiring is a concern. UFT One skills are rare in the NZ market — recruiting for VBScript-fluent automation engineers is significantly harder than recruiting for Selenium, Playwright, or Cypress practitioners. | Zephyr Scale or Xray (Jira-native) for test case management if your team prefers Jira over ALM Octane for day-to-day test tracking. |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I were the QA lead at Revenue NZ inheriting a UFT One suite that has been running for eight years against their PAYE and GST processing screens — screens that have not fundamentally changed and have no REST API — I would not rip it out.
I would…
Preserve the existing UFT One suite for those legacy screens, freeze new test authoring in VBScript, and ring-fence a separate Playwright project for any new web-facing functionality. Run both pipelines in Azure DevOps. Budget the UFT One licence renewal as a known cost of maintaining a legacy system — not as a QA investment.
If…
I were a test manager at CoverNZ being asked to evaluate UFT One for a new injury claims portal built on a modern React frontend with a documented REST API — replacing their existing manual regression suite.
I would…
Decline UFT One and propose a two-layer strategy: Playwright for end-to-end browser tests (TypeScript, runs headless in CI), and RestAssured or Postman/Newman for API contract tests. The total cost is near zero, the talent pool in Wellington and Auckland is far deeper, and the pipeline integrates cleanly with whatever CI tooling CoverNZ already runs. UFT One's GUI strength is irrelevant when the better testing surface is the API.
If…
I were an automation engineer at Harbour Bank where UFT One is the mandated enterprise standard and I have no authority to change it — but I am drowning in slow, brittle VBScript suites that fail on the slightest UI tweak.
I would…
Work within the tool rather than against policy. Refactor the existing scripts to use a proper Page Object pattern in VBScript — UFT One supports it, most legacy suites simply never adopted it. Centralise all object locators in a shared function library so a UI change means one edit, not fifty. That stabilises the suite without requiring a toolchain change, and builds the business case for migration data over time.
The bottom line: UFT One is a maintenance cost, not a competitive advantage. Preserve it where it is genuinely irreplaceable — legacy GUI applications with no API — and do not extend it to modern systems where open-source tools outperform it at a fraction of the licence fee.
Interview questions
Questions you are likely to get if you list UFT One on your CV — with what interviewers are really testing for.
Why would you choose UFT One over Playwright for a large enterprise project, and when would that decision be wrong?
What they’re really testing: Whether you understand UFT One’s genuine strengths or just listed it on your CV because a previous employer used it.
Strong answer covers: UFT One’s unique value for legacy GUI automation (SAP, Oracle, Siebel, mainframe terminals) where no REST API surface exists; the decision being wrong when the application is modern web or API-first; and the NZ context that most large government and financial-services organisations that still run UFT One do so because of existing OpenText contracts and audit requirements, not because it is the best tool for the job.
What is the difference between UFT One’s keyword-driven framework and a VBScript-based scripted approach, and which would you recommend for a team where half the testers are not programmers?
What they’re really testing: Practical knowledge of how UFT One is actually used day-to-day, and your judgment about team capability vs. tool feature selection.
Strong answer covers: Keyword-driven lets non-programmers assemble tests from pre-built action words without writing VBScript; scripted mode gives full control but requires developer-level skill; and a hybrid approach — keyword framework for business-readable test cases, shared VBScript function libraries for complex reusable logic — is the standard pattern in mature NZ enterprise UFT One setups.
You’re joining Revenue NZ as a senior automation engineer. They have a UFT One suite of 400 tests covering PAYE processing screens that has been running for six years. The suite is slow, brittle, and failing on minor UI changes. How do you stabilise it without a full rewrite?
What they’re really testing: Whether you can add value in a constrained legacy environment without defaulting immediately to “we should migrate to Playwright.”
Strong answer covers: Auditing the Object Repository to remove stale and duplicate objects; refactoring to a Page Object-style function library so locator changes are made in one place; switching brittle property-based object recognition to descriptive programming for unstable elements; and setting a test runtime baseline in ALM Octane so you can measure improvement — all without touching the business logic of the tests.
Your UFT One tests pass on the test engineer’s Windows laptop but fail consistently in the Azure DevOps CI pipeline. The error is “Object not found” on a web element that is clearly visible in screenshots. What do you investigate first?
What they’re really testing: Debugging depth in a Windows-only, GUI-driven CI environment — a genuinely hard problem that separates experienced UFT One engineers from people who only ran tests manually.
Strong answer covers: Screen resolution and DPI differences between local machine and the CI agent (UFT One’s image-based recognition breaks at different display scales); whether the CI agent has an interactive desktop session or is running in a non-interactive Windows Service context (UFT One requires an active desktop); browser version mismatch between environments; and synchronisation issues where the CI machine is faster and elements haven’t fully rendered before UFT One attempts to interact with them.
How would you structure a UFT One automation framework to scale across a team of eight engineers testing a multi-module enterprise system — covering both a legacy desktop ERP and a new web portal?
What they’re really testing: Architecture thinking — can you design a maintainable framework, not just write individual tests.
Strong answer covers: Separate Action libraries per application module stored in a shared network location or ALM Octane Assets; a centralised Object Repository split per application (desktop ERP and web portal as separate repos to avoid conflicts); a shared VBScript utility library for cross-cutting concerns (logging, screenshot capture on failure, environment config); and test data management kept out of the scripts — driven from Excel or a database — so data changes don’t trigger script changes.