82 Tosca interview questions with answers

What they are assessing

Whether you understand model based testing rather than reciting scriptless.

Model answer

Tosca is a commercial test automation suite built on a model based approach. Instead of writing code against locators, you scan the application to create Modules that represent its controls, then build TestCases by dragging those Modules in and supplying values. The separation is the point: the technical description of a control lives in one Module, and every TestCase referencing it inherits a change automatically. Compared with a code framework you trade flexibility and version control friendliness for lower maintenance and a lower barrier for non programmers.

Likely follow-up

What do you give up by choosing Tosca over a code based framework?

What they are assessing

Product knowledge.

Model answer

Tosca Commander is the main workbench where you build and manage Modules, TestCases, TestCase Design, Requirements and ExecutionLists. The Tosca Executor runs tests, either from Commander or headless. Tosca Wizard was the older scanning tool, largely replaced by XScan. Distributed Execution, usually called DEX, coordinates runs across agents. There is also Test Data Management and the Test Data Service for provisioning data, Tosca CI for pipeline integration, and qTest or Tricentis Analytics for reporting depending on the licensing.

What they are assessing

Basic navigation knowledge.

Model answer

Modules, holding the scanned technical representation of the application. TestCases, holding the test logic. TestCase Design, holding the data in TestSheets and Instances. Requirements, for risk based coverage. Execution, holding ExecutionLists and their results. Configurations, and Issues in some versions. The separation of Modules, TestCases and TestCase Design is the structural idea behind the whole tool: technical detail, logic and data are kept apart so each can change independently.

What they are assessing

Whether you can argue the case rather than repeat marketing.

Model answer

Maintenance leverage. When a control changes, you update one Module and every TestCase using it is corrected, rather than editing locators across dozens of scripts. It also lowers the skill floor, so business analysts can assemble TestCases from existing Modules. The honest counterpoint is that it only pays off if Modules are properly structured and reused: a project where every scan creates a new Module has all the maintenance cost of a code framework plus licence fees, and that is a common outcome.

Trap to avoid

Claiming it removes maintenance. It relocates maintenance into the Module layer, which still has to be curated.

What they are assessing

The core structural distinction.

Model answer

A Module is the technical description of a screen, a dialog or a set of controls, produced by scanning, and it contains ModuleAttributes identifying each control. It holds no test data and no logic. A TestCase is the sequence of TestSteps, each referencing a Module, with TestStepValues supplying what to do with each control: what to enter, what to verify. So a Module says how to reach a control and the TestCase says what to do with it.

What they are assessing

Detail knowledge of how steering works.

Model answer

A TestStepValue is the value assigned to a ModuleAttribute within a TestStep. Its ActionMode determines what Tosca does with it. Input enters the value. Verify asserts the actual matches the expected. Buffer stores the actual value for later use. WaitOn waits until the control reaches the value. Select chooses an item in a list. Constraint identifies which row or object to act on, typically in a table. Insert is used for database steering. Getting ActionModes right is most of what building a good TestCase consists of.

Likely follow-up

What is the difference between Verify and WaitOn?

What they are assessing

Honest judgement about tool fit.

Model answer

When the team is engineering strong and wants tests in the same repository and review process as the application, because Tosca artefacts live in its own repository and do not diff or review like code. When the application is heavily custom rendered or canvas based, where scanning struggles and you fall back to image recognition, which is fragile. When budget matters and the coverage need is modest, since licensing is significant. And when most of the value would come from unit and API level tests, which Tosca can do but is not the cheapest way to get.

What they are assessing

The starting point of any Tosca project.

Model answer

Scanning is pointing Tosca at the application so it reads the control hierarchy and generates Modules containing ModuleAttributes for each control it finds. XScan is the modern scanner for web applications; there are also scans for SAP, host and mainframe screens, and Insight for image based recognition where nothing else works. What you choose to include during the scan matters: taking every control on a complex page produces an unwieldy Module, so you select the controls the tests will actually steer.

What they are assessing

The Tosca equivalent of locator strategy.

Model answer

Through identification criteria on the ModuleAttribute: properties such as id, name, class, label, type and position in the hierarchy, combined by the scanner and editable afterwards. Robust identification means choosing stable properties, preferring id or a purpose built test attribute over position or generated class names, and using anchors so a control is located relative to something stable such as a label. The failure mode is identification by index, which works until the page adds a field and then silently steers the wrong control.

Trap to avoid

Accepting whatever the scanner produced without reviewing it. Auto generated identification often relies on index or generated classes and is the main source of brittle Tosca suites.

What they are assessing

Practical control handling.

Model answer

