Tosca Interview Questions for 2025

Tosca is a popular continuous testing platform developed by Tricentis. It accelerates testing with a no-code approach and scriptless end-to-end automation. This tool is used for both functional and regression testing. In addition to its automation functions, it also supports a graphical user interface, application programming interface, and command-line interface. 

It helps you to:

• Deliver fast feedback for DevOps and Agile
• Decrease regression testing time
• Maximizes maintainability and reusability
• Integrates and extends existing test assets
• AI-powered test generation
• Predictive Analytics and AI capabilities.

The major components available in Tosca are:

• Tosca Commander.
• Tosca Executor.
• Tosca XScan (Tosca Wizard)
• Test Repository
• Tosca Analytics Engine
• Tosca Cloud Execution Module
• Tosca Application Intelligence Platform.

Tosca API Scan helps you to create TestCases for Tosca Orchestrated Service Virtualization or Web Services.  We can scan API definitions, validate messages, and save them in TestCases.

TQL stands for Tosca Query Language, a powerful search method that allows you to take control of the project at any time. The TQL search is context-dependent.

It is used for various functions and expressions within Tricentis Tosca.

Tosca Jira integration improves the quality and traceability of software products. Some of the benefits of this integration are:

• Synchronizes failed tests from Tosca
• Automatically reports defects.
• Supports cross-tool traceability
• Two-way sync configurations
• Advanced filtering and automation rules.

Tosca continuous integration triggers automated Tosca Test Cases without user input. It helps to reduce testing time for continuous integration and delivery.

Tosca CI can be implemented in either of the below-mentioned ways:

• Run the test execution via Remote Service through a separate execution workspace.
• Use Tosca Continuous Integration together with Tosca Distributed Execution.
• GitHub Actions integration
• GitLab CI integration
• Jenkins advanced configurations
• Container-based execution
• Parallel execution strategies
• Cloud execution endpoints.

Tosca defines test cases by scanning the applications. The automation model includes logic to decouple the test logic as specified in a test case. Once the required models are defined, they can be used to execute both automated and manual test cases with input & verification data.

The various ways to identify objects in the Tosca Testsuite

• Identify by properties
• Identify by Anchor
• Identify by image
• Identify by index
• AI-powered object identification
• Advanced XPath and CSS selector strategies
• Computer vision for UI element recognition.

Test configuration parameters help you configure your tests by setting values. They can also be used to configure Tosca objects.

You can create test configuration parameters for the following Tricentis Tosca objects: 

• Project root element
• ExecutionList
• Component folder
• ExecutionEntry folder
• Configurations folder
• ExecutionEntry
• TestCase folder
• ScratchBook
• TestCase
• TestCase-Design folder
• ExecutionList folder.

String operations are used to verify or modify strings using regular expressions. They include counting specific characters/words in a statement, replacing a word with another word, verifying the format of a number, etc. You should have the AidPack module downloaded and imported into your project to perform String operations.

Exploratory testing is a process of designing and executing tests, and interpreting test results all at one time. It is a plan-as-you-test approach. The purpose of this testing is to explore the unknown to avoid unexpected results.

To keep track of the requirements, we link the test cases in Tosca. This lets us know how many requirements are covered, how many more are needed, and also check how many requirements the test cases pass successfully. This helps us get a high-level picture of requirement coverage.

Vision AI “looks” at the screen the way a person does. It doesn’t try to use the element’s ID, class name or DOM attributes. Instead, it identifies the element from the visual presentation, including the element context of the screen.

When to use it:

• Non-standard or custom controls that lack stable technical properties (embedded graphical elements, proprietary legacy systems)
• Virtual/Remote Desktops (VDI) like Citrix or RDP where underlying DOM properties are inaccessible
• Image-based elements that have no descriptive technical attributes whatsoever
• Rapid prototyping when the application is changing constantly, and technical IDs are not stable yet.

Do not default to Vision AI for everything. It is slower and less precise than property-based identification. Use it when traditional scanning genuinely fails, not as a shortcut.

MBT is an approach to testing where test cases are generated or executed from a model of the system under test. This model resides in the Modules section of Tosca.

• Model Creation happens through scanning. Technical details (element IDs, names, properties) are captured and stored in the Module.
• Test Case Creation references the logical controls from the Module, never the technical properties directly.

The benefit is separation of concerns. If the UI changes and an element's ID is updated, you fix it in the Module once. Every test case that uses that Module continues working without any changes to the test logic itself. This is the core architectural principle behind Tosca and the reason it scales to large enterprise projects.

A Unique Application Identifier is a stable key characteristic that Tosca uses to uniquely identify an entire application window or process before it begins interacting with its controls.

Modules have several default properties themselves, which are mainly for documentation, management, and identification: 

