[Link]

net/slideshow/interview-questionsdocx-
253432855/253432855

1 - Module Overview

2- Scanning

3- Identification by different Methods

4 - Test Case Creation

5 - Test Configuration Parameters

6 - Action Modes

7 - Buffer Creation

8- Waits

9- Debugging & Running in Scratch book

10- Inbuilt Function Usage

11- Reusable Test Step Block - Business Parameters

12- Template Creation

13- Test Case Design Creation

14- Instantiation & Creation of Test Instances

15- Execution List Setup

16. Cardinality

Example: How to create User defined Modules

User defined Modules: Identifying elements on your application.

Different ways how we can identify the elements .[Link] their:

1. Identify by Properties

2. Identify by Anchor

3. Identify by Image

4. Identify by Index.

User-Defined Modules in Tosca

User-Defined Modules in Tosca allow testers to create custom modules when
standard modules cannot identify elements properly. These modules help in
identifying, storing, and interacting with application elements in an efficient
manner.

Why are User-Defined Modules Needed?

• When standard Tosca modules fail to identify elements.

• When elements have dynamic attributes that change frequently.
• When we need to improve reusability and maintainability of test cases.

Example Scenario:

Imagine you are testing a web-based E-commerce application, where you

need to interact with a "Buy Now" button. If Tosca fails to recognize it using
standard scanning, you can create a User-Defined Module and use one of the
different identification methods to recognize the button.

Different Ways to Identify Elements in Tosca

There are four primary ways to identify UI elements in Tosca:

1. Identify by Properties
Definition:
This method identifies an element based on its attributes (properties) such as:
✔ ID
✔ Name
✔ Class
✔ Type
✔ Value

Example Scenario:

You are testing a Login Page where the "Username" input field has a unique ID
property.

How Tosca Identifies It:

• Tosca scans the application and identifies the element using:

o Property: id=userNameField

Real-Time Use in Testing:

• You use the unique ID userNameField to enter the username while

executing test cases.

Note: If an element has a unique ID or Name, always prefer this method as

it is the most stable

2. Identify by Anchor
Definition:
When an element does not have a unique property, Tosca allows
identification based on a nearby stable element (Anchor).

Example Scenario:

You need to interact with the Password field, but it has no ID or Name.
However, there is a "Password" label right above it, which has a unique ID.

How Tosca Identifies It:

• Tosca uses the label "Password" (id=passwordLabel) as an anchor to

identify the input field below it.

Real-Time Use in Testing:

 • Instead of relying on dynamic input fields, you use the "Password" label
to locate the field reliably.
• Useful when dealing with dynamic fields where properties keep
changing.

Note: Always use an anchor when direct identification is not possible.

3. Identify by Image
Definition:
This method identifies elements by capturing an image of them. It is useful
when:
✔ The element has no ID, Name, or other properties.
✔ The element is a custom button or icon without text.

Example Scenario:

You need to click on a search icon ( ), but it does not have an ID, name, or text.

How Tosca Identifies It:

• Tosca takes a screenshot of the search icon and uses it to find and interact
with the element.

Real-Time Use in Testing:

• ✔ Works well for mobile apps or custom buttons that have no unique
properties.
• Note: Use image identification only when other methods don’t
work, as small UI changes (like color, size, or position) can cause
failures.

4. Identify by Index

Simple Definition:
When multiple elements look the same and have no unique properties, Tosca
gives them a number (index) to tell them apart.
Example Scenario:

Imagine you are testing a shopping website with two "Add to Cart" buttons for
different products. Since both buttons look the same and have no unique ID
or Name, Tosca assigns them numbers to differentiate them.

How Tosca Identifies Them:

• First "Add to Cart" button → Index = 1

• Second "Add to Cart" button → Index = 2

How It Works in Testing:

• ✔ If you want to click the first "Add to Cart" button, use Index=1.
✔ If you want to click the second "Add to Cart" button, use Index=2.

📝 Important Note:
Using index-based identification is not recommended unless necessary because if a
new button is added, the index numbers might change, causing test failures. Use
"Identify by Properties" or "Identify by Anchor" first if possible.

Final Recommendation (Simplified)

Best Option: Use "Identify by Properties" whenever possible.

