Tricentis Tosca
Enterprise model-based test automation. No-code approach for SAP, Salesforce, and large-scale ERP testing.
Overview
Tricentis Tosca is an enterprise-grade test automation platform built around a model-based testing (MBT) approach. Instead of writing scripts, testers create reusable business models that represent application functionality. When the UI changes, only the model needs updating — not every test case. Founded in 2007 and headquartered in Vienna, Tricentis is now one of the largest pure-play testing vendors globally.
Tosca is particularly dominant in SAP, Salesforce, and Oracle environments where traditional script-based tools struggle with complex enterprise UIs. In 2025-2026, Tricentis added Vision AI (self-healing via computer vision) and agentic testing capabilities.
What it's used for
Tosca is the right choice when:
- Testing SAP, Salesforce, or Oracle applications: Native connectors and pre-built modules accelerate automation for enterprise apps.
- Business users need to create tests: The model-based approach requires no programming knowledge.
- High maintenance overhead is a problem: Model updates propagate to all dependent tests automatically.
- Risk-based testing is required: Tosca can prioritise tests based on business risk and code change impact.
- Regulated industries: Full audit trails, electronic signatures, and compliance reporting for pharma, banking, and government.
Pros & Cons
Pros
- Model-based testing dramatically reduces maintenance vs. script-based tools
- Native SAP, Salesforce, and Oracle connectors
- No-code interface enables business analysts to create tests
- Risk-based test prioritisation with AI-powered optimisation
- Enterprise compliance: audit trails, e-signatures, role-based access
Cons
- Very expensive — enterprise licences typically start at $50K+ annually
- Steep learning curve for model-based concepts
- Heavy resource requirements — needs dedicated infrastructure
- Not suitable for small teams or greenfield web apps
- Vendor lock-in: proprietary format makes migration difficult
Platforms & Integrations
Tosca runs on Windows (primary) with limited macOS/Linux support for execution agents. It supports web, desktop, SAP, Salesforce, Oracle, mainframe, and API testing.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Professional | Contact sales | Core automation, web and desktop testing |
| Enterprise | $50K-$200K+/yr | SAP/Salesforce connectors, risk-based testing, unlimited users, dedicated support |
NZ Context
Tosca is used by large NZ enterprises with complex ERP landscapes, particularly in government and banking. The NZ Ministry of Business, Innovation and Employment (MBIE) and several Crown Entities have evaluated Tosca for SAP testing. However, Tosca is rarely seen in NZ startups or SaaS companies due to cost and complexity. For NZ job seekers, Tosca skills command premium salaries but the job pool is smaller than Playwright or Selenium.
Alternatives
- Katalon — Lower-cost low-code alternative with broader web/mobile support.
- UiPath Test Suite — RPA-focused with strong enterprise app coverage.
- Playwright — Code-based alternative for modern web apps. Much faster and cheaper.
When to choose Tosca
A quick decision guide for NZ teams evaluating enterprise test automation options.
| Choose Tosca when… | Choose something else when… | Combine with… |
|---|---|---|
| Your organisation runs SAP S/4HANA, Salesforce, or Oracle EBS and maintains 500+ test cases | Your stack is a modern React/Vue SPA — Playwright or Cypress will cost a fraction and move three times as fast | Postman or REST Assured for API-layer tests that Tosca's UI coverage intentionally skips |
| Business analysts — not developers — must own and maintain the test suite | Your team is fewer than five testers; the infrastructure overhead and licence cost will dominate your budget | Jira + Xray for requirements traceability so Tosca test results map to user stories in your backlog |
| You operate in a regulated industry (banking, government, healthcare) and need signed audit trails and role-based access built into the toolchain | Continuous delivery pipelines are critical — Tosca's Windows-only execution agent and licence server add pipeline friction that open-source tools don't | Azure DevOps or Jenkins for CI/CD orchestration; Tosca's built-in CI connectors make this straightforward once infrastructure is in place |
| Risk-based test optimisation matters — you need data-driven evidence for which test cases to run before each release, not gut feel | You're evaluating because a vendor demo impressed leadership — run a two-sprint proof of concept on your actual applications before signing an enterprise contract | Tricentis NeoLoad or k6 for performance validation; Tosca covers functional coverage but has no load-testing capability |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
If…
I were on the QA team at Revenue NZ — a large government agency running SAP for core tax processing — and we were inheriting 800 manual regression scripts that a retiring contractor wrote in spreadsheets
I would…
Pilot Tosca on the 50 highest-risk SAP Finance test cases first — not the whole suite. The model-based approach genuinely shines when the underlying ERP business logic is stable and only the UI changes between upgrades. I would insist on a dedicated Tosca administrator role before going live; trying to run it as a shared part-time responsibility is how teams end up with a tool no-one can maintain. I would also push Tricentis for a proof-of-concept licence on our actual SAP instance, not a training sandbox — if it can't handle our custom transaction variants in week one, that's a deal-breaker to surface early.
If…
I were a QA lead at Harbour Bank, where the core banking platform is a mix of legacy mainframe and a modern customer-facing web app, and leadership was comparing Tosca against UiPath Test Suite for end-to-end automation
I would…
Choose Tosca for the mainframe and back-office system testing where Tosca's terminal and API connectors give it a genuine edge, but I would run Playwright in parallel for the customer web app — and I would be explicit with leadership that this is not tool sprawl, it's choosing the right tool for each surface. The financial services compliance features in Tosca (e-signatures, audit logs, change history) are real differentiators in a regulated environment; make sure those requirements are written into the procurement criteria so the evaluation is comparing like for like. I would never sign a multi-year Tosca licence without a contractual right to download execution logs in open formats — vendor lock-in risk in banking is a board-level concern.
If…
I were joining TechServNZ as a test automation consultant, assigned to a government client who had already purchased Tosca licences two years ago but the team had stopped using it because maintenance felt too hard
I would…
Start by auditing whether the modules were built correctly — abandoned Tosca implementations almost always fail at the modularisation step, where someone recorded actions at the UI element level rather than building proper business-object modules. The fix is rebuilding the module library, not replacing the tool. I would run a one-day workshop with the team to re-establish model-based thinking, using their own application as the example. If after two sprints of proper practice the team still can't maintain the suite without me in the room, then and only then would I recommend migrating the most-run test cases to Playwright and treating the Tosca investment as a sunk cost. Throwing a licensed tool away because of poor initial implementation is a common and expensive mistake.
The bottom line: Tosca is genuinely excellent at what it does — but what it does is a narrow, expensive, enterprise-specific job. If you can articulate a business case in one sentence ("we have 600 SAP regression tests and no developer bandwidth to maintain them"), buy it. If you can't, you're probably solving a process problem with a tool budget.
Interview questions
Questions you are likely to get if you list Tosca on your CV — with what interviewers are really testing for.
What is the difference between model-based testing in Tosca and traditional script-based automation?
What they’re really testing: Whether you understand Tosca’s core paradigm or just learned to click through the UI without grasping why it exists.
Strong answer covers: How Tosca separates the business model (modules and test cases) from the technical bindings (technical parameters); why a UI change only requires updating the module once rather than editing dozens of scripts; and the trade-off that model creation takes longer upfront but pays back in regulated, long-lived enterprise environments.
When would you choose Tosca over Playwright for a new automation project?
What they’re really testing: Whether you can make a commercially sound tool recommendation or default to whatever you used last.
Strong answer covers: Tosca wins on SAP, Salesforce, or Oracle ERP where native connectors reduce setup from weeks to days; Playwright wins on modern single-page apps where Tosca’s licence cost and Windows-only agent are hard to justify; and the team capability factor — Tosca is defensible when BAs, not developers, must own the test suite long-term.
You’re joining Revenue NZ as a QA lead. They run SAP S/4HANA for core tax processing and have 700 manual regression scripts in spreadsheets. How would you approach automating those with Tosca?
What they’re really testing: Whether you know how to sequence a Tosca rollout without blowing up delivery timelines or burning the team out.
Strong answer covers: Piloting on the 50 highest-risk test cases first rather than attempting full migration; insisting on a dedicated Tosca administrator role before go-live rather than treating it as a shared part-time responsibility; and demanding a proof-of-concept licence on the actual Revenue NZ SAP instance — not a training sandbox — to surface custom transaction variant issues in week one rather than month six.
Your Tosca tests pass on your local execution agent but fail consistently in the CI pipeline on Azure DevOps. How do you investigate?
What they’re really testing: Whether you understand Tosca’s infrastructure dependencies and can diagnose environment-specific failures methodically.
Strong answer covers: Checking whether the CI agent has a valid Tosca licence server connection and that the DEX (Distributed Execution) agent version matches the Commander version; comparing screen resolution and DPI settings between local and CI machines, since Tosca’s image-based controls are resolution-sensitive; and reviewing the Tosca execution log for “control not found” vs “synchronisation timeout” errors to separate UI-anchor failures from application-latency issues.
How would you structure a Tosca module library for a large ERP programme where five separate teams are contributing test cases simultaneously?
What they’re really testing: Whether you understand Tosca governance and can prevent the common failure mode where every team builds duplicate modules and the library becomes unmaintainable.
Strong answer covers: Establishing a shared module library with a designated module owner per business domain (Finance, HR, Procurement) so no two teams build the same SAP transaction module independently; enforcing naming conventions and a mandatory peer-review step before any module is promoted to the shared workspace; and using Tosca’s multiuser repository (typically backed by SQL Server) with branch-based workspaces so teams can develop in parallel without overwriting each other’s work.