TestComplete
SmartBear's desktop, web, and mobile test automation. Script or record tests in JavaScript, Python, or VBScript.
Overview
TestComplete, created by SmartBear, is a commercial test automation platform for desktop, web, and mobile applications. It supports both script-based and keyword-driven testing, with record-and-playback capabilities for quick test creation. TestComplete can automate Windows desktop applications (WPF, WinForms, Delphi), web applications (all major browsers), and mobile apps (iOS/Android).
TestComplete is positioned as an affordable alternative to UFT One for teams that need desktop automation alongside web and mobile testing.
What it's used for
TestComplete is ideal when:
- Desktop application testing needed: Automate WPF, WinForms, Delphi, and Java desktop apps.
- Mixed technology stack: Test desktop, web, and mobile in one tool.
- Script flexibility needed: Write tests in JavaScript, Python, or VBScript.
- Record-and-playback preferred: Quick test creation without coding.
Pros & Cons
Pros
- Strong desktop application support (WPF, WinForms, Delphi)
- Multiple scripting languages (JavaScript, Python, VBScript)
- Record-and-playback for quick test creation
- Object recognition with AI-powered property matching
- More affordable than UFT One
Cons
- Commercial tool — licensing required
- Windows-only for test development
- Smaller community than open-source tools
- Record-and-playback tests require maintenance
- Less modern than Playwright or Selenium for web testing
Platforms & Integrations
TestComplete runs on Windows for test development. Tests can execute on Windows, macOS (web), and mobile devices.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| TestComplete Base | From $2,300/yr | Desktop and web testing, one scripting language |
| TestComplete Pro | From $3,450/yr | Desktop, web, and mobile testing, all scripting languages |
NZ Context
TestComplete is used by some NZ enterprises with legacy Windows desktop applications. It is less common than Selenium or Playwright for web testing. For NZ teams with desktop automation needs, TestComplete is a more affordable entry point than UFT One.
Alternatives
- UFT One — More powerful but more expensive enterprise desktop automation.
- Selenium — Free alternative for web testing. No desktop support.
- Playwright — Modern web automation. No desktop support.
When to choose TestComplete
A quick decision guide for NZ teams evaluating GUI test automation options.
| Choose TestComplete when… | Choose something else when… | Combine with… |
|---|---|---|
| Your team maintains legacy Windows desktop apps (WPF, WinForms, or Delphi) alongside a web front-end and must automate both in one tool and one CI pipeline. | You only need web or mobile testing — Playwright is faster, free, and has a far larger community. There is no reason to pay a licence fee for browser-only work. | Playwright or Cypress for all web-only regression; reserve TestComplete for the desktop surface alone to contain licence costs. |
| Your testers are non-programmers who need record-and-playback to build an initial suite quickly, with a plan to hand off to developers later for maintenance. | Your team already writes code fluently — the record-and-playback benefit disappears and you inherit brittle tests that are harder to maintain than hand-crafted Playwright scripts. | Azure DevOps or Jenkins for CI orchestration — TestComplete integrates natively with both and can publish results to SmartBear's TestRail for traceability. |
| You are replacing UFT One and need a like-for-like desktop automation capability at roughly one-third the price, with a migration path for existing keyword-driven tests. | Your organisation runs macOS or Linux developer machines — TestComplete test development is Windows-only, which creates friction in a mixed-OS environment. | Appium for mobile testing if your mobile surface is complex; TestComplete's mobile support is functional but Appium has a richer ecosystem and community. |
| Your application uses a proprietary or in-house UI framework (e.g. a Delphi-based ERP built internally) that open-source tools cannot inspect — TestComplete's object recognition engine handles these surfaces well. | You need a strong open-source community, extensive plugin ecosystem, or free training resources — Selenium and Playwright win here by a wide margin. | TestRail or Xray for test management so recorded tests map back to requirements, giving stakeholders traceability without manual effort. |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I joined the QA team at TechServNZ supporting a client with a WinForms fleet management system and a React web portal, and the team had zero test automation in place.
I would…
License TestComplete Base for the desktop surface only, use it to automate the ten highest-risk WinForms workflows (order dispatch, driver scheduling, invoice generation), and run Playwright in parallel for all web regression. I would not use TestComplete for the web portal at all — that would be paying for a feature Playwright does better for free. The hybrid split is unusual but cost-effective: two tool chains, one CI pipeline, clear ownership boundaries.
If…
I was leading test automation at Revenue NZ during a migration from an aging Delphi-based assessment system to a modern web interface, with a three-year parallel-run period where both needed regression coverage.
I would…
Start with TestComplete Pro for the Delphi surface — it is one of the few tools that can actually inspect Delphi component hierarchies reliably. I would invest heavily in keyword-driven tests that non-technical business analysts can run and maintain, because Revenue NZ has deep domain expertise outside the IT team. When the Delphi system is decommissioned, I would not renew the TestComplete licence — I would migrate the regression suite entirely to Playwright. I would make that exit strategy explicit in the procurement decision so leadership understands the licence is finite by design, not permanent overhead.
If…
I was a QA lead at Foodstuffs NZ evaluating test automation for their in-store point-of-sale (POS) system — a thick-client Windows application — and the team had previously tried Selenium and failed because it could not interact with the POS UI controls.
I would…
Run a two-week proof of concept with TestComplete targeting the five most common cashier flows (sale, refund, void, loyalty scan, end-of-day). If the object recognition engine can identify the POS controls reliably — which it usually can for Windows desktop apps — I would proceed with a licence. I would not rely on record-and-playback beyond the PoC; those scripts are brittle under POS firmware updates. Instead I would write structured JavaScript tests from day one using TestComplete's scripting layer, treating the recording only as a starting template. If the PoC fails, the next honest option is WinAppDriver or a custom accessibility hook — not another browser automation tool.
The bottom line: TestComplete earns its licence fee precisely when open-source tools cannot reach your UI — desktop apps, proprietary frameworks, legacy Windows surfaces. Outside that scenario, it is an expensive substitute for tools that are free and better-maintained. Know the exit before you sign the contract.
Interview questions
Questions you are likely to get if you list TestComplete on your CV — with what interviewers are really testing for.
What is the difference between keyword-driven and script-based testing in TestComplete, and when would you choose one over the other?
What they’re really testing: Whether you understand TestComplete’s two core paradigms and can make a pragmatic trade-off between accessibility and maintainability.
Strong answer covers: Keyword-driven lets non-programmers build and run tests without code (good for business analysts at Revenue NZ or Benefits NZ maintaining their own suites); script-based (JavaScript or Python) gives full control, is far easier to refactor, and survives UI churn better; most mature teams combine both — keyword-driven for smoke suites, scripted for complex workflows.
When would you choose TestComplete over Playwright for automating a NZ enterprise application?
What they’re really testing: Whether you know TestComplete’s genuine strengths or are cargo-culting a tool choice from a previous employer.
Strong answer covers: TestComplete is the right call when the application has a desktop surface (WPF, WinForms, Delphi, Java Swing) that browser automation cannot reach; Playwright wins for all pure web work and is free with a larger community; a hybrid setup — TestComplete for the desktop layer, Playwright for the web portal — is common at NZ enterprises like TechServNZ running mixed legacy and modern stacks.
You’re joining the QA team at CloudBooks NZ to automate regression on an internal Windows desktop tool used by the finance team alongside the main CloudBooks web product. How would you approach the automation strategy?
What they’re really testing: Whether you can scope a tool pragmatically rather than applying it everywhere, and whether you think about CI integration from the start.
Strong answer covers: Scope TestComplete only to the desktop tool (not the CloudBooks web product, which should use Playwright or Cypress); identify the top-risk workflows first with the finance team before writing a single test; wire both suites into the same CI pipeline (Azure DevOps or GitHub Actions) so results land in one report; plan the licence exit early — if the desktop tool is replaced with a web UI, TestComplete does not follow.
Your TestComplete scripts pass on your Windows dev machine but fail intermittently on the CI agent. How do you investigate?
What they’re really testing: Whether you can systematically eliminate environment differences rather than just re-running tests and hoping.
Strong answer covers: Check the TestComplete execution log on the CI agent for the exact failure line and object-not-found details; compare screen resolution and DPI settings between dev and CI (object recognition is sensitive to these); look for timing issues — add explicit waits rather than fixed delays; verify the CI agent is running as an interactive session with a visible desktop, not a headless service account (TestComplete requires a real Windows session); confirm all application dependencies and fonts match.
How would you structure a TestComplete project to support a team of five QA engineers working across three desktop applications without stepping on each other’s tests?
What they’re really testing: Whether you understand TestComplete project organisation and have thought about source control discipline for a shared codebase.
Strong answer covers: Use separate TestComplete projects per application inside one Project Suite so they share common libraries (name maps, utility scripts, test data helpers) without coupling test logic; store everything in Git with a clear branching strategy so engineers don’t overwrite each other’s name map entries; centralise environment configuration (base URLs, credentials) in a single settings module rather than hardcoding; tag tests by application and priority so CI can run targeted subsets without executing the whole suite every push.