2. If no unique property is available, use "Identify by Anchor" (link it to a
nearby stable element).
3. Use "Identify by Image" only if there are no properties or anchors (but it’s
risky if the UI changes).
4. Last Resort: Use "Identify by Index" only when nothing else works
(because indexes can change).

5. Always try "Identify by Properties" first for the most stable tests!

Summary for Your Interview

In Tosca, User-Defined Modules help identify elements when standard methods don’t work.
There are four ways to identify elements:
Designing TestCases in Tosca
================================
1. Test Configuration Parameter
2. Reusable TestBlocks (Libraries)

Test Configuration Parameters (TCPs) in Tosca are predefined values that can be
used in multiple test cases. Instead of manually changing values in each test, you set
them once and reuse them.

Or

It is a storage place which stores some values, that value we can use in our TC.

It is same like a variable. What we use in programming same like that, But
what is the use of variable in TCP? Instead of manually changing values in each
test, you set them once and reuse them

1. Re-usability

2. Easy to Manage.
→Create

→Use

→Delete

Tcp can be under the TestCases or TestExecutionList.

Note : for UI related tests require a mandatory TCP called as Browser.

Point2: To use the Test Configuration parameters in a TestCase, you can

link the test configuration parmeter directly to the TestStepValue using the
following dynamic Expression: {CP[<Test configuration
parameter name>]}

When to Use in Real-Time Scenarios:

TCPs are helpful when you need to run the same test with different values
without modifying the test steps.

Example Scenario: Testing a Login Page

Imagine you are testing a login page for different users. Normally, you would
have to write separate test cases for each user. But with TCPs, you can
define values once and reuse them.

Without TCPs (Hardcoded Values – Not Recommended)

You create multiple test cases like:
Test 1 → Username: user1@[Link], Password: Test@123
Test 2 → Username: user2@[Link], Password: Pass@456
Test 3 → Username: user3@[Link], Password: Hello@789

If the login format changes, you have to edit every test case manually .

Using TCPs (Best Approach – Easy to Maintain)

Instead of hardcoding, you set up TCPs:

Test Configuration Parameters:

• Username = user1@[Link]
 • Password = Test@123

Now, whenever you run the test, Tosca picks the values from TCPs. If you
want to test another user, just change the TCP values, and the test case will
work without modifications.

Scenario-Based Questions
7️⃣ Scenario: You need to run the same test case on Chrome and
Firefox. How can you achieve this using TCPs?

Answer:
Define a TCP:

• Browser = Chrome

Before execution, change the value to Firefox → Tosca will run the same test
case in Firefox.

8️⃣ Scenario: You are testing a banking app where transaction

amounts vary. How would you handle this with TCPs?

Answer:
Define a TCP:

• TransactionAmount = 5000

For different amounts, update TCP value instead of modifying test steps.

Action Modes in Tosca

1. Introduction to Action Modes
2. Example and Usage of Buffer Action Mode
3. Example and Usage of Select Action Mode
4. Example and Usage of Verify Action Mode
5. Example and Usage of Input Action Mode
6. Example and Usage of Wait On Mode
 7. Recap of Action Mode

Final Tip:

• Use Buffer when storing values.

• Use Select for dropdowns and lists.
• Use Verify for validation.
• Use Input for entering values.
• Use WaitOn for handling delays.

Action Modes in Tosca – Complete Guide with Real-Time

Examples

Action Modes

Action Modes in Tosca define how a test case interacts with an application.
They help in entering, selecting, verifying, storing, and waiting for values
during test execution.

ActionModes perform reading or input operations on a control. Reading

operations read the property that is defined for a control. Input operations modify the
defined property during test execution.

ActionModes for input operations:

▪ Input
▪ Insert
ActionModes for reading operations:
▪ Buffer
▪ Constraint
▪ Verify
▪ WaitOn
▪ Select
Buffer
The Buffer Action Mode stores a value from the application so it can be used
later in the test.

When to Use?

When you need to save dynamic values like OTPs, order numbers, or user
IDs.

Real-Time Example

Scenario: Storing an Order Number for Later Use

Imagine you are testing an e-commerce website. When a user places an order, the
system generates a unique Order Number (e.g., ORD12345). You need to store this
number and use it later to check the order status.

How Buffer Works in This Case?

1⃣ After placing the order, the system displays:

➡️ "Your Order Number is ORD12345"
2⃣ Tosca stores this order number in a buffer ({B[OrderNumber]}).
3⃣ In the next test step, Tosca retrieves {B[OrderNumber]} to check the order status.

Test Steps in Tosca:

Field Action Mode Value Purpose

Order Number Text Buffer {B[OrderNumber]} Stores the order number

Search Field Input {B[OrderNumber]} Uses the stored order number

Search Button Input Click Clicks to check order status

Benefit: You don’t have to manually enter the order number each time. If the order
number changes, Tosca will still use the correct one dynamically.

Why Use Buffer?

• Works great for dynamic values (Order Numbers, OTPs, Ticket IDs, etc.).
• Saves values without hardcoding them.
• Ensures consistency in testing.
Select
The Select Action Mode is used to choose an option from a dropdown, list, or
checkbox.

When to Use?

When selecting a country, gender, or product category from a list.

Where to Use Select Mode?

• Dropdowns (e.g., Country, State, Gender)

• Lists & Menus (e.g., Product Categories, Payment Methods)
• Radio Buttons (when options are selectable)

Scenario: Selecting a Country from a Dropdown

Imagine you are testing a registration form where users need to select their country
from a dropdown list. Instead of typing the country name manually, Tosca will select
it from the dropdown using the Select action mode.

How Tosca Select Works in This Case?

1⃣ The form has a Country dropdown with options:

• India
• USA
• UK
• Canada
2⃣ You need to select India from the dropdown.

Test Steps in Tosca:

Field Action Mode Value Purpose

Country Dropdown Select India Selects "India" from the dropdown

Submit Button Input Click Clicks to submit the form

Benefit: Instead of manually typing, Tosca will automatically select the correct
option from the dropdown.
Verify
It is used to check if something is correct on the screen.

When to Use?

To confirm login success, order confirmation, error messages, etc.

Real-Time Example: Checking Login Success

1 You log into a website.

2 After login, a message appears: "Welcome, Admin!"
3 Tosca checks if the message is correct.

Test Steps in Tosca:

Field Action Mode Expected Value

Welcome Message Verify Welcome, Admin!

If the message matches, the test passes.

If it doesn’t match, the test fails.

🔥 Why Use Verify?

• To confirm expected results automatically.

• Helps ensure that the application works as expected.

Input
It is used to enter text or click buttons in Tosca.

When to Use?

To type in fields (username, password, search bar)

To click buttons (login, submit, add to cart)
Real-Time Example: Logging into a Website

1 Enter "admin" in the Username field.

2 Enter "Admin@123" in the Password field.
3 Click the Login button.

Test Steps in Tosca:

Field Action Mode Value

Username Input admin

Password Input Admin@123

Login Button Input Click

Tosca will automatically type and click for you!

WaitOn

WaitOn makes Tosca pause until something appears or disappears before moving to
the next step.

When should you use it?

When waiting for loading screens, pop-ups, or success messages.

Prevents test failures caused by slow page loading.

Simple Real-Life Example:

Imagine you are making an online payment:

1 You click "Proceed to Payment".
2 The page takes a few seconds to process.
3 You wait until "Payment Successful" appears.

How Tosca Handles This:

Step Action Mode Condition

Click "Proceed to Payment" Input Click

 Step Action Mode Condition

Wait for "Payment Successful" WaitOn Appears

Tosca will pause until the message appears and then continue. This helps avoid
errors caused by pages loading slowly!

Buffer
A Buffer in Tosca is used to store a value during test execution so it can be used later
in the same or another test step. Instead of manually entering or remembering values,
Tosca automatically saves and reuses them.

Ex :We can store innertext of any control to buffer and we can call that buffer
whenever we need to verify innertext of any control.

2 Types of Buffer In Tosca:

A. Static Buffer:
Syntax: {B[Buffername]}
B. Dynamic Buffer:
Syntax: {XB[Buffername]}

How Buffer Works in Tosca?

1. Capture a Value → Tosca saves a value (like Order ID, Transaction ID,
or PNR Number).
2. Store it Temporarily → The value is stored for later use.
3. Reuse the Value → The stored value can be used in another test step.

Real-Time Uses of Buffer:

E-commerce (Amazon, Flipkart) – Save Order ID for tracking.