Steering Parameters modify how a step interacts with a control rather than what value it uses. Common ones are Timeout for waiting longer on a slow control, Optional so a missing control does not fail the step, WaitBefore and WaitAfter for deliberate pauses, ForceSet to write a value where the normal method fails, and Focus or Highlight for troubleshooting. They are a legitimate tool for genuine cases such as a slow loading region, and they are also the place where people hide instability rather than fixing identification.

What they are assessing

Conditional handling.

Model answer

Mark the TestStepValue or the step as Optional so its absence does not fail the run, which is right for genuinely optional elements such as a cookie banner or a promotional overlay. Where the presence is meaningful rather than incidental, a conditional structure is better: an IF TestStep evaluating a buffered value, so the flow branches explicitly and the report shows which path ran. Using Optional everywhere to suppress failures is the pattern to avoid, because the suite then passes whether or not the application worked.

What they are assessing

The single biggest determinant of a healthy Tosca project.

Model answer

One Module per logical screen or reusable component rather than per scan, with a folder structure mirroring the application so people can find what exists. A naming convention that makes the target obvious. And a rule that nobody scans before checking whether a Module already covers that screen, because duplicate Modules for the same page are how a project ends up with the maintenance profile it was meant to avoid. Periodic review for unused Modules matters too, since they accumulate and nobody deletes them.

Likely follow-up

How would you find duplicate Modules in an existing project?

What they are assessing

Awareness of image based recognition and its cost.

Model answer

Insight identifies controls by image recognition rather than by the control hierarchy, which makes it the option for technologies Tosca cannot read: certain Citrix or remote desktop scenarios, custom rendered canvases, and legacy graphical clients. It is a last resort because image matching breaks with resolution changes, theme changes, font rendering differences and scaling, so it is the least stable identification available. If a project relies heavily on Insight, the honest advice is usually to ask the development team for accessible markup rather than to invest further in the tests.

What they are assessing

The basic workflow.

Model answer

Create a TestCase, then drag the Modules you need into it, which creates TestSteps. Each TestStep exposes the ModuleAttributes as TestStepValues, and you set the value and ActionMode for each: Input for data entry, Verify for assertions, Buffer to capture something. Order the steps to match the user flow, add control structures such as IF or LOOP where needed, and then run it from Commander or add it to an ExecutionList. Building the first one takes minutes; building them so they are reusable is the actual skill.

What they are assessing

Flow control knowledge.

Model answer

IF for conditional execution based on a buffered value or an expression. LOOP for repeating a block a set number of times, and WHILE for repeating while a condition holds. There is also a Do While variant. TestStepFolders group steps logically. Beyond these, reuse is provided through TestStepLibrary blocks rather than through procedural constructs. Tosca deliberately keeps the flow control simple, which is fine for most business flows and becomes a limitation when a test needs genuinely complex logic.

What they are assessing

Design judgement.

Model answer

Independence, so it can run in any order and in parallel: it creates its own preconditions rather than relying on a previous TestCase. A single clear purpose rather than a long journey verifying eight unrelated things, because a long TestCase failing at step forty tells you little. Reuse of library blocks for common sequences such as login and navigation. Data supplied from TestCase Design rather than hard coded into steps. And cleanup, so it leaves the system as it found it.

What they are assessing

Assertion mechanics.

Model answer

Set the ActionMode of the TestStepValue to Verify and provide the expected value, and Tosca compares the actual against it. The expected value can be a literal, a buffer reference, or a dynamic expression, which is how you verify calculated or date dependent values. For partial matches you use an expression such as a wildcard comparison rather than an exact string. Verification of a control not being present is done by combining Verify with the appropriate steering rather than by absence of a step.

Likely follow-up

How would you verify that an error message is not displayed?

What they are assessing

The most common practical problem.

Model answer

Buffer it. Set the ActionMode to Buffer on the control holding the generated value, which stores it under a named buffer, then reference that buffer later with the buffer syntax wherever the value is needed, including in verifications and in database queries. That is the Tosca equivalent of correlation. Where the value needs transforming first, a dynamic expression around the buffer handles it. Hard coding a value that the application generates is the mistake, and it produces a test that passes exactly once.

What they are assessing

Composition rather than monolithic tests.

Model answer

Decompose it into reusable blocks in the TestStepLibrary, one per business activity such as create customer, add product, submit order. Then assemble TestCases from those blocks with different data rather than duplicating the sequence. Each block takes its inputs as business parameters so it is genuinely reusable rather than hard wired. The benefit appears at the first application change: one block is corrected and every TestCase using it is fixed, which is the whole reason for choosing a model based tool.

What they are assessing

The data layer concept.

Model answer

