This Tutorial Explains how to Create and Execute Manual as well as Automation Test Cases in TOSCA, along with the Requirements, Modules & Reports in TOSCA.:
We explored all about Creating And Managing Workspaces in TOSCA in our previous tutorial of this Easy TOSCA Guide For Beginners.
This article discusses how to start with the TOSCA Test Automation Tool to create and execute test cases. Also with this article, one can learn the report generation and the ‘Search’ options available in TOSCA.
This article is for the new learners of this tool. They will get the trigger to start writing test cases in TOSCA. Here, we will explain all the steps in detail along with screenshots.
Table of Contents:
Test Cases In TOSCA
You can create and execute manual as well as automation test cases in TOSCA. Refer to the below image for a brief description regarding 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 automation. Those steps are: Create the workspace, start with TOSCA Commander, and create the requirements.
After defining the requirements, you may go with either manual test case or automation test case option.
For the manual test case, you will need to go with the ‘Test Case Design section to create the test scenarios. For an automation test case, you will have to create the modules for web pages. Based on this let us define the learning path.
Learning Path:
- First, complete the common steps for the test case creation.
- Understand the ‘Requirements’ section.
- Create and execute the manual test case.
- Focus on the ‘Modules’ section.
- Learn how to start with the 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) For creating 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, 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 here is, 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 the data administration. But it is simple since all the data of a project are saved to one central location, the ‘Common Repository’.
#2) Start With TOSCA Commander
Once the workspace is ready, you will be automatically navigated inside the TOSCA Commander, and in your workspace area. You will see all the sections there like, Test Cases, Modules, Requirements, Test Case Design, Execution, etc.
#3) Create The Requirements
Let us create some requirements. The discussion will take the sample flight reservation application website where we will create the requirements for the Login functionality in the application.
First, you will have to create one parent requirement as ‘Login’ and two child requirements to it as ‘User Name’ and ‘Password’. The first step is, 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 generally called as 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. Write 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 the ‘Login’ and select the requirement icon as ‘Create Requirement’. Give the name as ‘UserName’.
#3) Same way, create one more child requirement to ‘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 properties columns from the details. To do this, right-click on the space, generally 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 having 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 highest damage. i.e. if this requirement is failed, then it will damage the project badly.
#3) Weight: Formula to calculate weight is
Weight = 2^Damage class * 2^ Frequency class
Note: X^Y means X to the power of Y.
For Example: Suppose for any requirement, frequency class value is 4, and 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 create. To see this, test cases created must be linked with the respective requirements.
As you can see in the image below, yet there is no test case created or link to the requirement so it is showing in white color 100, it means 100% coverage is remaining. You have not created any single test case for the given requirement. There are two colors indication, 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 in the 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 Password as requirements and the weight associated with them is 8 and 16 respectively. Then the total weight of this requirement set is 8+16 = 24. Now relative weight for UserName requirement is, the calculation will be 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:
Create And Execute Manual Test Case
The requirement set is already there with you for the Login functionality of 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 as ‘ManualTest’.
For test case design, you will have to add different data values and create the combinations of them. Let us do it step by step.
Step #2: Right-click on the ManualTest folder and create ‘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’.
Note: Here, attribute means the web elements. You have to 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 ‘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 as ‘Create manual test step value’.
Add the value as ‘mercury’.
Step #10: use the same way 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 as below:
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 as ‘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 then 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 the 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 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 all objects you want to select and work upon. You should select those objects and save that scan information. This will automatically create the module in TOSCA ‘Modules’ section.
It is as good as you are creating the object repository for required objects for 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 repetitively while testing. For example, open the application URL inside the browser, closing 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 get change as per the test case requirement.
So with these objects, there are few ready modules available in TOSCA which 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, you have to deal with three objects for login, first is ‘Username’, then ‘Password’, and ‘SignIn’ button.
Step #2: To capture these objects and create the module you have to scan the webpage. Go with TOSCA Commander ‘Modules’ section. Create your folder as ‘NewtoursApp’ inside the root folder.
Step #3: Right-click on this folder and select the option as ‘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, then 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 application inside that 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 below step.
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 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 below:
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 click and selecting the option as ‘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 the 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.
Search Function In Tosca
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.
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” function 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!!
PREV Tutorial | FIRST Tutorial