Banking (HDFC, ICICI) – Save Transaction ID after payment.
Flight Booking (Indigo, MakeMyTrip) – Save PNR Number for ticket status.
Job Portals (Naukri, LinkedIn) – Save Application ID for status tracking.
Flight Booking

Imagine you are booking a flight ticket on Indigo Airlines:

1 You fill in passenger details and make a payment.
2 The website generates a PNR Number (e.g., PNR98765).
3 Tosca saves this PNR number using a Buffer.
4 Later, Tosca uses this saved number to check flight status.

Test Steps in Tosca:

Step Action

Book a flight ticket Input

Capture PNR Number Buffer

Check flight status using PNR Reuse Buffer

Why use Buffer?

• No need to type the PNR number manually.

• The same value can be used later in other tests.
• Saves time and reduces errors.

Ordering on Amazon

1 You order a mobile phone on Amazon.

2 After placing the order, an Order ID (e.g., ORD12345) is generated.
3 Instead of writing it down, Tosca captures and stores this Order ID using
Buffer.
4 Later, when you want to track your order, Tosca automatically retrieves the
stored Order ID and enters it.

Test Case Example in Tosca

Step Action Mode Value

Place an order on Amazon Input Click "Buy Now"
Capture Order ID Buffer Save generated Order ID
Track Order Input Use saved Order ID

Why Use Buffer?

 • Saves time (no need to manually enter values).
• Avoids errors (ensures correct values are used).
• Makes automation flexible (works even if values change).

The package Buffer Operations contains the following Modules:

▪ TC Set Buffer
▪ TC Name To Buffer
▪ TC Partial Buffer
▪ TC Delete Buffer

TC Set Buffer
This Module is used to create and verify buffer values.
The Module TC Set Buffer contains the following attributes:
ModuleAttribute Description
Buffer Name of the buffer.
Value Value to be written to the buffer or value to be verified with the buffer's content.

TC Name To Buffer

This Module writes the name of the TestCase using the Module to the specified buffer.
The Module contains the following ModuleAttribute:
ModuleAttribute Description
Buffer Specifies the name of the buffer, which should be used to save the TestCase name. If the sp
buffer name does not exist yet, it will be newly created.

TC Partial Buffer
This Module allows parts of a value to be either written to a buffer variable or to be verified.
The Module Partial Buffer contains the following ModuleAttributes:
ModuleAttribute Description
Buffer Name of the buffer.
Value Value to be either written to the buffer or to be verified.
Start Index of the character to be used as starting point for the value to be either copied to the buff
verified.
End Index of the character to be used as endpoint for the value to be either copied to the buffer or
Last Number of characters to be either copied to the buffer or verified, starting from the end. If this
specified, the ModuleAttributes Start and End are ignored.

TC Delete Buffer

This Module deletes the content of all existing buffers from the [Link] file. All existing
buffer variables are maintained.
The TestStep is executed without any specified values or ActionModes.

Constraint Action
It helps Tosca find the correct element when there are many similar
elements on a webpage or application. Instead of selecting all similar elements,
it filters and picks only one specific element based on given conditions.

How Constraint Works

Step 1: Tosca finds many similar elements (for example, multiple "Buy Now"
buttons on a shopping website).

Step 2: You give a condition to help Tosca find the correct one (for example, select
the button next to "iPhone 15").

Step 3: If there are still multiple matches, you tell Tosca exactly which one to
choose using #<n> (for example, #2 to pick the second "Buy Now" button).

Real-Time Example:
 Scenario: You are testing an e-commerce website where multiple "Buy Now"
buttons exist for different products.
You want Tosca to click the Buy Now button for "Laptop."
Instead of clicking all buttons, you apply a constraint to select the button
next to "Laptop."
If there are two laptops listed, you can use #2 to select the second one.

Why Use Constraint?

✔ Ensures Tosca clicks the correct element

✔ Avoids errors when multiple similar elements exist
✔ Helps in working with tables, lists, or repeating elements. This helps Tosca
focus on the right element instead of selecting all similar one

Constraint Index

Constraint Index is used to find a specific row in a table based on conditions instead of using
row numbers. It helps Tosca locate the correct row without using fixed row numbers, which makes the
test case more flexible and stable.

✅ Example:

If I want to click a button for the row where Patient ID is 1056, I use Constraint Index.