TestCase Design is where the data lives, separated from the TestCase logic. You define TestSheets containing Attributes, which are the data fields, and Instances, which are the value combinations. A TestCase Template is then linked to a TestSheet, and Tosca generates a Template Instance per data Instance, producing one executable TestCase per data set. The point is that adding a new data scenario means adding a row rather than copying a TestCase.

Likely follow-up

What happens to existing Template Instances when you change the Template?

What they are assessing

A distinction that confuses newcomers.

Model answer

The Template is the TestCase containing the logic with placeholders for data, linked to a TestSheet. A Template Instance is a concrete TestCase generated from that Template combined with one data Instance, and it is what actually executes. Instances are regenerated when the Template changes, so you never edit a Template Instance directly: any change made there is lost on the next generation. Editing the instance instead of the template is a very common early mistake.

Trap to avoid

Editing a Template Instance to fix something. The change disappears the next time instances are regenerated from the Template.

What they are assessing

Whether you use the tool to reduce test count.

Model answer

Tosca can generate combinations of attribute values rather than requiring every combination to be listed manually, including linear, pairwise and full combinatorial strategies. Pairwise is the useful default, generating a set where every pair of values appears together at least once, which typically reduces thousands of combinations to dozens while retaining most of the defect finding power. It rests on the observation that most defects come from a single parameter or an interaction between two rather than higher order interactions.

What they are assessing

Data architecture judgement.

Model answer

TestCase Design holds the data that defines the scenario: the inputs a business person would recognise as distinguishing one test from another. Buffers hold values produced by the application during the run, which by definition cannot be known in advance. Dynamic expressions hold values that are derived rather than chosen, such as today plus thirty days. Putting a generated order number in TestCase Design is wrong, and so is hard coding a business scenario into a step where a reviewer cannot see it.

What they are assessing

Awareness of the data provisioning side.

Model answer

The Test Data Service is a separate component for managing test data centrally: provisioning, reserving and recycling records so several tests and teams do not collide on the same accounts. TestCase Design is right for scenario data that defines the test. TDS is right when data must exist in the system, must be unique per run, and must be released afterwards. The problem it solves is the one that appears at scale: parallel runs consuming the same records and interfering with one another.

What they are assessing

The main reuse mechanism.

Model answer

A folder holding reusable TestStepBlocks that can be referenced from many TestCases. You build a block once, such as login or navigate to order screen, and reference it wherever it is needed. A referenced block is a link rather than a copy, so correcting the block corrects every TestCase using it. This is the mechanism that determines whether a Tosca project scales, and projects that copy and paste sequences instead of using the library end up with exactly the maintenance burden the tool was bought to avoid.

What they are assessing

Parameterising reusable blocks.

Model answer

Business Parameters are named inputs on a reusable TestStepBlock, so the same block behaves differently depending on what the caller passes. A login block takes username and password as business parameters rather than hard coding them, which makes it genuinely reusable across roles and environments. Without them a library block is only reusable when every caller wants identical behaviour, which is rarely the case, and people respond by copying the block rather than parameterising it.

Likely follow-up

How do you give a business parameter a default value?

What they are assessing

Judgement about abstraction.

Model answer

When a sequence appears in more than about two TestCases and represents a coherent business activity. The unit should be meaningful to a business reader, such as submit an order, rather than a single click. Over abstraction is a real risk in the other direction: a library of thirty single step blocks adds indirection without reducing maintenance, and makes TestCases harder to read. I would also avoid making blocks that take ten parameters, since that usually means the block is doing several things.

What they are assessing

Robustness design.

Model answer

A Recovery Scenario defines what Tosca does when a TestCase fails, so the run can continue in a known state rather than cascading failures. Typical actions are closing the browser or application, logging out, clearing session state, or navigating back to a home screen. It is attached at ExecutionList or TestCase level. Without one, a failure in a long ExecutionList commonly leaves the application in a broken state and every subsequent TestCase fails for reasons unrelated to what they were testing.

What they are assessing

Core data passing concept.

Model answer

A named store for a value captured at runtime, created by setting a TestStepValue ActionMode to Buffer, and referenced later with the buffer syntax. It is how values move between TestSteps and between TestCases within a run: capture the generated order number on one screen and use it to search on another, or to query the database. Buffers persist for the duration of the execution by default, and there is a setting controlling whether they survive between TestCases in an ExecutionList.

What they are assessing

Practical expression knowledge.

Model answer

DATE for generating dates relative to today with a format, which is how you avoid hard coding a date that expires. RANDOM for random values within constraints, useful for unique identifiers. CALC for arithmetic. EXP for general expression evaluation. And the buffer reference syntax for reading a buffered value. They can be nested, so you can calculate a date offset from a buffered value. Between them they cover most of what a code framework would use a helper method for.

