How To Create & Execute Test Cases In Tosca Testing Tool?

This tutorial explains how to create and execute manual as well as automation test cases in TOSCA, along with the requirements, modules, and reports in TOSCA.

In the previous tutorial of this Easy TOSCA Guide for Beginners, we explored how to create and manage workspaces in Tricentis Tosca in detail.

In Tricentis Tosca, the creation and management of test cases are at the heart of automation. In this section, you will learn about test cases in Tricentis Tosca, steps involved in creating test cases, the Requirements and Modules sections, manual and automation test cases, reporting, and search.

Test Cases In TOSCA

You can create and execute manual and automation test cases in TOSCA. Refer to the image below for a brief description of the different steps you have to perform for the test cases.

From the image, you can understand that there are three common steps for the test case, whether it is manual or automated. Those steps are: Create the workspace, start with TOSCA Commander, and create the requirements.

After defining the requirements, you may go with either a manual test case or an automation test case option.

For the manual test case, you will need to go to the ‘Test Case Design section to create the test scenarios. For an automation test case, create the modules for web pages. Based on this, let us define the learning path.

Learning Path:

1. First, complete the common steps for test case creation.
2. Understand the ‘Requirements’ section.
3. Create and execute the manual test cases.
4. Focus on the ‘Modules’ section.
5. Learn how to start with an automation test case.

Common Steps For Test Case Creation

#1) Create The Workspace

a) Start TOSCA Commander from the Windows Start menu: Start-> All Programs-> Tricentis-> TOSCA ->TOSCA Commander. You will get the start screen.

b) To create the workspace, select the Project menu ->New option. This will open the ‘Create new workspace’ window, as shown below. Enter the name of your workspace into the ‘Select name for new workspace’ field. For example, here we have entered the name as “TOSCA_Training”. Now click on the ‘OK’ button.

You will get the success message. So, currently, you have created a single-user workspace as “TOSCA_Training”.

The important point to focus on here is that there are two types of workspaces you can create in TOSCA. In a ‘Single User Workspace’, only one person has access to it. It is like a single-user single-workspace.

Another one is the ‘Multiuser Workspace’, which needs data administration. But it is simple since all the data of a project is saved to one central location, the ‘Common Repository’.

#2) Start With TOSCA Commander

Once the workspace is ready, you will be automatically navigated inside TOSCA Commander and into your workspace area. You will see all the sections there: Test Cases, Modules, Requirements, Test Case Design, Execution, etc.

#3) Create The Requirements

Let us create some requirements. The discussion will take place on the sample flight reservation application website, where we will create the requirements for the Login functionality in the application.

First, create one parent requirement called ‘Login’ and two child requirements under it: ‘User Name’ and ‘Password’. The first step is to go to the ‘Requirements’ section. You will see one folder already available there. This type of folder you will get in every section inside TOSCA Commander. Such base folders are called root folders.

Create your folder inside this root folder. For this, right-click on the root folder name ‘Requirements’ and select the folder icon there as ‘create folder’. Give the name of your folder as ‘ManualTest’.

To create the requirements, follow the steps as given below:

#1) Now create the requirement set inside this folder. Click on ‘Manual Test’ and select the requirement set icon as ‘Create requirement set’. Give the name as ‘Login’. This is the parent requirement.

#2) For creating the child requirements, right-click on ‘Login’ and select the requirement icon as ‘Create Requirement’. Give the name as ‘UserName’.

#3) Same way, create one more child requirement for ‘Login’ and name it as ‘Password’ as shown in the image below:

Thus, we have completed the first step in ‘Learning Path’, i.e., successfully done with the common steps for the test case.

Let us go ahead with the next step.

Understand the ‘Requirements’ Section

A requirement is a functional or non-functional measure that is relevant to the test project. Each requirement must be assigned to a particular requirement set. When you create any requirement, certain properties are associated with it. You can see those properties in the ‘Details’ tab on the right-side pane.

You can add or remove property columns from the details. To do this, right-click on the space in the last property column, and you will get the option as ‘Column Chooser’.

Select this option, and you can see on the right-hand corner the list of columns from which you may choose more properties to add(Refer to the image below). Those will be added after the last column.

Refer to the image below.

Let us have more focus on some important properties of the requirements.

#1) Frequency Class: This represents the probable frequency of an event. The value between 0 and 10 is allowed. 10 stands for the highest frequency. i.e., the requirement of having a more frequency class is getting used more frequently in the project.