Tosca will search the table, find the row with Patient ID = 1056, and click the button in that
row.

When or in which scenario do we use it?

We use Constraint Index when:

• The table data keeps changing (rows are not always in the same position).
• You want to perform an action (like click, verify, or input) on a row that matches a
specific value.
• For example:
o In a patient list, click "View" for the patient with ID = 1056
o In an order table, verify status for the order with Order ID = 9999
o In an employee table, update data for Employee Name = "Ravi"
✅ Why do we use it?

Because table rows keep changing, and we can't trust row numbers. So we tell Tosca to find the
row based on value.

Summary:

• Constraint Index = Find row by condition, not by number

• Used in: Tables with changing rows, Table rows change, and you want to act on a specific
row using conditions
• Why: Makes test cases flexible and reliab

How to handle multiple tabs in browsers?

In the Module we need to add a configuration parameter with the property name as
“ConstraintIndex” and with the value as tab number as below:

Ex: ConstraintIndex =1(For tab1)

Waits in Tosca – Simple Explanation

Definition:
Waits in Tosca make sure that the test waits until a certain condition is met
before continuing. This helps to avoid errors caused by slow-loading pages or
elements that take time to appear.

Real-Time Usage Example:

Scenario: You are testing an online payment process. After clicking "Pay
Now," the system takes a few seconds to show the "Payment Successful"
message.

Without Waits: Tosca moves to the next step immediately and may fail
because the success message is not yet visible.

With Waits: Tosca waits until the "Payment Successful" message appears
before proceeding.

This ensures the test runs smoothly, even if there are delays.
Business Parameters
A Business Parameter is a dynamic value used in Reusable Test Step Blocks
(RTSB) to make test cases flexible. Instead of hardcoding values, you can pass
different values each time you run the test.

"Business Parameters in Tosca allow us to run the same test case with different
values without modifying the test steps. For example, in an e-commerce checkout
process, instead of creating multiple test cases for different products and
payment methods, we define parameters like {Product_Name} and
{Payment_Method}. This way, we can test various scenarios by just changing
these values, making automation more efficient and reusable."

Why Use Business Parameters in These Scenarios?

Reduces Test Case Duplication: One test case can be used for multiple
scenarios.
Saves Time & Effort: No need to manually edit values for different test
runs.
Increases Test Coverage: Ensures a wide range of test scenarios are
covered efficiently.

Reusable Test Step Block

"RTB in Tosca is like a reusable template for test steps. Instead of writing the
same steps for login, checkout, or search in every test case, we create a
reusable test block once and use it everywhere. This saves time, reduces
errors, and makes maintenance easy. For example, a Login RTB can be used in
all test cases that require login, ensuring consistency and reusability."

Summary of RTB in Tosca

 RTB = Reusable Test Steps → Avoids Repetition
Used in Login, Checkout, Flight Search, Banking Apps, etc.
Saves Time, Improves Efficiency, Reduces Maintenance Effort
Makes Test Cases More Dynamic and Scalable

Easy Summary:

RTSB (Reusable Test Steps) → Saves time by reusing test steps instead of
writing them again.
Business Parameters → Make tests flexible by allowing different values
without changing test steps.
Where We Use? → Login tests, checkout processes, and testing with
different data.

Summary for Interview Preparation

RTBs: Avoid test step repetition, making tests reusable and easy to
maintain.
Business Parameters: Allow dynamic values, making tests flexible and
data-driven.
Where Used? Login, Search, Payment, Order Verification, and any
frequently used test steps.
Key Benefit: Saves time, reduces errors, and improves test automation
efficiency.

💡 Interview Tip:
"RTBs and Business Parameters make Tosca test automation efficient. In real
projects, we use RTBs for common tasks like login and payment, while Business
Parameters allow different inputs, making tests dynamic and reusable.

Test Configuration Parameters (TCP) & Business Parameters

Or
Interview Answer

"TCP is a global setting that applies to multiple test cases, while

Business Parameters are dynamic values used inside Reusable Test
Step Blocks (RTSB) to run the same test with different inputs. For
example, I would use TCP to set the browser for all test cases, but a
Business Parameter to test login with different usernames."

Details about test Case Design(TCD)