• Name: The user-defined, unique name of the Module (e.g., M_LoginScreen)
• UniqueId: The internal, unique identifier generated by Tosca.
• Path: The location of the Module within the Commander tree
• Description: A field for documenting the Module's purpose
• URL/Application Identifier: The identifying property (e.g., the browser title or desktop application caption) that Tosca uses to launch or attach to the application.

To enable it, open the Tosca Commander and go to Project → Settings → Engine.

Look for the Dokusnapper settings. Choose the mode you'd like for captures: capture on each step, capture on failure only, or capture on specified test steps. Once activated, Dokusnapper will automatically take screenshots while running and append them to the execution log.

You can also enable it at the test case level by adding Dokusnapper-specific configuration parameters directly to the test case or execution list.

Business parameters are placeholders inside your test steps that get their values from the calling test case. You define the parameter in the reusable component (like an RTB), and the test case that calls it provides the actual value.

This means you write the test logic once and reuse it across dozens of test cases, each with different data. Without business parameters, you would need separate test steps for every data variation, which defeats the entire purpose of reusability. They are the mechanism that makes Tosca's template and library architecture work.

If you are only running tests, the mandate can stay checked in. Other users can execute from the same mandate simultaneously. Nonetheless, in the event you’re seeking to amend your mandate’s structure, or include and exclude test instances, you must checkout the mandated test system prior to this change.

Multiple users cannot make conflicting changes independently, therefore, to support concurrency, Tosca checks in and checks out a test object.

DPI captures how users actually work with an application in production. It records click paths, navigation patterns, and transaction flows from real usage data. Tosca will use this information to identify which processes are most used, where bottlenecks or deviations occur, and which processes most urgently need testing.

The powerful part is that DPI can feed directly into test case creation. Instead of a tester guessing which scenarios to automate, DPI tells you "these are the 20 most common paths your users actually take." You automate those first and know you are covering what matters most.

The recommended order of preference:

• Unique IDs like Id or Name if they are stable and do not change between sessions
• Technical Properties like TagName and ClassName, often combined with unique text for disambiguation
• Visible/Structural Properties like InnerText, Value, Title. Excellent for human readability and stability
• Descriptive Properties with Regex for dynamic values. Use regular expressions on the stable portion (e.g., InnerHtml containing a known text snippet)
• Anchor/Index as a last resort to resolve non-uniqueness when nothing else works.

Fire Event is a specialized ActionMode used with the XBrowser Engine. It specifically forces a JavaScript event (onchange, onclick, onblur, or onfocus) to happen on the element. 

You would use it when a "normal" Tosca action (e.g., "Input", "Click") doesn't seem to invoke the "client side" behavior that the application expects. For example, a text field has a JavaScript onchange event that triggers validation.

Simply using the Input ActionMode populates the value but does not fire onchange. Adding a Fire Event step with the value onchange after the Input explicitly triggers the event, and the validation runs as expected.

It is a Test Case that acts as a blueprint, containing the abstracted test logic with placeholders called Business Parameters (e.g., {Username}).

Creating Template Instance:

• Create the Test Case and insert the required Test Steps, replacing values with Business Parameters (e.g., Input: {Name}). 
• Right-click the Test Case $\rightarrow$ and convert to Template. 
• Drag the relevant Test Case Design sheet onto the Test Case Template. 
• Right-click the Template $\rightarrow$ Instantiate. This creates the Template Instances (Test Cases) in the designated folder.

Use them when a sequence of steps appears in more than one test case. Login flow, navigation to a specific page, filling a common form. Instead of duplicating those steps everywhere, you wrap them in a TestStep Block and reference it.

The practical benefit is maintenance. If the login screen adds a new field, you update the block once. Every test case that references it picks up the change. Without blocks, you would be hunting down and editing the same steps in dozens of test cases manually.

Conditions in an RTB are used to skip the execution of the entire RTB based on the value of one of its Business Parameters in the calling Test Case. 

• Open the RTB in the Test Step Library. 
• In the Properties section of the RTB, define the Condition using the RTB's  Business Parameters. 

If the RTB is for entering an optional field, and you only want to run it if the field value is not empty:

$$Condition: {OptionalField} != ""$$ 

If the Test Step that calls the RTB provides an empty value for {OptionalField}, the entire RTB is skipped during execution.

To Create Buffers:

Buffers are created in two ways within a Test Step: 

1. ActionMode: Buffer: On a UI control, set the ActionMode to Buffer and the value to the desired buffer name (e.g., OrderID).
2. Set Buffer Module: Using the TBox Set Buffer module from the TBox Standard Modules.

To View and Manage Buffers:

Buffers are managed in the Settings dialog of Tosca Commander: 

• Go to the Project menu $\rightarrow$ Settings. 
• Navigate to Engine $\rightarrow$ Buffers. 
• You can see the list of all global buffers. You can manually view, create, modify, or delete them.