Likely follow-up

How would you enter a date thirty days in the future in DD/MM/YYYY format?

What they are assessing

Combining buffers and calculation.

Model answer

Buffer the components, then verify the total against a CALC expression built from those buffers rather than against a hard coded number. That way the test remains valid when prices change, and it actually tests the calculation rather than confirming a number someone typed. The consideration is rounding: the expression must round the same way the application does, and mismatches of a penny are a common and legitimate finding rather than a test defect, so it is worth confirming the expected behaviour before assuming either side is wrong.

What they are assessing

Whether you see the coupling.

Model answer

It creates dependencies between TestCases that are invisible in the TestCase itself. A TestCase reading a buffer set by an earlier one cannot run alone, cannot run in parallel and will fail confusingly if the ExecutionList order changes. So buffers within a TestCase are fine, and buffers spanning TestCases should be treated as a design smell, handled instead by having each TestCase create its own preconditions or by provisioning data through the Test Data Service.

Trap to avoid

Building a suite where TestCase five depends on a buffer from TestCase two. It works in one ExecutionList and nowhere else.

What they are assessing

Basic execution organisation.

Model answer

An ExecutionList is a collection of TestCases assembled for a run, containing ExecutionEntries that reference them. It is how you define a smoke run, a regression run or a release run from the same set of TestCases, and it is what you schedule or trigger from CI. Results are recorded as ExecutionLogs against the list, so history is retained per run. You can also set execution level configuration there, such as the recovery scenario and whether to continue after failure.

What they are assessing

Scaling knowledge.

Model answer

DEX distributes an ExecutionList across several machines running Tosca agents, coordinated by a DEX server, so a long suite completes in a fraction of the time. You assign agent characteristics and the server allocates work accordingly, which also lets you target specific configurations such as a particular browser or operating system. The practical requirements are that TestCases are genuinely independent, that test data does not collide across agents, and that the environment under test can handle the concurrency.

Likely follow-up

What breaks first when you move a working serial suite to DEX?

What they are assessing

Headless execution.

Model answer

Through the Tosca Executor invoked from the command line, or through the Tosca CI client which is designed for pipeline use and produces JUnit compatible XML output. Either way you point it at an ExecutionList and a workspace, and it runs without the Commander UI. The CI client is the better option for a pipeline because the output format is consumable by Jenkins, Azure DevOps and similar, so results appear in the build rather than only in Tosca.

What they are assessing

Practical suite management.

Model answer

By purpose rather than by feature. A short smoke list that runs on every deployment and must stay under a few minutes. A regression list run nightly or before release, parallelised through DEX. Targeted lists per feature area for use during development of that area. And a quarantine list for known unstable TestCases, run and reported but not blocking. The principle is that each list has a clear question it answers and a clear audience, otherwise people run the full regression for everything and stop running anything.

What they are assessing

The prerequisite for DEX actually helping.

Model answer

Independence in three respects. Data: each TestCase uses its own records, ideally provisioned at runtime or reserved through the Test Data Service, rather than a shared account several TestCases modify. State: no reliance on buffers or application state left by another TestCase. Environment: no assumption about being the only session, which matters for anything with a single active session per user. Then cleanup through a recovery scenario so a failure does not poison the agent for the next TestCase assigned to it.

What they are assessing

A distinctive Tosca capability.

Model answer

Tosca lets you model Requirements with a weighting for business impact and a probability of failure, which combine into a risk value. TestCases are linked to Requirements, so the tool can report risk coverage rather than only test counts, and can tell you which portion of total risk your current suite addresses. The value is in prioritisation and in the conversation it forces: assigning weightings makes the business state what actually matters, which is usually more useful than the resulting number.

Likely follow-up

How would you set the weighting if the business will not commit to one?

What they are assessing

Traceability practice.

Model answer

By creating the link in the Requirements section, associating TestCases with the requirement they verify. The reasons to bother are coverage reporting, which shows requirements with no tests and tests covering nothing; impact analysis, so when a requirement changes you know which TestCases to review; and audit, since regulated environments require demonstrable traceability. The cost is maintenance, and the link decays quickly unless it is part of the definition of done for a story rather than a periodic clean up exercise.

What they are assessing

Critical thinking about a metric.

Model answer

It tells you what proportion of the risk you identified is addressed by tests that exist. It does not tell you whether those tests are good, whether the risk weightings are right, or whether you identified the risks that matter. So eighty per cent risk coverage with shallow tests and optimistic weightings is worse than it sounds. I would use it as a prioritisation aid and a conversation starter with the business, and be cautious about presenting it to management as a quality measure, because it is easily read as one.