Introduction to Test Cases Design TCD
1. Use TestSheets to create all combinations of possible TestCases that are
required to ensure full Test Coverage.
2. Work with Classes to reduce the number of TestCases needed.
3. Use Instances to define concrete values for specific TestSheets,
TestCaseDesign Attributes or TestCase-Design Classes.
 4. Create TestCases and TestCase Templates.
5. Assign TestSheets to TestCase Templates to instantiate TestCases for
execution.
6. Manage test data.

Key Concepts of TCD

1. TestSheets → Store Test Case Data

• Think of TestSheets as Excel sheets storing different test case

combinations.
• Example: A TestSheet for login tests may have different usernames and
passwords.

2. Classes → Reduce the Number of Test Cases

• Classes help group related test cases, so you don’t create unnecessary
duplicates.
• Example: Instead of testing every product separately, create a Product
Class covering all product types.

3. Instances → Define Specific Test Values

• Instances hold actual values for test cases.

• Example: A "Payment Method" class may have Credit Card, UPI, and
Net Banking as instances.

4. TestCase Templates → Automate Test Case Generation

• Instead of writing test cases manually, templates generate them

dynamically based on data.
• Example: A Login Template can create multiple test cases using
different username-password combinations.

5. Assign TestSheets to Templates → Generate Test Cases

• Connect TestSheets to Templates to automatically generate all possible

test cases.
• Example: A login TestSheet with 5 users + 3 passwords → Generates 15
test cases instantly.

6. Manage Test Data Efficiently

• TCD keeps test data structured, reusable, and easy to update.

 • Example: If the login flow changes, update the TestSheet once instead of
modifying multiple test cases.

What is DEX in Tosca?

DEX (Distributed Execution) allows you to run multiple test cases on different
machines at the same time. This helps speed up test execution and improve
efficiency.

How Does DEX Work?

Step 1: Tosca divides test cases among multiple machines.

Step 2: Each machine runs its assigned test cases in parallel.
Step 3: Results are collected in a central location (Tosca Execution
Monitor).

Why Use DEX? (Benefits)

Faster Testing → Runs tests on multiple machines at once.

Better Resource Utilization → Uses multiple computers instead of
overloading one.
Supports Continuous Testing → Ideal for CI/CD pipelines.

🔹 Where is DEX Used? (Real-Time Example)

Scenario: Testing an E-commerce Website

• Suppose you have 500 test cases for different features (Login, Checkout,
Payment).
• Running all 500 test cases on one machine takes 5 hours.
• With 5 machines using DEX, the tests finish in 1 hour instead!
 How to Use DEX in Tosca?

1⃣ Set up DEX machines (install Tosca Distributed Execution Service).

2⃣ Configure Agents (machines that will execute the tests).
3⃣ Assign Test Cases to different agents.
4️⃣ Run the tests → DEX distributes them automatically.
5⃣ View results in Tosca Execution Monitor.

Interview Tip

"DEX in Tosca helps execute test cases faster by running them on multiple
machines simultaneously. It improves test execution speed, resource utilization,
and supports automation in CI/CD pipelines."

TestSheets
TestSheets are the basic framework in TCD. It can be used to
organize the Test data to have a logical structure.

TestSheets can be used:

1. Use to build Data oriented Testcases

2. Test Case design steps to build process oriented Testcases

TCD – Using Test Sheets

Work With Attributes:

Attributes are the various characteristics of your application, or
representations of your business objects. You can use Attributes to
map business objects that are necessary for your TestCases.

Create an Attribute:

You can create attributes within a TestSheet to help structure your

TestCases appropriately. To create an Attribute, follow the steps
below:

1. Right-click the object for which you want to create an

Attribute from the mini toolbar.
2. Rename the Attribute as desired. Attributes must have unique
names.

TCD - Working with Instances

TestCase - Design Instances are possible variants of attributes.

Create an Attribute:

You can create an Instance for a TestSheet, a TestCase - Design

Attribute or a TestCase – Design Class. You can create Instances in
different ways according to your requirements and preferences:

1. Manually
2. By assigning values
3. From Module Attributes.
Create an Instance - Manually

To create an Instance, follow the steps below:

1. Right-click on the object you want for to create an Instance

for.
2. Select Create Instance from the mini toolbar.

TCD - Generate Instances