#2) Damage Class: This represents the probable damage value of an event. It is allowed to set the values between 0 and 10. 10 stands for the most serious damage. i.e., if this requirement is failed, then it will damage the project badly.

#3) Weight: The formula to calculate weight is

Weight = 2^Damage class * 2^ Frequency class

For clarity: X^Y indicates X elevated to the power of Y.

For example, suppose for any requirement, the frequency class value is 4, and the damage class value is 3. Then the weight calculated for that requirement is (2^3) * (2^4) = 128.

#4) Contribution (%): This represents the value in percentage that each requirement contributes to the requirement set it belongs to. The calculation is based on the weight of each requirement. A particular requirement may divide its weight into sub-requirements.

#5) Coverage Specified (%): This indicates how many test cases are created and how many are yet to be created. To see this, the test cases created must be linked with the respective requirements.

As you can see in the image below, there is no test case created or a link to the requirement, so it is showing in white color 100, which means 100% coverage is remaining. You have not created a single test case for the requirement.

There are two color indications: yellow means that much coverage is done, and white means that much work is still pending.

#6) Execution State (%): This will indicate the execution state as a percentage of the linked test cases. How many test cases are executed, how many are pass, and how many failed?

#7) Relative weight: It is calculated as the percentage of a requirement weight relative to the total weight of the requirement set.

For example, here, we have a UserName and a Password as requirements, and the weights associated with them are 8 and 16, respectively. Then the total weight of this requirement set is 8+16 = 24. Now, the relative weight for the UserName requirement is calculated out of 24. UserName weight is 8, then out of 100, how much?

(8*100)/24 = 33.33 %

For Password it is: (16*100)/24 = 66.66%

This will end up with the second step in ‘Learning Path’, i.e., successfully done with the ‘Requirements’ section. Let us go ahead with the next step:

Creating and Executing Test Cases

The requirement set is already there with you for the Login functionality of the Mercury Tours application. Let us directly create the manual test for the same. To design the test scenarios for manual testing, go with the section ‘Test Case Design’.

Step #1: In the ‘Test Case Design’ section, create your folder inside the root folder and give the name ‘ManualTest’.

For test case design, add different data values and create combinations of them. Let us do it step by step.

Step #2: Right-click on the ManualTest folder and create a ‘Test Sheet’ and give it the name as ‘LoginData’.

Step #3: Right-click on the ‘LoginData’ sheet and create two attributes one by one as ‘UserName’ and ‘Password’.

Here, attribute means the web elements. Create a combination of test data values for these attributes as valid data, invalid data, etc.

Step #4: Right-click on the attribute ‘UserName’ and select the option to create the instance.

For your test case, let us create two instances, ‘ValidData’ and ‘InvalidData’, as shown below.

Step #5: It is observed that the icons for both valid and invalid instances are the same. It means both belong to the same category, which is not correct. One should reflect as valid and others should reflect as invalid.

For valid data, the icon is correct, but for an invalid data value, you have to correct it. There is a ‘Properties’ tab on the right side. Click on that and open the properties of the instances. Select the option ‘character’ and make it ‘invalid’ for the ‘InvalidData’ instance. The icon will change.

Step #6: In the same way, create valid and invalid instances for the ‘Password’ attribute as well.

Step #7: Get the combination of data values and create the test scenarios. For this, go to the option ‘Complete Instances’ in the menu bar and select the option as ‘Pairwise’. You will get the combination of valid and invalid data and 4 test scenarios based on the same.

You may choose which scenarios you want to consider for creating the test cases.

Step #8: Write the actual test case using the ‘Test Cases’ section. Inside the ‘Test Cases’ section, create your folder ‘ManualTest’ in the root folder. Right-click on the ‘ManualTest’ folder and create a test case. Give the name ‘ValidLogin’.

Once the test case is created, you have to add the steps for testing. Let us add it.

Step #9: Right-click on the test case created in the folder ‘ValidLogin’ and create the manual test step.

Using this option, you will be able to add a new step manually in your test case. Give the name for the test step as shown below.

Currently, the step is empty without any value. You have to add the value for the step. See on the right-side pane, select the step and right-click and choose the option ‘Create manual test step value’.

Add the value as ‘mercury’.

Step #10: Use the same method to create the steps for entering the password and click on the sign-in button. Add the respective test values as well. So the overall test case will look like this:

Step #11: Run the test case. Since you are currently working with a manual test case, first, open the application inside the browser manually. Then go to the test case name ‘ValidLogin’ and right-click on the same. Select the option ‘Run in ScratchBook’.

Run the test case manually. Enter the data as suggested in the test steps and pass or fail the test step manually based on the actual working in the application.

Refer to the image below. After every step, you have to close the window (marked in red circle), and it will automatically open the next step. Once all the steps are over, click on the option ‘Finish TestCase Execution’. This will end the execution of the test case.

Now observe the result as:

This is how you can create a manual test case and execute it in TOSCA. Now, we will see the next part in the learning path.

Focus On ‘Modules’ Section

Modules in Tosca Commander contain technical information that is used to steer test objects. While creating the automation test case, create a module in TOSCA Commander for each function of the object to be tested.

In Tosca, there are two types of Modules available: Classic Modules and XModules. Classic Modules use classic engines for steering test objects. Xmodules use XEngines, which are based on the Tosca TBox framework. This applies to both GUI and non-GUI.

The classic module is represented by the symbol:

XModule is represented by the symbol:

TOSCA is a model-based test automation tool. Every tool has its own way to identify the objects in the application. Like in Selenium, you have locator builders; in UFT, it creates the object repository. Similarly, in TOSCA, the tool will scan the page and capture all the object properties of web objects on the page.

You will have a choice of which objects you want to select and work on. You should select those objects and save the scan information. This will automatically create the module in TOSCA ‘Modules’ section.

It is as good as you are creating the object repository for the required objects on a page. These modules will be further used in the ‘Test Cases’ section to create the automation test steps.

There are certain common functionalities that you may need repeatedly while testing. For example, open the application URL inside the browser, close the application, read-write data from Excel, etc.

For such common functionalities, the objects like URL, Excel sheet objects, browser, etc. are the same always, only their values may change as per the test case requirement.

So with these objects, there are a few ready modules available in TOSCA that you can use directly to create the test steps. Those are available in the set called ‘standard.tce’. When you install TOSCA, this set of default modules will automatically come along with it.

Few advanced modules are available with another set called ‘Aidpack’. This will be available on the TOSCA support portal. You can download it from there.

Let us understand how to work with the ‘Modules’ section while learning the creation of an automation test case. Will move on now with the next step in the learning path.

How To Start With Automation Test Case?

Already you are ready with the requirements for ‘Log in’ function in the new tours demo application. Also, you have created the manual test case for the same. Let us create an automation test case for the same scenario.

Step #1: Open the browser and open the application with URL http://newtours.demoaut.com/. Here, deal with three objects for login: ‘Username’, then ‘Password’, and ‘SignIn’ button.

Step #2: To capture these objects and create the module, you have to scan the webpage. Go with the TOSCA Commander ‘Modules’ section. Create your folder as ‘NewtoursApp’ inside the root folder.

Step #3: Right-click on this folder and select the option ‘Scan application’ and further select ‘Desktop’.

Step #4: Select your application screen and click on the ‘Start’ option.

Step #5: The scanner will start, and it will capture all the objects from the web page. Once done, it will display the list of objects along with the properties. Scroll up or down in the list and select your required objects along with the parent.

While selecting if the orange band is shown at the bottom, you will have to select more properties from the right-hand section for that object to get the unit identity.

When the object has a unique identity, it will show a green band at the bottom. Just click on the ‘Save’ button once you have selected all the required objects.

Step #6: You will get the module created inside your folder.

Step #7: Go to the ‘Test Cases’ section and create one more folder inside the root folder and give the name as ‘AutomationTest’. Right-click on this and create the test case as ‘ValidLogin’.

Now you are working with automation, so the steps of opening the browser and starting the application inside it should also happen automatically. To achieve this, use readily available modules from the ‘standard’ set of modules.

Step #8: In TOSCA Commander, select the root folder in the ‘Modules’ section. Then go to the Home menu option and click on the ‘Import Subset’ icon. Browse and select the standard.tce file and say open. It will get added inside your root folder in the module section. This contains all the generic modules.

Now you can start creating your first automation test case. The first step is to open the browser for which you have to set the test configuration parameter.

Then open the application URL inside that browser for which you have the readymade modules available in ’standard’ modules. Let us first set the test configuration parameter. Follow the steps below.

Step #9: Right-click on the name of the test case ‘ValidLogin’ and select the option ‘Create Test Configuration Parameter’.