What they are assessing

Team working knowledge.

Model answer

A single user workspace is a local file based workspace for one person. A multi user workspace connects to a common repository, usually a database, and several people work against it concurrently using check out and check in. In multi user mode you check out the objects you intend to change, which locks them, make your changes, then check in to publish. Understanding this is essential because most of the operational friction in a Tosca team comes from checkout conflicts.

What they are assessing

A real and frequent operational problem.

Model answer

Nobody else can modify it until it is checked in or the lock is released. An administrator can undo the checkout, which discards that person's uncommitted changes, so it is a decision rather than a routine action. The practical mitigations are checking in frequently rather than holding long checkouts, checking out the narrowest object needed rather than a parent folder which locks everything beneath it, and having an agreed team convention about end of day check in.

Trap to avoid

Checking out a whole folder to change one TestCase. It blocks the entire team and is the most common cause of Tosca workflow complaints.

What they are assessing

Honest assessment of a real weakness.

Model answer

It is pessimistic locking against a central repository rather than distributed branching, so there is no practical equivalent of a feature branch, no meaningful diff of a TestCase, and code review in the sense a developer means it is not available. Tosca does support branching and merging in later versions but it is heavier than Git and rarely used for routine work. The workarounds are process rather than tooling: small frequent check ins, clear ownership of areas, a naming convention that makes changes traceable, and peer review conducted by walking through the change in Commander.

What they are assessing

Deployment practice.

Model answer

The artefacts are usually shared through the common repository rather than deployed, so what actually varies between environments is configuration: URLs, credentials and environment specific data. Those belong in a configuration mechanism such as TCPs or environment specific parameters, read at runtime, rather than embedded in TestCases. Where separate repositories exist for different stages, subsets are exported and imported as TSU files. The principle is the same as any test asset: one set of tests, environment supplied as configuration.

What they are assessing

Whether you have used more than the UI engine.

Model answer

Through the API Engine, where you create an API Scan and either point it at a definition such as Swagger, OpenAPI or a WSDL, or construct the request manually. Tosca generates Modules representing the request and response structure, and you then build TestCases setting values on request attributes and verifying response attributes, including nested JSON and XML nodes. It supports the usual authentication schemes, and responses can be buffered for use in subsequent steps exactly as with UI tests.

Likely follow-up

How would you verify a specific element inside a nested JSON array?

What they are assessing

Test architecture reasoning, tool independent.

Model answer

Speed and stability. An API test runs in a fraction of the time, does not break when the layout changes, and fails for reasons related to the behaviour under test rather than a rendering timing issue. The same logic as any framework applies: business rules and data handling belong at the API layer, and only genuine end to end journeys need the UI. In Tosca specifically this also reduces the Module maintenance burden, since API Modules change far less often than scanned screens.

What they are assessing

Practical hybrid testing.

Model answer

Freely, since both are just TestSteps referencing different Module types, and buffers pass values between them. The pattern that pays off most is using API calls for setup and teardown around a UI verification: create the account and the order through the API in seconds, verify the resulting screen through the UI, then clean up through the API. That removes most of the slow, brittle part of a UI test while keeping the coverage that genuinely needs a browser.

What they are assessing

Breadth of engine knowledge.

Model answer

Through the Mobile Engine, which supports native, hybrid and mobile web applications on iOS and Android, connecting to real devices or emulators, and to device clouds. You scan the application to produce Modules much as with web, and the same TestCase construction applies. The considerations are the usual mobile ones rather than Tosca specific: device and version coverage, gestures, orientation, permissions, interruptions such as calls and notifications, and network conditions.

What they are assessing

Enterprise usage awareness.

Model answer

SAP is one of the strongest cases for Tosca, because it provides dedicated engines for SAP GUI, Fiori and S/4HANA that understand SAP control types natively rather than treating them as generic UI. That makes scanning reliable where a generic web driver struggles. It also matters commercially: SAP regression testing after transports and upgrades is high effort and high risk, and it is the scenario Tricentis sells into most successfully. Combining it with the API and database engines lets you verify a process end to end.

What they are assessing

Non UI verification.

Model answer

With a database Module configured with a connection, where you supply a SQL statement and steer the result. Values can be verified directly, or buffered for use elsewhere, and an Insert ActionMode supports writing. The most valuable use is verifying that a UI action produced the correct persisted state, which a UI only test cannot confirm, and setting up preconditions directly rather than through the interface. The caution is keeping credentials out of the TestCase and treating the queries as test assets that need maintenance when the schema changes.

What they are assessing

Output knowledge.