Different Ways of Generating Instances:
You can choose different combinatorial methods to meet your specific project
needs. Depending on the granularity of your requirements, you may want a
greater or lesser number of possible combinations from which to build your
TestCases.

The following combinatorial methods are available:

1. All Combinations
2. Orthogonal
3. Pairwise
4. Liner Expansion

Error Handling

At some point of steps, test case got failed and remaining execution is not
[Link] we can handle this error and how I can execute these steps,
these concepts we called as error handling.

Types:

[Link] Failure :If any verification point is fails, it means if Expected

value and Actual value doesn’t match then Verification will be failed.

[Link] Failure / User Abort: Abort of the test execution by the user.
[Link] Box Failure : During the execution if at all we notice any unexpected
popups and if that stops the execution then we call it is Dialog failure.

Recovery Scenario & CleanUp Scenario

Recovery Scenario is nothing but during execution time unexpected error is
coming , to overcome that problem we can use the Recovery Scenario. But
when Recovery Scenario also failure then we can go up for the CleanUp
Scenario.

Recovery Scenario: It is used to handle unexpected errors that occur

during test execution. If an error comes up, Tosca tries to fix it and continue
the test.

CleanUp Scenario: If the Recovery Scenario also fails, the CleanUp Scenario
ensures the system returns to a stable state before continuing or stopping the
test.

Cardinality

Definition:

• Cardinality in Tosca defines how many times an element appears on a

screen and how Tosca should handle it.

2. Types of Cardinality:

• 1:1 (Single Occurrence) → Element appears only once (e.g., Login

button).
• 1:n (Multiple Occurrences) → Element appears multiple times (e.g.,
multiple rows in a table).
• 0:n (Dynamic Occurrence) → Element may or may not appear (e.g.,
error message).

3. Why is Cardinality Important?

• Helps Tosca identify and interact with UI elements correctly.

 • Avoids test failures when elements are missing or appear multiple times.

4. Example Scenario:

• In an e-commerce website, multiple "Add to Cart" buttons exist.

• If Cardinality = 1, Tosca selects only the first button.
• If Cardinality = 1:n, Tosca interacts with all buttons dynamically.

5. How to Set Cardinality in Tosca?

• Go to Tosca Object Repository (XScan) → Select the element → Adjust

Cardinality Property.

Test Events
Test Events in Tosca are used to perform actions before, during, or after a
test case runs. They help in handling special situations like setup, cleanup, or
error handling during test execution.

Why Use Test Events?

• To initialize test data before execution.

• To clean up data after execution.
• To handle errors and take necessary actions.

Types of Test Events:

1. Pre-Execution Events – Run before a test case starts (e.g., opening a

database connection).
2. Execution Events – Run during test execution (e.g., logging test steps).
3. Post-Execution Events – Run after a test case completes (e.g., closing
applications, clearing cache).

Example Scenario:

• Suppose you are testing a healthcare application (AbbVie project)

where:
o Before execution: You need to log in to the application.
o During execution: You need to capture screenshots for failed test
steps.
o After execution: You need to close the browser and generate a
report.
• You can define Test Events to handle all these actions automatically.
Where to Configure Test Events?

1. Go to ExecutionLists in Tosca Commander.

2. Right-click on the ExecutionList → Select Properties.
3. Find Test Events → Add the required event.
4. Save and run the execution.

How do you create Business Parameters?

Basic syntax of date and time

Syntax of dynamic buffer

Static wait vs dynamic wait

1. Static Wait – Wait for fixed time

• Toscawill wait for the time you tell it to wait, even if the screen is already
ready.
 • You are telling Tosca: “Wait for 5 seconds no matter what happens.”

Example:

You click a button, and Tosca waits 5 seconds before doing the next step —
even if the page loads in 2 seconds.

Looks like:

Wait = 5 (fixed time)

Problem: It wastes time if the app loads quickly.

2. Dynamic Wait – Wait only until something appears

• Tosca will keep checking if something (like a button or message) is

visible.
• As soon as it finds it, Tosca moves to the next step. It doesn’t wait longer
than needed.

Example:

You click “Login” and wait for the dashboard to appear.

Tosca keeps checking for the dashboard.

• If it appears in 2 seconds, Tosca moves ahead.

• If it takes 6 seconds, Tosca waits for that.

Much smarter and faster than static wait.