Add the parameter as ‘Browser’ and value as ‘InternetExplorer’. (Note: Do not add any space while writing the name of the browser, and keep the first letters in caps).

Refer to the image below:

Step #10: Open the application URL in the browser. For this, go to ‘Modules’ section. Select the module from Standard modules-> TBox XEngines-> Html-> OpenUrl.

Drag and drop this module on the name of the test case ‘ValidLogin’ in the ‘TestCases’ section. This will automatically create the first step of your test. Then enter the value of the URL in the step. You will get your test step created as follows:

Step #11: For the next step, i.e., enter the user name, enter the password, and click on the sign-in button, you have to drag and drop the module to the test case name ‘ValidLogin’.

This is the same module that you have created by scanning the webpage prior. This will create the next step in the test case automatically with all the required objects and you need to just enter the values for those objects as shown in the image below.

Step #12: Now you will get your overall automation test case created as shown below.

Step #13: Run the test case automatically by right-clicking and selecting the option ‘Run in ScratchBook’. You will see the time duration as well while executing the test case.

The final run result you will get is as shown below:

How To Create Reports In TOSCA?

TOSCA reporting will allow you to generate reports on the following object types:

• Modules
• TestCases
• ExecutionLists
• ExecutionLogs
• Requirements
• Requirement sets
• Project root

You can print your current view of Tosca Commander by clicking on the print icon in any of the sections.

To create the customized report for your automation test case, you have to download the file ‘Tosca_10.3_Documentation.zip’ from the Tricentis Support Portal. This file contains the subset ‘Documentation_TestCase_Report.tce’, which will help you create the customized report.

How to Use the Search Function

TOSCA Commander provides two different search functions: Simple Search and TQL Search (TQL = Tosca Query Language). You can go to any section, like Test cases, Modules, Requirements, etc. In the ‘Home’ menu, you have this search option as shown in the figure below.

When you click on this option, you will get those two categories for search:

(i) Simple search: This is a normal search option. You may enter any world or input for the search operation, say the name of a Test Case, or the value of a TestStepValue.

The settings option will indicate which object properties (name, description, properties, and values) are included in the search. You may also include how the search should be performed inside these settings. Below are the options:

(ii) TQL Search: The TQL search (Tosca Query Language) is part of the simple search and is activated with the button TQL Search. It is context-dependent. This means that the starting point affects the search to be carried out.

TQL search queries tend to consist of many subexpressions. Tosca Commander displays these expressions in a multiline field. TQL search queries allow searching for all objects, object relations, and object properties within a project.

This enables searching for all TestCases that are not assigned to any ExecutionLists. TQL queries can be saved to virtual folders by clicking on the button

The virtual folder is created beneath the folder from which the query has been started. The button is enabled only after the query has been performed via the Search button.

How to Build Valid Search Queries

Example:

Suppose you want to search for all SUBPARTS of the TestCases folder. Then select the TestCases folder and click on Search in the context menu. The search function will use the TestCases folder as the starting point for the query. Next, click on TQL search in the search dialog box. Enter the query as “ ->SUBPARTS”

Syntax: query ::= {arrowOperator [returnToken] searchExpression}

Meaning: Since only one level below the starting point should be searched, arrow Operator must be replaced by ‘->’. The ‘ ‘ are not written in this entry. The return Token is optional and is thus not required for this search. SearchExpression is replaced by (assocName | aggregation) [colonToken type] [leftSquareBracket logicalExpression rightSquareBracket].

Since we search for SUBPARTS. The actual query will be:

query ::= ‘->’ ‘SUBPARTS’

Then click on the ‘Search’ button.

You will get the result as:

This is how you can make use of ‘Search’ in TOSCA.

Conclusion

In this tutorial, we have covered the detailed steps regarding how to start with the TOSCA Automation Tool. This is enough information to get started with writing the requirements, creating the modules, and working with the manual and automation test cases in TOSCA.

Also, we have focused on the “Reports” and “Search” functions in TOSCA. This will help you to create the reports and find the required ‘Search’ items in TOSCA.

Hope you enjoyed this series of TOSCA tutorials!!

For more Test cases-related guides, you can explore our range of tutorials below:

• Writing Test Cases From SRS Document
• How to Write Test Cases in Software Testing (Examples)
• Test Case Templates with free Download and Examples
• Writing Test Cases or Testing Without Requirement Documents
• How to Write Test Cases For a Login Page (Sample Scenarios)

PREV Tutorial | FIRST Tutorial