Model answer

ExecutionLogs against each ExecutionList, showing pass and fail per TestCase and per step with the values used, which is the primary record. Reports can be generated from those logs, including requirement and risk coverage reports. For screenshots on failure there is a configuration to capture them automatically. Beyond the product, Tricentis Analytics or qTest provide dashboards across runs, and the CI client emits JUnit XML so results surface in the build system rather than only inside Tosca.

What they are assessing

Pipeline knowledge.

Model answer

Using the Tosca CI client, invoked from the pipeline with the ExecutionList to run, which returns JUnit compatible XML that the build system parses so failures appear as test results. Plugins exist for Jenkins and Azure DevOps to simplify this. The practical constraints are that an agent machine with Tosca installed and licensed must be available, which is different from a code framework where the runner is just a dependency, and that the licence model needs to accommodate concurrent pipeline execution.

Likely follow-up

What is the licensing implication of running Tosca on several CI agents?

What they are assessing

Triage quality.

Model answer

Configure screenshot capture on failure, ensure the ExecutionLog is exported and archived with the build rather than only living in the workspace, and make sure the JUnit output includes the step level message rather than only the TestCase name. Adding the environment, build identifier and data set used to the log makes the difference between a report someone can act on and one that says a TestCase failed. Without this, every failure requires someone with Commander access to investigate, which becomes the bottleneck.

What they are assessing

The most common Tosca failure.

Model answer

Whether the control is actually present at that point, since the previous step may not have completed or navigated where expected. Then timing, because the control may exist later than the step runs, which a longer Timeout or a WaitOn step addresses. Then identification: whether the properties the Module relies on have changed, which is where rescanning or editing the identification criteria comes in. Then context, such as a frame, a new window or a modal dialog that the step is not looking inside.

What they are assessing

Environment and concurrency reasoning.

Model answer

Data collision with another TestCase running concurrently on the same records, which is the most common. Then state left by a previous TestCase on that agent, which a recovery scenario addresses. Then environment differences on the agent: screen resolution affecting element visibility, a different browser version, missing certificates or credentials, or no access to a required network path. Then timing, since an agent under load runs slower than a developer machine and exposes implicit assumptions about speed.

What they are assessing

Practical tooling knowledge.

Model answer

Run it in debug mode from Commander, which lets you step through, set breakpoints on TestSteps, and inspect buffer values as they are set. Highlight on the ModuleAttribute confirms Tosca is finding the control you think it is. Running a single TestStep in isolation checks identification without running the whole flow. And the ExecutionLog shows the actual values used, which usually resolves the class of failure where the test was steering correctly but with unexpected data.

Likely follow-up

How do you inspect the value of a buffer mid-run?

What they are assessing

Structured remediation.

Model answer

Measure first: duration per TestCase and failure rate per TestCase over recent runs, because both distributions are usually skewed and a handful of items account for most of the pain. Then categorise the failures into identification problems, timing problems, data collisions and genuine defects, since each has a different fix. Then act in order: fix identification at the Module level so one change fixes many TestCases, replace UI setup with API steps, remove fixed waits, and quarantine the worst offenders so the signal is restored while they are fixed.

What they are assessing

Whether you exploit the model based structure.

Model answer

By fixing it at the Module layer, which is exactly what the architecture is for. Rescan or edit the affected Module, and every TestCase referencing it is corrected without being touched. The work is identifying which Modules are affected, which the usage view supports, and verifying the fix with a targeted ExecutionList before the full run. If a change instead requires editing hundreds of TestCases individually, that is a signal the Modules were not structured for reuse, and worth saying so in an interview.

What they are assessing

Robustness handling.

Model answer

For a known and expected interruption, an optional step or a conditional block that dismisses it if present. For an unpredictable one, a recovery scenario that handles it at execution level so every TestCase benefits without each one carrying the handling. The judgement call is whether the popup is legitimate application behaviour, in which case it should be tested rather than dismissed, or noise such as a browser notification prompt, which is better prevented through browser configuration than handled in every test.

What they are assessing

Basic product distinction.

Model answer

Commander is the workbench where you create and organise everything: Modules, TestCases, TestCase Design, Requirements and ExecutionLists. Executor is the runtime that actually runs the tests, and it can be invoked from within Commander or standalone for unattended execution. In a CI pipeline it is the Executor, usually via the CI client, that runs, with no Commander involved. Licensing typically differs between the two, which matters when planning how many machines can run tests concurrently.

What they are assessing

Version awareness.

Model answer

