Tosca Interview Questions

Tosca is a popular continuous testing platform developed by Tricentis. It is a AI-powered, scriptless, model-based test automation and 
software quality assurance platform.

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 supports a graphical user interface, an application programming interface, and a 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. 

Choose automation when the test needs to run across different releases and the tests repeatedly deal with large datasets that will take forever. The test is run for regression testing and must be performed after every sprint. You need cross-browser and cross-platform tests.

For selecting test cases, follow this priority:

• High frequency tests that run every release are the first candidates
• Stable functionality where the feature is unlikely to change drastically in the near term
• Data-driven scenarios where the same flow runs with hundreds of input combinations
• Smoke and sanity tests that validate critical paths after every deployment.

Avoid automating tests that are still in flux, one-time validations, or purely exploratory scenarios where human judgment is the point.

Recovery scenarios occur when things go wrong during test execution. The screen is interrupted by an unforeseen pop-up window, the browser crashes, or the screen takes longer to display. By creating Recovery Scenarios you set up how Tosca will act upon these issues close the popup window, restart the browser, try again, skip the test.

Cleanup scenarios take place when the test is completed, irrespective of its success or failure. Cleanup brings the application back to the state it was before starting the test run – you may need to log out, close windows, or clear down the data used during the test or the application configuration may need to be reset. In the absence of appropriate clean-up the next test would be run against an unclean state and is guaranteed to fail for non-test defects.

Configuration parameters are used in:

• Execution Lists to define runtime settings like browser type, environment URL, or timeout values
• Test Case Templates to pass environment-specific configurations to template instances
• Test Step Libraries to control the behaviour of reusable components
• ExecutionEntry configurations to override settings at the execution level without modifying the test case itself.

The key benefit is that you separate environment-specific values from test logic. The same test case runs against dev, staging, and production simply by changing configuration parameters at the execution list level.

You can imagine how this can quickly get unmanageable if you have a login test that you need to run with 50 different username/password pairs, and you have 50 different test cases with the same steps. With a template, you create the test logic once. Then you create template instances, each linked to a different row of test data from TCD, Excel, or TDM. 

If the login flow changes, you update a single template, and all 50 instances reflect the change instantly. This is fundamental to how Tosca scales.

The automation flow in Tosca follows a clear sequence:

1. Requirements with Risk Weightage: Define application requirements and assign Risk Weightage (Frequency of Use × Damage Class) to prioritize which areas get automated first.
2. Modules with Identification: Scan the application using XScan to create Modules. Choose the best identification mechanism (properties, anchor, index) and use regex for any dynamic parts.
3. Test Case Design (TCD): Utilize the data generation techniques such as Boundary Value Analysis, Equivalence Partitioning. Define Classes (data sets) to ensure optimal coverage with minimal test cases.
4. Test Cases with Templates and Libraries: Create a TestCase Template by abstracting the logic with parameters. Build reusable TestStep Blocks for common flows. Instantiate the template into instances linked to TCD data or external sources like Excel.
5. Execution and Reporting. Create Execution Lists, run them, and use the Reporting section to analyze results and share quality metrics with stakeholders.

The process follows three steps:

• Define Range: The cell must be within a defined range in the TBox Excel Range Manipulation module.
• Access Property: Target the specific cell using column and row constraints, then access the property through the Control Properties section.
• Set or Verify: Use Input or Verify ActionMode on the cell property.

For example, to verify a cell is bold: target the cell, set ActionMode to Verify, specify Control Property as FontStyle, and set Value to Bold. For formulas, verify the Formula property to check the formula itself, or verify the cell's main value to check the calculated result.

How it works:

• Use the TBox DB Connection module to connect to the Excel file through OLEDB drivers (e.g., Microsoft.ACE.OLEDB.12.0).
• Use the TBox Execute SQL Statement module. The worksheet name acts as the table name (e.g., SELECT * FROM [Sheet1$] WHERE Status = 'New').
• The result set is stored in a Tosca XBuffer for use in subsequent test steps.

Benefits:

• Fast, targeted retrieval using WHERE, JOIN, and other SQL clauses without reading the entire sheet.
• Large data handling makes this the preferred method for big Excel files where iterating row by row would be slow.
• Data manipulation lets you UPDATE and DELETE test data directly in the Excel file during test execution.

API contract testing ensures the API provides what the consumer expects-the right endpoint, with the right shape of requests and responses, the right status codes, data types and the agreed error behaviour. 

In Tosca, you use the API Scan feature to import the definition (Swagger/OpenAPI, WSDL) for an API and generate a module for each endpoint. 

You can then create test cases to send requests and validate the response against the contract: 

Does it have the expected status code? 

Does it contain all necessary fields?

Do they have the expected data types?

Is the error response formatted as discussed?

Breaking changes can be detected early with API contract tests, before they impact consuming systems.

An IaC tool can provision the infrastructure defined as code. It is the job of Tosca to test the result. After Terraform deploys an IaC configuration, Tosca can run a suite of tests to ensure that the VMs have been deployed successfully, the correct network ports are open, the databases can be reached, load balancers are correctly configured to route traffic, and applications are running successfully on the provisioned infrastructure.

This bridges the gap between “the infrastructure has been deployed” and “the infrastructure is actually working,” putting the “quality check” on the IaC process by using Tosca as the quality gate in the IaC workflow.

WCAG (Web Content Accessibility Guidelines) are a set of guidelines that state web applications must be perceivable, operable, understandable and robust for disabled users. Some automated checks that could be performed using it include:

• Alt text on all images and non-text content
• Keyboard navigation, ensuring every element is reachable with a mouse
• Colour contrast ratios meeting minimum thresholds (4.5:1 for normal text)
• ARIA attributes correctly describing dynamic content for screen readers
• Explicitly defined labels on all form elements.

Tosca can automate many of these using XBrowser modules to check for certain DOM attributes, property values and structural requirements needed to meet WCAG standards. Manual testing will still be required for non-objective testing, such as content clarity.

The approach involves three parts. First, scan the web page and create a module that identifies anchor (<a>) elements. Use a broad identification (like TagName = "a") to capture all links rather than specific ones.

Second, use a loop construct in your test case with the XBrowser engine to iterate through all matching elements on the page. For each element, extract the href attribute and the InnerText property.

Third, write the collected data to an external file (CSV or Excel) using Tosca's TBox Excel or file handling modules. Count the total by tracking iterations. The final output is a file with every link URL and its display text, plus a total count at the end.

On large projects I have worked with, these are the things that actually reduced maintenance:

• Model-based approach where all technical identification lives in Modules. UI changes update one Module, not 200 test cases.
• TestCase Templates for any test that runs with multiple data sets. Write once, instantiate many.
• Reusable TestStep Blocks and Libraries for common flows like login, navigation, and logout.
• Business Parameters to externalize test data so logic never contains hardcoded values.
• Stable scanning properties chosen deliberately (unique IDs first, regex for dynamic parts) to minimize how often modules need updating.
• Folder structure and naming conventions enforced from day one. Messy projects become unmaintainable fast regardless of how good the technical design is.

Start by understanding why the scanner is failing. Is the element's ID changing on every page load? Is it nested inside a dynamic container? Is it rendered by a framework that generates random attributes?

Step through these options in order:

• Regular Expressions on the parts of the property that stay consistent. If the ID is "btn_submit_7842" and only the number changes, use regex: btn_submit_\d+
• Anchor to identify the element relative to a stable nearby element. "The input field next to the label 'Email Address'".
• Index as a last resort if multiple matches exist and other methods fail. Position-based, so fragile.
• Vision AI for cases where technical properties are completely unreliable: VDI environments, legacy systems with proprietary controls, or image-based elements with zero DOM attributes.

Tosca's XBrowser engine supports Chrome, Firefox, Edge, and Internet Explorer. The browser selection is controlled through a configuration parameter, typically Browser, set on the execution list or test configuration.

You write your test cases once using XBrowser modules. Then you create separate execution lists (or execution entries) for each browser, changing only the browser configuration parameter. The same test logic runs across all browsers without any duplication.

To integrate Tosca with cloud-based cross-browser testing platforms, such as BrowserStack or Sauce Labs, make use of the remote execution configuration settings. 

Spin up virtual machines on your cloud provider (EC2 on AWS, Azure VMs, or GCE on GCP). Install the Tosca DEX agent on each VM. The agent registers with your Tosca server and becomes available as an execution endpoint.

Configure your execution lists to target these cloud-based agents. You can scale by adding more VMs during heavy testing periods and shutting them down when done. For browser testing, install the required browsers on the VMs or connect to cloud-based grids like BrowserStack.

For Docker-based setups, containerise the DEX agent and orchestrate through Kubernetes for elastic scaling.

There will be a task within your CI/CD pipeline that invokes the execution API in Tosca or triggers the Tosca CI Client, specifying the ID of your execution list.

• Jenkins: Invoke the Tricentis CI plugin or perform a shell step that calls the Tosca CI command-line tool pointing to your execution list.
• GitHub Actions: Make use of a workflow step to invoke a REST API endpoint in Tosca for initiating execution and perform a polling action to fetch the results.
• GitLab CI: Create a pipeline stage that uses a script step to initiate the execution by calling either the CI command line tool or the REST API and to make your pipeline fail if tests do not pass(green).

In all cases, Tosca would return execution results such as Pass/Fail/Error counts for your pipeline.

A scalable Tosca framework is built on:

• Module library with stable, well maintained modules organized by application area.
• TestCase Templates for any scenario that runs with variable data.
• Reusable TestStep Blocks for common flows (login, navigation, validation).
• Externalized test data through TCD, Excel, or TDM so logic and data are fully separated.
• Configuration parameters for environment switching (dev, staging, prod) without modifying test cases.
• CI/CD integration so tests run automatically on every build.
• Execution architecture that supports distributed and cloud-based execution for parallel runs.
• Naming conventions and folder structure enforced from day one.

Here is a real-world scenario. A large enterprise runs 5,000 test cases nightly. Over six months, predictive analytics identifies patterns: test cases covering the payment module fail 3x more often after specific types of code commits touching the pricing engine.

Before the next release, the analytics flags that the current code changes overlap heavily with the pricing engine modules. The testing team prioritizes the payment module test suite and runs it first. It catches two critical regressions that would have reached production.

The prediction is based on correlating code change patterns, historical failure rates, module dependencies, and execution trends. Tosca's integration with tools like SeaLights provides this kind of test impact analysis, showing exactly which tests are at risk given the code changes in a release.

To set it up:

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

Example: If the RTB handles an optional address field, and you only want it to execute when the address is provided:

Condition: {AddressLine1} != ""

If the calling test case passes an empty value for {AddressLine1}, the entire RTB is skipped during execution. If a value is present, the RTB runs normally.

This is particularly useful for optional flows that only apply to certain data combinations. Instead of creating separate test cases for "with address" and "without address," a single test case handles both by letting the condition determine whether the RTB fires.