Tricentis Tosca review: what it is, pricing and setup

Tosca separates the technical description of an application from the tests that use it. XScan inspects a screen and saves its controls as a Module, with each control as a ModuleAttribute holding the properties Tosca uses to find it. TestCases never contain locators; they reference ModuleAttributes. A change to a button’s identification is therefore fixed in the Module and every TestCase that uses it follows. Engines, such as TBox for most UI technologies, the API Engine 3.0 and dedicated engines for SAP, Salesforce and PDF, decide how each kind of control is steered. Vision AI scanning, in Tosca Cloud, recognises controls visually where technical properties are missing.

A TestCase is a sequence of TestSteps, each pointing at a Module, with a value and an ActionMode per attribute. Input and Insert enter data; Verify checks it; Buffer stores a value for later steps; WaitOn waits for a control to reach a state; Select and Constraint pick a control or a table row by its content. Values can be literal or dynamic expressions: {B[name]} reads a buffer, {CP[name]} a test configuration parameter, {XL[path]} test sheet data in a template, and {CLICK} clicks a control. Reusable TestStep Blocks group common sequences, such as signing in, so they are maintained in one place.

TestCase-Design separates test data from test logic. A test sheet models the data dimensions of a process, such as customer type, payment method and delivery country, as attributes with instances. A TestCase marked as a template references that data with {XL[...]} expressions, and creating a TemplateInstance generates one concrete TestCase per combination you choose. Regeneration rebuilds the instances from the template, and Tosca marks any generated TestCase that was edited by hand with a ChangedManually property, which is the signal that someone fixed the wrong object. Requirements, weighted by damage and frequency classes, then show which risks the generated cases cover.

In Tosca Commander, multi-user workspaces sit on a common repository in a shared database. Objects are read-only until checked out, other users cannot change what you hold, and Update all pulls in everyone else’s check-ins. ExecutionLists run TestCases locally, and distributed execution sends them through Tosca Server to agents on Windows machines. Tosca Cloud moves authoring into the browser and execution into playlists, run on personal, team or cloud agents, with a REST API for CI. Licences in both models float: a machine takes one from the pool while a Tosca component runs and returns it when finished.

Structure the workspace by business process and application, with Modules in a separate area grouped by application and screen, and Reusable TestStep Blocks in a library that TestCases reference rather than copy. Name everything predictably, because search is how people find existing assets. In multi-user workspaces, check out only what you are changing, check in small sets often, and run Update all at the start of each session; long-held check-outs block colleagues and make conflicts more likely. Appoint an owner for the Module area who reviews new Modules for duplicates, and use subset exports, which 2026.1 can restrict by permission, to move assets between workspaces deliberately.

For any process with several data combinations, design it once as a template. Model the data in a test sheet with attributes for each dimension, mark the TestCase as a template, and replace literal values with {XL[...]} references, using dots for nested attributes. Create a TemplateInstance to generate one TestCase per instance, then add instances rather than copying TestCases. Never fix a generated TestCase by hand: change the template and regenerate. Keep environment-specific values, such as client numbers, URLs and users, in test configuration parameters read with {CP[...]}, so the same TestCases run in test, pre-production and other environments by changing the configuration, not the steps.

Tosca Cloud exposes playlist runs through a REST API, and Tricentis documents the sequence for Jenkins: request an OAuth token with client credentials and the tta scope, start a playlist run, poll its state until it is Succeeded, Failed or Canceled, then download the results as JUnit XML. The same calls work from any CI system. Run on a Tosca Cloud or team agent by setting private to false, keep the client secret in CI secrets, and publish the JUnit file so results appear beside the build. The Tosca CLI, toscactl, offers playlist runs from a terminal too, but on the review date it was limited to the Tricentis Labs programme.

With Tosca Commander, ExecutionLists go to distributed execution: Tosca Server queues the work and agents on Windows machines run it, each taking a licence from the pool. UI tests on those agents need an interactive desktop, so agents run in RDP sessions, and 2026.1 added a key vault timeout for RDP credentials and an option to confirm RDP login messages automatically. In Tosca Cloud the same role is played by personal agents, team agents that can start automatically on Windows, and cloud agents that Tricentis provisions, which since June 2026 can reach private applications through an allowlist rule. In our experience the agent pool, not authoring, sets the pace of a regression cycle, so size it against the licence pool deliberately.

Most flaky Tosca runs come from timing and unexpected dialogs. Use WaitOn to wait for a control to reach a state before acting, rather than fixed waits, and adjust synchronisation settings for slow systems instead of inserting delays. Define recovery scenarios for pop-ups that may appear and cleanup scenarios that return the application to a known state, so one failure does not cascade through an ExecutionList. Buffer generated values, such as order numbers, and verify them later instead of hard-coding expectations. Keep ExecutionLists aligned to requirements, so a failed run maps directly to the business risk it affects.