XScan is the current scanning technology for web and most modern technologies, providing a clearer selection interface, better identification suggestions and support for modern frameworks. The Wizard was the older approach and remains for some legacy technologies. For an interview the relevant point is that projects built long ago on Wizard scans often have brittle identification, and migrating those Modules to XScan is a common improvement task rather than a one click operation.

What they are assessing

A very common practical requirement.

Model answer

Tables are steered through a table ModuleAttribute where you identify the target row using a Constraint, which is an ActionMode that says find the row where this column equals this value, then act on a cell within that row. That is far more robust than addressing by row index, which breaks when sorting or filtering changes. For iterating over rows, a LOOP with a row counter, or buffering the row count first, handles the general case.

Trap to avoid

Addressing table rows by index. It works with the current data and fails as soon as the data or sort order changes.

What they are assessing

Data organisation at scale.

Model answer

Keep TestSheets focused on one scenario family rather than becoming a spreadsheet of everything, and use attribute naming that a business reader recognises. Use combinatorial generation rather than manually enumerating combinations, so the intent is visible and the volume is derived. Reference shared reference data rather than repeating it across sheets. And review periodically for instances that no longer correspond to a real scenario, since data accumulates in the same way unused tests do and nobody removes it.

What they are assessing

Practical distinction.

Model answer

Running a TestCase from the TestCases section is for development and debugging: it executes immediately and the result is transient. Running an ExecutionList executes the entries in order, records ExecutionLogs with history, applies execution level configuration such as the recovery scenario, and is what you schedule or trigger from CI. The distinction matters because results that need to be reported or retained must come from an ExecutionList run, not an ad hoc one.

What they are assessing

Risk management of shared assets.

Model answer

Carefully, because one edit affects every TestCase referencing it, which is both the benefit and the risk. I would check the usage list first to understand the blast radius, make the change additive where possible by adding an optional business parameter rather than changing existing behaviour, and run a representative ExecutionList covering several consumers before checking in. On a large project it is worth agreeing that shared library blocks have named owners, so changes are not made by whoever happens to be in that area.

What they are assessing

Data uniqueness handling.

Model answer

Dynamic expressions, typically combining a fixed prefix with RANDOM or a timestamp from DATE, so each run produces values that do not collide with previous runs or with parallel agents. For example a username built from a prefix plus a timestamp to the second plus a random element. For values that must be unique across distributed agents, including an agent or run identifier avoids the case where two agents generate the same timestamp. The alternative for records that must exist is provisioning through the Test Data Service.

What they are assessing

Change management.

Model answer

Start narrow rather than modelling the whole application. Take one release scope, work with the product owner to weight the requirements in it, link the existing TestCases and show the coverage picture, which usually reveals something surprising such as heavy coverage of a low risk area. That single conversation is normally more persuasive than the framework. Then extend gradually. Attempting to model every requirement up front produces a large artefact nobody maintains, which is how most risk based testing initiatives quietly stop.

What they are assessing

Import and export knowledge.

Model answer

A Tosca subset unit, which is an export of a portion of the repository including the objects and their dependencies. It is used to move work between repositories that are not connected, to hand a component to another team, to take a backup of a specific area, or to supply a reproducible example to support. The thing to watch is dependencies: exporting a TestCase without the Modules and library blocks it references produces something that imports and does not run.

What they are assessing

Practical API scripting.

Model answer

Call the token endpoint as its own TestStep, buffer the token from the response, and reference that buffer in the authorisation header of subsequent requests. For a long ExecutionList, the token may expire partway through, so either refresh it at intervals using a conditional block checking elapsed time, or obtain it in a reusable library block called at the start of each TestCase so each one has a fresh token. Credentials themselves come from configuration rather than being stored in the TestCase.

What they are assessing

Communication as well as tooling.

Model answer

From ExecutionList results rather than anecdote: executed against planned, pass and fail counts, and defects raised, ideally as a trend across days rather than a single snapshot. Where risk based testing is in use, risk coverage is the more meaningful figure because it speaks to what is at stake rather than how many TestCases ran. I would also state what has not been executed and why, since that is the part stakeholders need for a release decision and the part most status reports omit.

What they are assessing

Optimisation priorities.

Model answer

Move coverage down the stack first, replacing UI TestCases with API TestCases where the check does not need a browser, which typically gives the largest gain. Replace UI based setup with API or database steps inside remaining TestCases. Remove duplicate coverage, which accumulates when TestCases are copied rather than parameterised. Then parallelise through DEX, which only helps once the TestCases are genuinely independent. Adding agents before fixing independence usually produces a faster suite with a higher failure rate.

Likely follow-up

How would you identify duplicate coverage across hundreds of TestCases?

What they are assessing

Commercial judgement.

Model answer

By comparing total cost against the alternative rather than looking at the licence in isolation. Costs are licences, training, and the fact that Tosca skills are scarcer and command a premium. Benefits are lower maintenance if Modules are well structured, faster authoring by non programmers, and strong support for SAP and packaged applications where an open source stack struggles. I would look hard at what proportion of the suite genuinely needs UI automation, because if most value is at API level the economics shift toward a code framework.

What they are assessing

Leadership on a tool with many footguns.

Model answer

Focus the standards on the decisions that are expensive to reverse. Module structure and naming, since duplicated Modules are the main way projects decay. A rule that nobody scans without checking for an existing Module. Library block conventions and ownership. Where data lives, meaning TestCase Design rather than hard coded values. Check in discipline for the shared repository. And a review step before check in, because Tosca has no pull request and without a deliberate review nothing gets looked at.

What they are assessing

Context switching knowledge.

Model answer

Tosca represents the frame or window in the Module hierarchy during scanning, so the controls inside appear under it and steering works without an explicit switch command in most cases. Where a window opens dynamically, the window identification may need adjusting to match on title or URL pattern rather than a fixed value. Problems here usually present as control not found, so the first check when a step fails after a popup is whether the Module is looking in the right context.

What they are assessing

Prioritisation.

Model answer

The checks that would stop everything if they failed, and nothing else. Can users authenticate, does the main navigation load, can the primary revenue path complete, do the critical integrations respond. The constraint is time: if it does not finish in a few minutes it stops being run on every deployment, which defeats its purpose. I would keep it to a small number of TestCases, review it when the product changes, and resist the steady pressure to add just one more thing to it.

What they are assessing

Organisation within a TestCase.

Model answer

It groups related TestSteps for readability, and can be used as the unit for control structures and for conditional or repeated execution. On a TestCase with forty steps, grouping them into folders named after the business activity makes the TestCase readable by someone who did not write it, and makes the failure location meaningful in the log. It is cosmetic in execution terms and significant in maintenance terms, which is a reasonable summary of a lot of Tosca practice.

What they are assessing

Practical collaboration.

Model answer

Only one can hold the checkout, so the answer is coordination rather than tooling: agree who takes it, keep the checkout short, and check in as soon as the change is verified. Where the changes are genuinely independent, sometimes one person makes both. Where this happens frequently it usually indicates the Module is too large and covers several screens, so splitting it reduces contention as well as improving reuse. Long lived checkouts are the underlying problem in almost every case.

What they are assessing

Ecosystem knowledge.

Model answer

Through the available connectors, which typically synchronise requirements or user stories into the Requirements section and push execution results and defects back. Tricentis qTest is the first party option with the deepest integration. The practical caution is that bidirectional synchronisation tends to drift: identifiers get out of step when items are deleted or moved, and the integration then reports confidently against things that no longer exist, so it needs periodic reconciliation rather than being assumed correct.

What they are assessing

Practical normalisation.

Model answer

Buffer the value, then normalise before comparing rather than comparing the raw strings. A DATE expression can reformat a buffered date into the format the second screen uses, and string handling expressions can strip currency symbols and thousand separators. The alternative, and often the better one, is verifying against the underlying data through an API or database step, where the value has a canonical form, and treating the display format as a separate presentational check.

What they are assessing

Attention to invisible differences.

Model answer

Almost always something not visible in the rendering: trailing or leading whitespace, a non breaking space rather than a normal one, a different unicode character that looks identical, hidden formatting, or the control returning an underlying value different from the displayed one such as a code rather than a label. The ExecutionLog shows the actual value captured, which usually makes the difference obvious. The fix is either trimming and normalising in the comparison or verifying against the underlying value deliberately.

What they are assessing

Recovery of a degraded asset.

Model answer

Assess before rebuilding, because a rewrite usually recreates the same problems. Measure duplicate Modules, unused objects, TestCases with hard coded data, failure rate per TestCase and duration. That normally shows the decay is concentrated: a few hundred duplicate Modules and a set of TestCases copied rather than parameterised. Then fix structurally in priority order, starting with consolidating Modules since that fixes many TestCases at once, and introduce the standards that prevent recurrence. Reserve rebuilding for areas where the application itself has changed beyond recognition.

What they are assessing

A considered, non partisan view.

Model answer

On fit rather than loyalty. It extends well where the team tests packaged or enterprise applications, has limited programming capability, and values low maintenance over repository integration. It extends badly to a team of engineers building a modern web application who want tests in the same repository, reviewed as code, running in the same pipeline, because Tosca's version control model will be a permanent source of friction. I would also weigh the licence cost per additional seat against what the same budget buys in engineering time, and be willing to conclude against the incumbent tool.