Hi, I am K. Mondal, I am associated with a leading organization. I am having 12+ years of working experience across domains e.g., application development, automation testing, IT Consultant. I am very much interested in learning different technologies. I am here to fulfill my aspiration and currently contributing as an Author and Website Developer both in LambdaGeeks.
Lets Connect through LinkedIn-
Testing is now an important phase of the software development life cycle to secure the product’s quality. Also, without having testing, we can’t ensure the fulfillment of all the requirements. Here automation is playing an essential role in the testing cycle to reduce the efforts and time. In the market, there are multiple testing tools available to automate the testing process. The most used automation testing tool is UFT.
In this UFT Tutorial article, we are going to learn about the different types of UFT Parameterization such as UFT Environment Variables, UFT DataTable Parameters, UFT Action Parameters, Random Number Parameters with practical implementation.
UFT Parameterization is an approach to feed test data into the test steps through parameter during the run time. It will help us to increase the reusability of test case modules to use in different data criteria. UFT Parameterization is the key to any advanced test framework.
Purposes of UFT Parameterization:
UFT Parameterization allows feeding the test data into test cases at run time
Easy to maintenance.
Increase the script reusability to execute the same steps for multiple sets of test data.
In the case of data change, test script modification is not required.
We can avoid hard coding in the test cases through UFT Parameterization.
UFT Environment Variables:
UFT Environment variables are used to store the global test data, which can be used across the test suites. Primarily, test suite configuration, test environment-related data are stored here, which are applicable for all the test scripts. Such as Application URL, Report Path, Test Environment name, etc., are stored in the environment variable.
The syntax for reading/ edit environment variables is “Environment.Value(“ParamName”).” We can view the variables from the Environment tab of the “Test Settings” wizard.
Classification: Two types of environment variables are available –
Built-in: These are the UFT defined environment variables related to UFT and Test Case information details. Such as TestName, OS, OS Version, etc. This is the read-only variable and accessible from entire test suites.
User-Defined: These types of environment variables are defined by the tester based on the requirements. Again user-defined environment variables are classified into two parts –
· Internal – It is defined in the specific test case for reading or writing purposes. From the wizard, we can add, edit, or delete user-defined internal environment variables. Also, it can be created during the execution as well by assigning any value to Environment.Value(“ParamName”), the variable will be auto-created. The scope of these variables is restricted to a particular test case.
· External – It is defined in an external XML file that can be associated with UFT through Load Variable options from the same wizard. These variables can be accessed only for reading purposes. The scope of these variables is the entire suite.
UFT Parameterization – UFT Environment Variable
Create Internal Environment Variable:
Step1# Open Test Setting from navigation “File->Settings.”
Step2# Click on Environment link from the left navigation to open Environment Section. Also, Select variable type as User-defined.
Step3# Click on the plus icon to add the internal environment variable.
Step6# From the test, we can read the value using the code – Environment.Value(“externalEnvVariable”)
UFT DataTable Parameters:
UFT DataTable is used to store test data, which can be used in the test cases during the run time. Structure wise, UFT DataTable Parameters are looked like Microsoft Excel sheet. Every column of the datatable sheet is referred to as the UFT datatable parameter. We can store different data sets in datatable, which can drive the test execution. UFT Datatable parameters are an essential part of the data-driven test framework. UFT Datatable Parameters are store as default.xlsx file in the UFT Test case folder.
To run a test case for different global datatable rows, we can configure the same in the Test Settings dialog, that can be accessed from menu navigation “File -> Settings -> Run(Tab)” as shown below:
UFT Parameterization – Run Setting
UFT DataTable Classification:
There are two types of datatable available –
Local datatable – Every action has one default datatable, which is referred to as local datatable. It can be accessed across actions. Syntax to access the local datatable –
DataTable.Value(“Param1”,dtLocalSheet) or DataTable.Value(“Param1”,”SheetName”)
Here dtLocalSheet can only be used from the container action of that datatable.
Global datatable – Every test case has one default global datatable, which can be accessed across different actions. Syntax to access the local datatable–
DataTable.Value(“Param1”,dtGlobalSheet) or DataTable.Value(“Param1”,”Global”)
Purposes:
Test Data parameterization.
Easy to implement and maintain the UFT Datatable Parameters.
Easy to work with bulk test data.
This is the primary component of Automation Data-Driven Test Frameworks.
Easily isolate the test data from the code area.
This can be updated easily by any nontechnical test user.
DataTable Operations (Mostly used):
Sample UFT DataTable
Read-Write Operation –
In the above figure, if we want to access value from the second row of local action, named mainAction, the script will look like –
//Copy data from Param1 to Param2 column.
DataTable.GetSheet(“mainAction”).SetRowCount(2)
tempVariable = DataTable.value(“Param1”,“mainAction”) // Read from dataTable
destination_sheet(Optional) – destination external excel data sheet name.
UFT Action Parameters:
Action parameters are used to define the variables that are accessible in the contained actions. It’s mainly used to pass the test data into called actions and return as output. The parameter can be created from the action properties section.
There are two types of action parameters available –
Input Parameter – Pass value to actions.
Output Parameter – return value from actions.
UFT Action Parameters
Input Parameters:
We can pass the value as an input parameter as arguments when calling the action. Example –
Here we are passing the value of variables inputValu1 and inputValu2 as an action parameter. Same value can be read from childAction using Parameter(“inputParam1”) and Parameter(“inputParam2”).
Output Parameters:
We can read the value as an output parameter variable as arguments when calling the action. Example –
function “childAction”, one iteration,inputValu1,inputValu2, outputValue
Here outputValue is the variable that stores the output parameter of the childAction.
Create Action Parameter:
Step1# Open Action Properties section from “View->Properties” navigation.
UFT Parameterization – Create Action Parameter 1
Step2# Click on the Add button from the Parameter tab and click on the “Add Input Parameter” or “Add Output Parameter” link.
Step3#: Enter the required details to create parameters.
UFT Parameterization – Create Action Parameter 2
UFT Random Number Parameters:
The UFT Random Number parameter helps us to generate random numbers through this specific parameter. The following example returns a random number using the random number settings defined in the p_Text parameter.
RandomNumber(“p_Text”)
UFT Parameterization – Assign Parameters into UFT test step:
Step1# Change the action layout from editor view to keyword view through the menu option “View->Keyword View.”
UFT Parameterization – Assign Parameters 1
Step2# Click on the value column for any step and click the <#P> icon.
UFT Parameterization – Assign Parameters 2
Step3# Based on the configuration/ data setup, we can select either of the below four types of the parameter from the corresponding tabs –
Test/Action Parameter
DataTable
Environment
Random Number
UFT Parameterization – Assign Parameters 3
Conclusion:
In this uft tutorial, we have learned about UFT Parameterization such as UFT Environment Variables, UFT DataTable Parameters, UFT Action Parameters with practical implementation. Click here to understand more from the Microfocus support portal. Also, if you want to prepare for UFT Interview Questions, please click here.
Testing is now an important phase of the software development life cycle to secure the product’s quality. Also, using of untested product can cause the business loss due to faulty coding.
Here automation is playing an essential role in the testing cycle to reduce the efforts and time. There many tools are available for test automation. But, if we consider the broad application coverage, Unified Functional Testing(UFT) tool is very popular for test automation.
In this topic, we are going to learn about the UFT Actions, steps to working with actions, UFT function library and library creation steps.
The UFT action component is acted as a container for writing the scripts. The UFT actions allow us to break the entire automated functionalities into small modules. Any automated test cases should have at least one action by default. But, we can use more than one action based on the test design.
Different parts of an Action:
The overview of different sections which are available in UFT actions are explained below –
Scripting Area – This section contains the actual test scripts.
Local Object Repository – The technical information of test objects are kept here.
Local DataTable – We can store the test data here which will be used in the test script. It’s similar to the excel sheet.
Properties – Through this section, we can pass the test data as input and read the output.
Classification of UFT Actions:
The UFT actions can be classified into below three types –
Non-Reusable Actions: This types of actions are treated as the private action for the test script. Thus it cannot be referred from the out side.
Reusable Actions: The reusable actions are treated as a shared action which can be referred from outside. It is used to share the automated common functionalities with the multiple test cases. During the action creation, the reusable checkbox need to be checked to make it as a reusable component. There is two options are available while referring the reusable actions from external places. The options are “Call to an Existing Action” to link the action or “Call to Copy of an Action” to copy the entire action. The primary purpose is to increase the concept script reusability for better maintenance of test cases.
External Actions: When an action has been called from a different action, is called as external action.
Reusable and Non-Reusable UFT Actions – Differences:
The scope of non-reusable action is within the same test script, but reusable actions can be accessed from outside test cases.
The non-reusable action is used to create logic of the functional test case, but reusable actions are used to create the reusable components.
Action Parameters:
The action parameter defines the different input-output data parameters. The input parameters are used to pass the input test data while calling the action and the output parameters are used to return the data from the action to the called actions. We can define the action parameters from the action property section. Two types of action parameters can be defined which are –
Input Parameter – It’s used to pass value to the action as arguments.
Output Parameter – It’s used to return the values from action.
The below example shows the use of input and output parameters of the action –
Here, we are sending the input data through the variables inputValue1 and inputValue2 . From the calling action, the input parameter’s value can be read using Parameter(“inputParam1”) and Parameter(“inputParam2”). Also, the parameter outputParam is used to return the data from action “subAction” through the variable outputValue.
Action Parameters
UFT Actions with Object Repository:
By default, every action contains one local object repository. So the action can use objects from the local repository. Also, we can use any shared object repository to make it more reusable. It is advisable to use a shared object repository for reusable actions.
Steps to Associate Shared Object Repository: The steps to associate repository are mentioned below –
Step1# Rightclick on the action icon from the solution explorer section and click on “Associate repository with action” link.
UFT Actions – Associate Repository – Step1
Step2# Local the path for the shared object repository and click on “Open” button.
UFT Actions – Associate Repository – Step2
Step3# Confirm the “Automatic Relative Path Conversion” dialogue to complete the process. It’s an optional step.
Step4# The the associated shared repository is visible in Solution explorer section. Also, we can open it as the read-only mode by double-clicking on it.
UFT Actions – Associate Repository – Step3
UFT Actions with DataTable:
Another important component of a UFT action is datatable, which is similar to Microsoft Excel sheet. Datatables are used to store data which are used in test cases.
The UFT datatables are classified into two categories. Those are explained below –
Local datatable – The every UFT actions are contain one default datatable. This datatable is known as local datatable. The data available in datatable, can be read or update throughout the actions within same test case. The syntax to access the data are,
DataTable.Value(“Param1”,dtLocalSheet) or DataTable.Value(“Param1”,”SheetName”)
Here, dtLocalSheet is only applicable while trying to access the datatable from the container action.
Global datatable – Apart from local datatable, every test case contain one default datatable which is known as Global datatable. It can be accessed across all the actions using either of the below syntax –
DataTable.Value(“Param1”,dtGlobalSheet) or DataTable.Value(“Param1”,”Global”)
DataTable – UFT Actions
As per the dataTable structure which is shown in above diagram, the script to update data in 2nd row of column “Param1” from column “Param2” of “mainAction” dataTable, will be looks like below –
'Copy data from Param1 to Param2 column.
DataTable.GetSheet(“mainAction”).SetRowCount(2)
myVar = DataTable.value(“Param2”,“mainAction”)
DataTable.value(“Param1”,“mainAction”) = myVar
Working with UFT Actions:
Three different operations can be performed with the actions –
Call to New Action – Create a new action.
Call to Copy of Action – Create a new action by copying areusable action
Call to Existing Action – Calling an existing reusable action as a reference.
Call to New Action:
Step1# Click on navigation “Design-> Call to New Action” to open new action creation window.
UFT Actions – Call to New Action – Step1
Step2# Enter below details and click on OK to create a new action.
Name – We need to provide the name of the action.
Reusable Action – We need to check it to make the action as reusable.
Description – It’s an optional field to provide a description of the action.
Location – This field defines the position of new action to be placed after creation.
UFT Actions – Call to New Action – Step2
Step3# Action is created and available in the Solution Explorer section. Now click on “Add” button from Properties section(Parameter tab) to create parameters. After providing the name of Input or Output parameters to create it.
UFT Actions – Call to New Action – Step3
Call to Copy of Action:
Step1# Click on navigation “Design-> Call to Copy of Action” to open “Select Action” Dialogue window.
Step2# Enter below details and click on OK to create a new action.
From Test – Need to select the container test case for the source reusable action which will be copied.
Action – We can choose the target action from the list box options.
Action Description – It’s an optional field to provide a description of the action.
Edit new action properties – We need to check it if we want to edit the properties.
Location – This field defines the position of new action to be placed after creation.
UFT Actions – Call to Copy of Action – Step2
Step3# Edit the properties such as name, parameters, descriptions etc.
UFT Actions – Call to Copy of Action – Step3
Step4# Click OK to create the action.
UFT Actions – Call to Copy of Action – Step4
Call to Existing Action:
Step1# Click on navigation “Design-> Call to Existing Action” to open “Select Action” Dialogue window.
Step2# Enter below details and click on OK to create the reference of reusable action.
From Test – Need to select the container test case for the source reusable action which will be copied.
Action – We can choose the target action from the list box options.
Action Description – It’s an optional field to provide a description of the action.
Location – This field defines the position of new action to be placed after creation.
UFT Actions – Call to Exsiting Action
Step3# Reference of existing reusable action will be showing below –
RunAction “testAction”, oneIteration
UFT Function Library:
Overview of Functions:
A function is a logical block of instructions. UFT supports the vbscripting. So, we can follow the guidelines to create functions in UFT. Any kind of conditional, logical or looping statements can be developed through the functions in UFT which can be reused from any place. Even, we can automate the functional steps through the functions with the help of shared object repository. It’s always advisable to write the functions in UFT function library which is stored in a external path. By associating the function library, we can access any of the functions from any of the UFT test cases.
As UFT allows to develop the functionality, we can replace any reusable action with the help of functions and shared object repository.
Limitations:
The limitations are explained below for the function library.
By default, the UFT function library has no dataTable or object repository..
The UFT functions can not be executed as a standalone. To execute it, it has to be called from any action.
The function library is an optional component of UFT.
Always, we need the help of shared object repository or descriptive programming approach to automate any application functionalities.
Functions and UFT Actions – differences:
The functions are not build with default object repository and dataTable. But the UFT actions have both the default component.
The functions can not be executes as an individual component but any action can be executed stand alone.
It is easy to maintain the functions with compare to actions.
The use of multiple action can increase the weight of the test scripts which impacts the test execution. But, functions are light weighted which helps to improve the performance.
Actions are the mandatary component but functions are optional.
Step1# Use the menu option “File->New->Function Library” or “Shift+Alt+N” to open the function library cretion dialogue.
Step2# Enter the location and file name to create the function library with qfl extension.
UFT Function Library Creation Step2
Step3# Now, we need to associate the function library in the current test case by clicking on the “Associate Function Library with Test” option.
UFT Function Library Creation Step3
Step4# The function library is now showing under the Solution explorer section. We can write our function using Vbscripting in the library.
UFT Function Library Creation Step4
Conclusion:
In this article about UFT Actions and function library, we have learned about about uft actions, classifications and step by step guidance to create different types of UFT Actions and UFT Function Library. Click here to understand more from the Microfocus support portal. If you want to get the flavors of frequently asked UFT interview questions, please click here.
Testing is now an important phase of the software development life cycle to secure the product’s quality. Also, without having testing, we can’t ensure the fulfillment of all the requirements. Here automation is playing an essential role in the testing cycle to reduce the efforts and time. In the market, there are multiple testing tools available to automate the testing process. The most used automation testing tool is UFT.
In this topic, we are going to learn about the UFT Object Repository, descriptive programming approach and concept of virtual object in UFT, which are the most important features of UFT.
An object repository is the primary component of UFT as an automation test tool. It is the collection of test objects which are used to map the applications with the UFT test scripts. Basically, one or multiple properties that can uniquely represent any test objects of the application are stored in Object Repository. For example, name, id, inner text, these are the common properties used to represent any object. It follows the below properties to identify the field objects –
Two types of object repositories are available in UFT –
Local Object Repository
Shared Object Repository
Local Repository
Shared Object repository – An object repository that is located outside of the test case is known as a shared object repository. It can be shared across multiple actions or test scripts. We can build it with the help of the object repository manager. It’s used for reusability purposes. We can store it as a .tsr file in any location. This type of object repositories is mostly used for reusability purposes in Keyword or Hybrid test frameworks.
Shared Repository
Guideline for Object Repository:
The logical name of the objects in the repository should be given based on the application functionality.
Smart identification should be disabled to increase performance.
Object Repository size should not be big; descriptive programming can be partially used to reduce the size.
Handle dynamic objects through regular expressions or descriptive programming.
Use a shared object repository instead of a local.
Do not use multiple entries for the same object in Repository.
Different Options in Object Repository:
ObjectFinder – This is one of the most important and helpful features of UFT to analyze the test object. Through this option, we can view/analyze the different properties of test objects before adding them to Object Repository. It will help us to define the object identification approaches for test automation. Without object Finder, it is very difficult to define the descriptive programming approach.
Object Finder
Add Object – It’s used to add any application object into the repository.
Update from the application – We can update any objects which are already added to the repository directly from the application through this option.
Highlight – Object can be highlighted in the application.
Locate in Repository – We can locate the actual object available in the repository from the application.
Object Properties section – Descriptive properties, ordinal identifier, and smart identification configuration can be view/ edit from this section.
UFT Object Hierarchy: The UFT test object hierarchy includes one or multiple levels of test objects. The highest level of the object may represent a window, dialog box, or browser type object, depending on the environment. For any web applications, three levels of object hierarchies are available – Browser, Page, and individual test object. So, the identification has been made sequentially from top to bottom.
Objects from the repository can be identified based on the properties or behavior as appeared in the application. There are three different types of property options that are available to locate any object uniquely. Those are –
Descriptive Properties – Based on the application development, behavior or properties are defined in the application. It has two parts – Mandatory properties and assistive properties. Based on the uniqueness of the properties, UFT is able to identify the objects. First, the tool is to try to identify the Mandatory properties such as name, id, text, etc., which are defined during the application development, are used to identify the object. If any unique combination is not available, UFT is trying to identify the application with the help of some additional properties, which are referred to as assistive property.
Ordinal Identifier – When the descriptive properties are not sufficient to identify any object uniquely, UFT is trying to define some additional properties based on the appearance of the objects in the application to identify. These properties are called an Ordinal Identifier. Three types of ordinal identifiers are available –
Index – it’s defined based on the position of the object in the application. Index value always starts from 0.
Location – it’s defined based on the location of the object in the application. The location value always starts from 0.
CreationTime – it’s defined based on the creation time of the object in the application. The value of CreationTime always starts at 0.
Smart Identification – When Descriptive properties and Ordinal Identifiers are failed to identify any object, some additional configuration/properties are used, which are predefined to identify the objects in this case. Smart Identification is the last option to identify the objects. It’s only applicable if we set the value as true. But this feature has slowed down the test execution. So, as best practices, in most cases, we need to disable these features.
Property View of Repository
Step by step guide to add Objects:
Open the test application and move to the desire page/screen to add objects.
Open local object repository from UFT by clicking on the Object Repository icon or pressing “Ctrl+R” keys. In case of a shared repository, we can open it from “Resources-> Object Repository Manager.”
Click on the add object button(Green plus button) in the repository. Now the tool will allow us to select the object by clicking on the desired field in the application.
After the selection of an object, an intermediate “Object Selection – Add to Repository” popup will appear. Click on the OK button to add the object.
After adding the object, we can edit the properties or logical names based on the requirements.
Object Repository Manager:
Object repository manager is used to manage/ work with a shared repository. We can add, update, delete objects from the shared repository through the wizard. Navigation to open – Resources -> Object Repository Manager.
How to Create a Shared Object Repository:
The different approaches are –
Create through Object Repository Manager – Open “Resources-> Object Repository Manager” and add objects from this window. After adding objects, we can save it as a .tsr file to create a shared object repository.
Converting Local Repository into Shared Repository – Exporting the local object repository (File -> Export Local Objects) into a shared object repository.
Drag Drop approach – Drag the objects from the Local Repository and drop them into a shared repository.
Associate Shared Object Repository in action:
Two options are available –
In the Solution Explorer of UFT, right-click on the action name node and select the Associate Repository with Action.
In the Open Shared Repository dialog box, select the object repository and click Open.
Object Repository Comparision Tool:
This is used to compare two shared repositories and identify the mismatches.
This tool can be opened from “Object Repository Manager” by the following path – “Tools-> Object repository Comparision Tool.”
Select both the shared repository and press on OK button.
Now comparision details will be available to analyse.
Object Repository Comparision Tool
Object Repository Merge Tool:
This is used to merge two shared repository into one.
Merge tool can be opened from “Object Repository Manager” by the following path – “Tools-> Object repository Merge Tool.”
We need to select the primary and secondary repositories for merging.
Now analyze the conflicts and save for merging both the repositories into the primary repository.
Object Repository Merge Tool
Handling Dynamic Objects:
Two options are available to handle dynamic objects –
Descriptive programming approach – We later about descriptive programming in this article.
Regular Expression – It’s a series of characters that form a pattern/string which is used to identify the objects. We can define it by replacing the dynamic part of any properties with wild characters. Let see the below example –
We have a dynamic link with text as – “Current date is 03-04-2000”. Here we can observe that in this link, the “Current date is “ part is constant by rest part is getting change every day. So we can use the either of below pattern while defining the objects in Object Repository –
“Current date is .*” – Here ‘.*’ represent any string of any size.
“Current date is \\d\\d-\\d\\d-\\d\\d\\d\\d” – Here ‘\\d’ can replace one numeric digit only.
Similarly, there are more regular expressions available. Please click here to see that.
Descriptive Programming:
Descriptive programming is an approach to define the description of the object during execution time. Through this approach, we can execute the test cases when the objects are not stored in the object repository.
The purposes of using the Descriptive Programming approach are –
The test object is dynamic in nature.
To execute test cases without adding objects in Object Repository.
Execution performance may decreases if we use a big Object Repository. Descriptive programming can be used to avoid it.
ChildObjects are used to create a collection of objects which are matched based on the defined object descriptions. The parent objects proceed ChildObjects. Example – refer above example.
Working with descriptive Programming:
There are two ways to develop test cases using descriptive programming –
1. Description Objects – Script is created using the Description object with the required properties. Example – Below descriptive programming approach is used to find the number of links available on a particular webpage.
Descriptive Programming
2. Description Strings – The Description of the object are passed as a string during the test case creation. Example –
Comparision Study between Object Repository and Descriptive Programming:
Object Repository
Descriptive Programming
Object need to be added here.
No need to add object in OR.
Difficult to handle dynamic objects.
Easy to handle dynamic objects.
Reduce the performance of the execution.
Increase the performance of the execution.
Object need to be defined prior to execution.
Objects are defined during execution.
Virtual Object in UFT:
Sometimes, we have observed that objects in test applications are not recognized by the UFT for automation. Instead of that, the entire region identified as standard window objects. To handle this kind of scenario, UFT provides a feature as a virtual object to define those unrecognized objects as Button, link, textbox, etc., based on their behavior.
We can open the virtual object creation wizard from the path – “Tools-> Virtual Object->New Virtual Object.” By following the step by instruction from this wizard, we can define the Virtual Objects.
Limitations of Virtual Object are –
UFT is not able to record the virtual objects.
It’s not controlled by Object Repository.
Checkpoints can not be added here.
Object Finder can not inspect the virtual objects.
Execution may fail if the screen resolution has been changed.
Creation of Virtual Object in UFT:
1. Open Virtual Object Manager from navigation “Tools-> Virtual Object” and click on New button.
2. Click on Next from “Welcome to Virtual Object Manager” screen.
New Virtual Object in UFT – Screen 1
3. Select class and click Next from “Map to a Standard Class” screen.
New Virtual Object in UFT – Screen 2
4. Now mark the test object from application using mouse and click on next.
New Virtual Object in UFT – Screen 3
5. Now configure the object and click next.
New Virtual Object in UFT – Screen 4
6. Now click on Finish to save virtual Object.
New Virtual Object in UFT – Screen 5
Conclusion:
In this article about UFT Object Repository, we have learned about how to identify objects from the application under test and the classification. Click here to understand more from the Microfocus support portal. Also, if you want to prepare for UFT Interview Questions, please click here.
After developing, the software product has to be passed through the testing phase to ensure the quality. In the testing life cycle, test automation has a brighter future as it has the ability to reduce the testing cycle and cost with expected quality check. Many tools are available for test automation, but if we consider the broader application coverage, the Unified Functional Test(UFT) tool is one of the key player.
Through out this “UFT Overview” article, we will go through the basics of testing and overview of different components which are available in UFT.
Testing has the importance for cross verification of the end product. Testing can be done in different phases of software development life cycle. We can perform the software testing in two ways – manually or through test automation. We will talk about test automation through out the tutorials.
The purposes of software testing are explained below –
Verification of the quality of the end product..
Find and fix the bugs before deploying the software in production.
Testing can assure about the software requirement.
Report if there is any performance or security issues.
The classification of software testing are explained below –
Unit Testing – This type of testing are done in the development phase by the application developer.
Integration Testing – After the development, when all the components are integrated, the integration testing is required to ensure the interfaces and the different software components are working as expected.
System Testing – This type of testing is done before delivering the end product. The functionalities of the product are tested in this phase.
User Acceptance Testing – The User Acceptance Testing(UAT) is done by the business users to check the requirements before deploring the product into production. This is a blac-kbox testing.
Regressing Testing – Regression testing is required to verify the business-as-usual functionalities during the application enhancements.
About Automation Testing:
In todays life, time is an important criteria for the software testing process. So, there is a high demand to reduce the test execution cycle without compromising with the quality. In this particular aspect automation testing is come into the picture. Automated testing is nothing but the testing has to be done automatically without spending any human efforts. Many tools are available to perform test automation like RFT, QTP (UFT), and Selenium. But, considering the application coverage and flexibility, UFT is ruling the test automation industry. In this tutorial, we will provide an overview idea of UFT as a test automation tool.
The key features of test automation are mentioned below –
Automated test execution is always very fast with compare with manual testing cycle.
Common human errors can not be replicated in test automation.
It reduces the test execution cycle time which helps to reduce the entire software development life cycle as well.
Ensures the quality by covering more functionalities.
Parallel test execution can be done.
About UFT Overview:
UFT is the short form of Unified Functional Testing, which is previously known as Quick Test Professional (QTP). With the help of VB Scripting, test cases build to automate any functional testing scenario. The primary merits of UFT over other test automation tools, are specified below –
Test automation process is simple and easy to learn the tool in a shorter span of time.
Automation can be done through the recording.
Identification of test object is more efficient and robust.
It’s easily compatible with different standard test automation frameworks.
It has more application coverage. The famous application platforms (e.g., Web, SAP, SFDC, mobile, etc.) are compatible with UFT.
UFT supports web service testing(API) and XMLs.
It supports vbscripting which is easy to learn
We can easily integrate the UFT with ALM as a test management tool.
It has an in-build excel sheet like dataTables which helps to develop test data driven approach easily.
In-build reporting is available with the tool during execution.
Different important components of UFT are specified below –
Action –Actions are the actual container of the test scripts i.e., we can develop the test case in a action. The application functionalities can be broken into small logical blocks/ modules using the actions.
Object Repository – The technical properties of test objects are stored in object repository (OR) which are used to develop the automated test cases in UFT.
Datatable – The another important features of UFT is datatable which is used for test data management. Based on the usage and looks, it’s comparable to Microsoft excel sheet. We can add, edit, delete data at any time from the datatable. The datatable allows us to design the data-driven automation test framework.
Function Library – The function library in UFT, contains the user defined functions and sub procedures. Conceptually, function is a block of codes or statements which are used to perform a specific task. To access the functions from the function libraries, first, we need to associate the library with the UFT test cases.
Environment Variable – UFT allows us to store configuration related test data which will be accessible through out the entire test suite in a special kind of variables. This variables are known as environment variable. Three types of environment variables are available – In built, internal user defined and external user defined environment variables. Details on environment variables are available here.
UFT Overview
About Automation Test Framework:
The automation test framework defines some standard guidelines which help to perform test automation test activities in a organized and efficient way. The purposes of automation test frameworks as specified below –
Use the same standards through out all the test cases.
Increase the speed of test automation activities such as development, execution, maintenance etc.
Easy to debug the failed test cases.
Using of predefined standards, there is better readability.
Reduces the test execution efforts by implementation of unattended execution.
Test data can be managed in a structured way by defining the proper frameworks.
In the below section, the all types of automated test frameworks are explained –
Linear Automation Framework –
This type of automation test frameworks are also known as record and play framework. The reason behind this naming convention is that the test cases are created by recording the test scenario by the UFT Recording feature. This type of test case does not contain data parameterization, reusable components etc. Here, the test cases can be created quickly with minimum skillset of tester. This test framework is popular for one time test execution but not advisable to use for long run. As it needs much more maintenance efforts if we compare with other frameworks.
Modular Driven Framework –
The name suggest that test cases are driven by reusable modules which means that the entire test scenario is broken into small parts as modules. By clubbing the modules, we can create the test cases. The modules can be created using reusable actions or procedures with the help shared object repository. Before starting the scripting, we need to analyze the entire test scenarios and identify the small sections which can be reused again and again.
As the modules are the driver in this test framework, the test maintenance efforts are very less if we compare with linear test framework. This framework approach is very useful for any application where different test flows are available.
Data-Driven Framework –
As per the name suggest, the test cases are driven by test data in data-driven test framework. The test data can be stored in datatables, excel sheet, databases or csv files which will be fetched and used during the test execution. This framework is very useful for applications where single flow is available and based on different data criteria, different test cases are created. It minimizes the number of test cases as same test case can be executed for different set of test data. Thus, it reduces the maintenance efforts as well.
Keyword Driven Framework –
The keyword-driven test framework is also called the table-driven testing. The first step of this framework is to develops the keys which represent the small modules such as invoke, login, enterData, clickSubmit, verify, logout, etc. Then, by specifying the keys in predefined excel or datatable along with data and operation, we can develop the test cases. In this framework, one driver script is required which reads the excels or datatable and perform the corresponding task as per the keys. This is best fitted for small projects and due to usage of reusable keys, the maintenance efforts are very less. The main disadvantage of this keyword driven framework is the complexity.
Hybrid Test Framework –
By combining two or more test frameworks which are explained above, we can define the hybrid test frameworks. This types of frameworks are mostly used for any test automation projects.
UFT Overview – Test Framework
Conclusion:
In this article about UFT Overview, we have learned about the overview of automation testing, components of UFT, and test frameworks. Click here to understand more from the Microfocus support portal.
Through out this UFT Setup article, we will explain the step by step approach of UFT Setup, which includes download. Install, License Configuration, and ALM Connection.
The software testing now the hot topic on software development life cycle to ensure the quality of the end product. Also the marked demands the faster delivery of the product with the best quality. On this aspect, test automation plays the major role to reduce the test cycle time. In the market, different types of automation test tools are available. But, Unified Functional Testing (UFT in shorter form) is playing the key role in the market.
Step1: Open the microfocus site and click on the corresponding link to download the latest UFT.
Step2: Enter the below details to register for the UFT Trial version.
UFT Setup – Registration to Download UFT
Step3: Click on Start Free trial to download software and unzip it if required.
Install UFT
Step1: Uninstall the existing UFT version from the system (if any).
Step2: Execute the setup file with Admin privilege, which was downloaded previously.
Install UFT Step2
Step3: Enter the location to extract temp files and click on Next.
Install UFT Step3
Step4: Update window components (if required). Click OK.
Install UFT Step4
Step5: Click on the Next button and accept terms and condition
Install UFT Step5
Step6: Select required Addons to automate corresponding applications. Also, the Installation directory can be modified from here.
Install UFT Step6
Step7: Keep the default selection and click on the Install button and wait for the completion of the installation.
Install UFT Step7
Step8: Click on the Finish button to close the setup wizard.
Install UFT Step8
Step9: Install Microsoft Script Debugger by executing scd10en.exe file with admin privilege. The script debugger is available in Microsoft’s official page to download.
UFT License Configuration
Step1: Open the UFT with admin privilege(for the first time only).
UFT Setup – UFT License Configuration Step1
Step2: Click on the Install Licence button from the error message(if it appears).
UFT Setup – UFT License Configuration Step2
Step3: Click on the “Concurrent License” section.
UFT Setup – UFT License Configuration Step3
Step4: Enter the License server as “mlgccu01devat02” and click on Connect. Some time error may appear (in the error case, retry for a couple of times after restarting the server)
UFT Setup – UFT License Configuration Step4
Step5: If connection success, click on the INSTALL button.
UFT Setup – UFT License Configuration Step5
Step6: License server connected successfully now. Click on EXIT WIZARD and reopen the UFT tool.
UFT Setup – UFT License Configuration Step6
Step7: After the successful installation of the license server, the below addon selection screen should appear.
UFT Setup – UFT License Configuration Step7
ALM Connection
ALM is used as a script repository of UFT test cases. Also, we can manage the test execution, status reporting, defect management through the ALM. In this section, we will learn how to connect ALM from the UFT.
Step1: Open the UFT with admin privilege. Admin access is required to download the required DLL files to establish a connection with ALM. This is a one-time activity.
Step2: Select required addon and click OK to open UFT…
Step3: Click on the “ALM Connection” icon.
UFT Setup – ALM Connection Step3
Step4: Enter ALM Server URL and user credential. Server URL – http://xxxxxxxxx/qcbin/and click on Connect.
UFT Setup – ALM Connection Step4
It will take a couple of minutes to download ALM components(DLLs).
Step5: Select the ALM projects and click on the Login button.
UFT Setup – ALM Connection Step5
Conclusion:
In this article about UFT Setup, we have learned about how to download, install, and configure UFT for test automation. To know more details on UFT from support portal, please click here. Also, if you want to prepare for UFT Interview Questions, please click here.
Now-a-days, the demands of test automations are getting increased rapidly to save time and money. Many tools are available to automate the software testing process in the IT industries. But, if we consider the different aspects like the flexibility of scripting, easy maintenance, rapid development, then we have to choose the Unified Functional Testing(UFT) tool, which was previously known as Quick Test Professional (QTP).
Through out this “UFT Interview Questions and Answers article”, we are going to show case the frequently asked UFT Questions and answers which will gives you more exposures for UFT Interviews. The UFT Interview Questions and Answers article will also help to get the preparation to face UFT job interviews.
Top UFT Interview Questions and Answers
Q1. What is Software Testing?
Ans: Testing is a process to check the readiness of the end product with expected quality. There are multiple levels of testing are defined throughout the software development process. The software testing can be done through manual or automated process.
Q2. Why is testing required?
Ans: Purposes of testing –
Ensure the quality of software products.
Identify issues or break in an application before the production deployment.
Ensure all the business requirements are fulfilled.
Identify if there are any performance issues.
Q3. What are the various testing approaches?
Ans: Different types of testing are specified below –
Unit Testing – Done by the developer during the software development phase.
Integration Testing – It is done by the tester during the integration phase of different software components.
System Testing – It’s done to ensure the overall quality of the software products after completion of integration testing.
Integration Testing – This is done after the integration of different components/subsystems for any application.
User Acceptance Testing – It is done by the receiver of the product to check the fulfillment of all the requirements.
Regressing Testing – This done to check the business as usual processes of the application after any major or minor code drop.
Q4. What is automation testing?
Ans: Nowadays, there is a big opportunity for software testing to be done fast and efficiently with proper quality assurance. So, the test automation is the perfect solution which means testing can be done through tools/robots to reduce the efforts and increase the effectiveness.
Q5. Why automated testing is so important?
Ans: The importance of automation testing are –
Fast test execution cycle.
Avoid human errors during testing.
Reduce the manual test execution efforts.
Reduce the time of the overall software release cycle.
More test coverage ensures better software quality.
Parallel execution can be possible.
Q6. What are the major automated testing tools available in the market?
Ans: The major tools which are available in the market are – UFT, Selenium, RFT, Tosca, etc.
Q7. What is the full form of QTP, UFT, ALM, QC?
Ans:
QTP – Quick Test Professional
UFT – Unified Functional Testing
QC – Quality Centre
ALM – Application Lifecycle Manager
Q8. Explain the merits of UFT tool?
Ans: The merits of UFT are mentioned below –
Easy to automate and learn the tool.
An automated test case can be developed by recording any test scenarios.
An object identification process or approach is easy and more effective.
It supports all the standard automation test frameworks.
Automation of major application platforms (e.g., SAP, Web, SFDC, window, mobile, etc.) are possibles.
Web service testing is possible also supports XML.
It follows VBScripting for writing test cases, which is easy and simple.
Easy to embed with test management tool ALM.
It supports data tables and excels, which will help to parameterize the test data easily.
It provides a default test reports with export features.
Q9. What is automation test frameworks? Explain the benefits?
Ans: Automation test framework is a set of technical rules or guidelines to automate test cases in an organized and effective way. The benefits of the implementation of test frameworks are –
Follow the same guideline throughout the test case developments.
Enhanced the speed of different automation testing process.
Easy to maintenance.
The application can be tested accurately.
Continuous testing can be possible.
Better readability of the test suite.
Q10. Explain the concepts of different test frameworks? Which test frameworks are commonly used, and why?
Ans: The standard automation testframeworks are –
Linear Automation Framework – This is also known as Record and Playback framework as it’s generated during the recording. Test data parameterization, script reusability concepts are not used here. Due to this, we can create test cases quickly. This framework is not suitable for the long run.
Modular Driven Framework – As per this Framework, the tester can break the entire application into small modular test scripts based on the smallest part of requirements. After the creation of modules, the tester can develop the test cases based on the small modules.
Due to the usages of modules, script maintenance is easier than compare the Linear automation framework. This approach is helpful for distributed applications where multiple test flow is available.
Data-Driven Framework – In this framework, the test cases are created based on the test data. It means, test data drives the test cases. The test data is fetched from the external sources such as Excel, CSV files, databases, etc., and they are loaded in variables. As data is parametrized, so the same test case can be used to test multiple scenarios based on different data set. It reduces the number of test cases.
Keyword Driven Framework – It is also known as table-driven testing. The automation test scripts are developed based on the keywords which are mentioned in the excel sheet. Each keyword is referring to small script modules. The keyword-driven framework is ideal for small test projects. Here, a single keyword can be reused in multiple test cases.
Hybrid Test Framework – This type of frameworks are defined by referring the concepts of more than one standard test automation frameworks. This framework is commonly used for test automation. Based on the test applications, the different suitable frameworks are identified and combined to develop hybrid frameworks.
Q11. What are the different components of UFT?
Ans: Primary components are mentioned below –
Actions – This the scripting area where actual codes are written here.
DataTables – Use to keep the test data.
Object Repository – This is a collection of technical information(properties) of test objects.
Function library – All the functions are kept here.
Environment Variable – Use to define the framework configuration, application platform-related data, which can be used throughout the entire test suite.
Q12. What is Action? Explain the classifications?
Ans: Action is basically acted as a container where we can write our test scripts. Through the action, we can break the entire functionalities into small logical steps/modules. Every script should contain at least one. But we can create/refer multiple actions based on the requirements. There are two types of actions available –
Non-Reusable Actions: This type of action can be called in the same script only.
Reusable Actions: This type of actions can be linked from external UFT test cases.
Q13. What are reusable actions? Explain the purpose.
Ans: This is one kind of action that can be reused from multiple test scripts. It provides the reusable feature of UFT. While creating actions, we need to check the reusable checkbox to make it reusable actions. After that, we can call it from other test scripts by following the option “Call to an Existing Action” for linking or “Call to Copy of an Action” for copying the reusable actions.
It’s mainly used for script reusability purposes to reduce the no of test cases. Indirectly, it will help for better script reusability.
Q14. Explain the main difference between local and reusable actions?
Ans: The scope of local action is restricted to with in the same test case, but the reusable actions can be used from the external test cases.
Local actions are used for building the logic of a particular test scenario, but reusable actions are developed as a module to cover the common functionalities that can be reused.
Q15. What are the different parts of actions? Explain.
Ans: The major parts of actions are –
Scripting Area – It’s used to write the scripts.
Local Object Repository – Contains the objects which can be used in the scripting area of that action.
Local DataTable – It contains the test data which can be used in that particular action.
Properties – The input/ output parameters can be defined here.
Q16. Explain the differences between UFT script view and the keyword view?
Ans: In the scripting view, we need to write the logic as a script. But in the keyword view, we can view the scripts as a keyword and can be modified by selecting the configuration.
Q17. How can we create a reusable action?
Ans: While creating actions, we need to check the reusable checkbox to make it reusable actions.
Q18. What is an object repository? Explain the purpose of it.
Ans: The Object repository (OR) is the collection of technical information(properties) for the test objects which is used to map the application with the test case. Basically, different types of properties of the application fields are stored in OR as an object. The properties are used to uniquely identify the test object. It is advisable to follow the below sequence of object identification mechanism through the OR –
Local Object repository – The scope of local object repository is restricted to with in the same action. The local OR is created as mtr file within the test folder.
Shared Object repository – The shared object repository can be access from multiple actions and test cases. The shared object repository can be defined with the help of object repository manager utility. It is created with the tsr file extension.
Q20. Explain the ideal framework to use a common object repository?
Ans: The common object repository component of UFT is ideal for keyword driven, modular and hybrid frameworks.
Q21. What is the .tsr file?
Ans: Shared object repositories are saved as .tsr file.
Q22. What is the .mtr file in UFT?
Ans: Local object repositories are saved as .mtr file.
Q23. Explain the different components of the object repository?
Ans: Different parts of the object repository are –
Object Finder – It’s used to inspect or analyze the technical properties of test objects at any point of time.
Add Object – Any object an be inserted into the repository through this option.
Update from the application – This option allows us to update the properties for the existing objects with the reference of the application.
Highlight – It allows to highlight the selected object in the application.
Locate in Repository – It allows us to locate the object in object repository from the application.
Object Properties section – Different types of object properties can be viewed/edited from this section. The properties includes mandatory properties, ordinal identifier, smart identification, etc.
Q24. Explain the object identification mechanism in UFT?
Ans: The test objects can be identified based on the technical properties which are defined during the application development or the behaviors during the appearances. The UFT uses some mechanisms to identify objects which are explained below –
Descriptive Properties – The technical properties of test objects which are defined during the application development, are treated as descriptive properties in UFT. This properties should be the first choice for object recognition. The descriptive properties are the combination of mandatory and assistive properties. If the mandatory properties fail to identify any object uniquely, we need to go for the assistive properties for object recognition.
Ordinal Identifier – We need to use the ordinal identifier while both the descriptive properties are not able to identify the object. The ordinal identifiers are defined by the UFT based on the appearance, location of the test objects. Three types of ordinal identifiers are available in UFT –
Index – It’s defined based on the appearance of the test object. The index value for the first occurrence of the object is always starts with zero.
Location – It’s defined based on the location of the test object. The location value for the first occurrence of the object is always starts with zero.
CreationTime – It’s defined based on the creation time of the test object. The creationtime value is always starts with zero.
Smart Identification – When both the above mentioned approaches are failed, the UFT is trying to identify the test object based on some pre-configures additional properties. This approach is known as smart identification. It should be the last option for object identification. This approach is applied to objects which are available in OR if we select the “Smart Identification” value as true. As per the best practice, we should disable it as it slow down the test execution.
Q25. What is an ordinal identifier?
Ans: We need to use the ordinal identifier while the descriptive properties are not able to identify the object. The ordinal identifiers are defined by the UFT based on the appearance, location of the test objects. Three types of ordinal identifiers are available in UFT –
Index – It’s defined based on the appearance of the test object. The index value for the first occurrence of the object is always starts with zero.
Location – It’s defined based on the location of the test object. The location value for the first occurrence of the object is always starts with zero.
CreationTime – It’s defined based on the creation time of the test object. The creationtime value is always starts with zero.
Q26. What is Smart Identification?
Ans: When both the descriptive properties and ordinal identifiers are failed, the UFT is trying to identify the test object based on some pre-configures additional properties. This approach is known as smart identification. It should be the last option for object identification. This approach is applied to objects which are available in OR if we select the “Smart Identification” value as true. As per the best practice, we should disable it as it slow down the test execution.
Q27. What is descriptive programming?
Ans: This is an alternative approach to identify object with out using object repository. In this approach, the description(identification properties) of the test object, has to provide as a string at the time of test execution. The descriptive programming helps in below use cases –
When the test objects are dynamic in nature.
When we need to avoid object repository i.e. develop functional scripts through functions.
Improve the execution speed.
When working with similar types of multiple objects.
Q28. Explain the types of descriptive programming approach?
Ans: Two approaches are available to use descriptive programming –
Description Objects – Using the Description object, the the properties can defined and passed during test execution. Example –
Description Object – UFT Interview Questions and Answers
Description Strings – In this approach, the all properties are passed as string during execution. Example –
Q29. What is the purpose of descriptive programming?
The purposes of descriptive programming are –
When the test objects are dynamic in nature.
When we need to avoid object repository i.e. develop functional scripts through functions.
Improve the execution speed.
When working with similar types of multiple objects.
Q30. Explain the differences among descriptive programming and object repository approaches?
Ans:
Object Repository Approach
Descriptive Programming
Objects has to be added in OR.
OR is not required.
It is not easy to handle dynamic objects.
Dynamic objects can be handled easily.
Reduce the execution performance.
Enhance the execution performance.
Need to define the object prior to execution.
Objects can be defined during the execution.
Q31. Explain the best practices used for object identification?
Ans: The common best practices are –
The logical names in the object repository should be self explanatory of test objects.
Disable the smart identification to increase the execution performance.
Big object repositories should not be used as it decrease the performance. The descriptive programming is useful in this condition.
Use regular expression to handle dynamic objects. Even descriptive programming approach can be used here.
Use shared object repository for reusability.
Avoid use of duplicate objects in the object repository.
Q32. How to handle dynamic objects in UFT?
Ans: We can use either of the below approach to handle dynamic objects in UFT –
Descriptive programming approach – We have already discussed this in previous questions.
Regular Expression – UFT allows to define patterns with the use of characters to identify any test objects which follow the same patterns. The series of characters i.e. the patterns can be use by replacing the dynamic part of the test objects. Example –
By analyzing the link with visible text as – “Business date is 05-12-2021”, we conclude that the “Business date is “ part is static but the remain part is dynamic which will change every day. So, to handle this dynamic object, we can use any of the below patterns while defining the “text” property in the object repository –
“Business date is .*” – Here ‘.*’ denotes any string values without any restriction for length.
“Business date is \\d\\d-\\d\\d-\\d\\d\\d\\d” – Here ‘\\d’ denotes any numeric digit.
Q33. What is a virtual object? Why did it use?
Ans: The virtual object is used when the test object is not compatible with UFT i.e. object is not getting recognized. The virtual object feature allows to define this kind of objects as link, textbox, button, etc. based on their appearances.
The virtual object wizard can be opened from the UFT menu – “Tools-> Virtual Object->New Virtual Object.” After opening the wizard, the virtual objects can be defined by following the instructions appear in the wizard.
Q34. Explain the approach to create shared object repository from local?
Ans: The conversion approaches are –
Export local into shared object repository (File -> Export Local Objects) from the Object Repository window.
Drag-drop(cut-paste) the objects from local to shared object repository.
Q35. What is an object Finder? Why is it used?
Ans: This is very helpful while working with objects. The object Finder is used to inspect or analyze the technical properties of test objects at any point of time. Based on the analysis, it will be very easy to plan and design the object recognition methods to create the object repository. Also, it helps to investigate and identify the route cause for object related issues.
For description programming, object Finder is used to capture the technical properties for the test objects.
Q36. What is a regular expression?
Ans: UFT allows to define patterns with the use of characters to identify any test objects which follow the same patterns. This patterns are known regular expression. The series of characters i.e. the patterns can be use by replacing the dynamic part of the test objects. Example –
By analyzing the link with visible text as – “Business date is 05-12-2021”, we conclude that the “Business date is “ part is static but the remain part is dynamic which will change every day. So, to handle this dynamic object, we can use any of the below patterns while defining the “text” property in the object repository –
“Business date is .*” – Here ‘.*’ denotes any string values without any restriction for length.
“Business date is \\d\\d-\\d\\d-\\d\\d\\d\\d” – Here ‘\\d’ denotes any numeric digit.
Q37. How to get the count of links which are available in a web page?
Ans: We can do this using the below descriptive programming approach with child object–
Descriptive Programming – UFT Interview Questions and Answers
Q38. What is ChildObjects?
Ans: This method is used in description programming approach. Based on the description, the method ChildObjects returns a list of matched objects. Please refer last question for example.
Q39. What are ChildItem?
Ans: When working with the table objects, the ChildItem method is used to interact with embed objects with in table cell. It will help to perform operations such as click, getRoProperty, etc. The syntax for usage –
mic_class – Refers type of the embedded object like Link, Button, etc.
index – Refers the occurrence of the embedded object. It always starts from zero.
Q40. How can we associate a shared object repository in action?
Ans: Two options are available –
Right-click on the node which represents the action name from the UFT solution explorer section.
Choose the option “Associate Repository” with Action to open Shared Object Repository dialog box.
Now, choose the correct shared object repository file and click Open to associate it.
Q41. Explain the main difference of “call to copy of action” with respect to “call to existing action”?
Ans:
call to copy of action – It will copy the entire reusable action into the working test script as local action. So any change in reusable action will not be reflected here.
Call to existing action – It will link the reusable action from the working test script as local action. So any change in reusable action will be reflected here.
Q42. What is “Object Repository Manager”?
Ans: It’s use to manipulate shared object repository. It allows to add, modify, remove of test objects from the repository. The object repository manager window can be opened from UFT menu –
Resources -> Object Repository Manager.
Q43. What is the purpose of the “Object Repository Comparision Tool”?
Ans: This tool is used for comparison between two tsr files i.e. shared object repositories. After the comparison, it will identify the mismatches. It can be opened from “Object Repository Manager” by the following path – “Tools->Object repository Comparision Tool.”
Q44. What is the purpose of the “Object Repository Merge Tool”?
Ans: This is used to merge two shared object repository into one. It can be opened from “Object Repository Manager” by the following path – “Tools->Object repository Merge Tool.”
Here, input data are passed through the variables ipValu1 and ipValu2 into the child action. The input parameters are paramValue1 and paramValue2. The input parameters can be read from the child action using expressions Parameter(“paramValu1”) and Parameter(“paramValu2”).
Q47. How can we read the value of output parameters from the main action?
Ans: The output action value can be return through output parameters from the child action. Example –
col_num –It represents the column index of the table.
micClass – Object type such as Link, Button, etc.
Index – occurrence of the object type in the particular cell. Index value starts with numeric 0.
Q49. What are the different options are available if a particular object is not getting identified by UFT?
Ans: Different available options are –
Use of virtual objects.
Perform low-level recording, and we can click on based on the co-ordinates.
Q50. Explain the best practices to work with actions?
Ans: The common best practices are –
Give a proper action name.
Use action parameters to work with dynamic test data that are generated during execution.
Use data table or external excel sheets for test data.
Use of shared repository instead of local object repository.
Use reusable actions for unit functions.
Q51. What are the functions of UFT?
Ans: Function is a collection of statements to perform specific task. In UFT, we can write any conditional, logical, looping statements in function through vbscripting. Also, we can write scripts with the help of shared objects repository in functions. Functions are written in function libraries, which are stored in external paths. To work with functions, we need to associate the corresponding functional library with our test scripts.
Using a combination of functions and a shared object repository, we can replace our reusable actions.
Q52. What are the differences between UFT functions and UFT actions?
Ans: The differences are –
Action has the own local object repository and datatable. But function does not have that.
It is not possible to execute the functions as a standalone component which is possible for UFT actions. The function should be use with in actions.
The function is easy to maintain in comparison to actions.
By using multiple reusable actions, execution performance may be reduced. Execution performance may be increased by using of function library.
We can not develop test scripts without using at least one action. But the function library is not an essential component of UFT.
Q53. What are the environmental variables? Explain the classifications?
Ans: This features is used for test data parameterization in UFT. The test data which are applicable across the entire test suite, are stored in the environment variables such as, application URL, Report Path, Test Environment name, etc. The structure to use environment variables is Environment.Value(“param_name”). It can be viewed from Environment tab which is available in “Test Settings” wizard.
The environment variables in UFT are classified into below two categories –
Built-in: The built-in environment variables are pre-defined by the UFT which are used to keep the tool and test related information such as, TestName, OS, OS Version, etc. This variables are read-only and can be accessible from entire test suites.
User-Defined: The UFT allows us to create environment variables based on the requirement which are known as user-defined environment variables. Again, two types of user-defined environment variables are available which are –
Internal – The scope of this types of variables are specific to the individual test cases only. From the Environment tab of setting wizard, the user-defined internal environment variables can be created, modified or deleted. Also, it can be defined during the execution as well with the expression Environment.Value(“param_name”)=”Some value”.
External – This kind of user-defined environment variables are defined in a XML file which need to be attached with UFT to access the individual variables. The external variables can be access through out the suite as read-only.
UFT Interview Questions and Answers
Q54. What are the limitations of virtual objects?
Ans: Limitations are –
The virtual objects can not be created through recording.
It can not be used with Checkpoints.
We can not analyze the virtual objects using object Finder.
It’s depends on screen resolution.
Q55. What are the limitations of the function library?
Ans: The limitations of a functional library are –
The function library does not have an object repository and datatables.
Execution of function is not possible from Function library. It should be referred from Actions to execute.
The function libraries are the optional component.
It works with shared object repository or descriptive programming to develop functional script through funtions.
Q56. What is datatable? Explain the different types of datatables?
Ans: Datatable is one of the most important components of UFT. It’s similar to Microsoft Excel, which is used to store data and feed the same in test scripts. Based on the data available in different rows of datatable, we can execute the test cases in a loop. Read/ Write both the operations are possible during execution.
The UFT datatables are classified into two types –
Local datatable – The every action is built with a default datatable, which is know as local datatable. The scope is available through out the test case. The expressions to access any specific parameter item from the datatable –
DataTable.Value(“paramItem1”,dtLocalSheet) or DataTable.Value(“paramItem1”,”SheetName”)
Here, dtLocalSheet indicates the default local datatable available within the action.
Global datatable – The every test case is built with a default datatable, which is know as global datatable. The scope is available through out the test case. The expressions to access any specific parameter item from the global datatable –
DataTable.Value(“paramItem”,dtGlobalSheet) or DataTable.Value(“paramItem”,Global)
Q57. Explain the syntax to read or write data in datatables?
Ans: In this example, we will see how to copy data from one cell to another cell in UFT datatable.
//Set or select the second row of the datatable
DataTable.GetSheet(“mainAction”).SetRowCount(2)
//Copy from Param1 to Param2 using a temp variable
tempVariable = DataTable.value(“Param1”,“mainAction”)
DataTable.value(“Param2”,“mainAction”) = tempVariable
DataTable – UFT Interview Questions and Answers
Q58. What is an active screen? Explain the purposes.
Ans: The Active Screen pane allows us to view snapshots of test application as it is displayed during recording time.
We can add steps, checkpoint after running the test by right-clicking in the Active, without opening your application. Also, it can be used as a reference for the test object in the future for any test failure.
Q59. What is the recovery scenario? Explain the purposes.
Ans: A recovery scenario is an approach to control any unexpected events or errors which can appear at the run time. The “Recovery Scenario Manager” wizard is used for working with recovery scenarios. The wizard is available in UFT menu option “Resources → Recovery Scenario Manager.”
Through the recovery scenarios, we can handle either of the below-triggering points, which are the root causes of errors –
Errors for un-handled pop-up windows.
Errors related to Object State
Error during Test Run
Application Crash
The main purpose of the recovery scenario is to handle all types of unexpected errors and perform some predefined tasks based on the error types.
Q60. How to develop a recovery scenario?
Ans: We can define recovery scenarios through the Recovery Scenario Manager through the navigation “Resources → Recovery Scenario Manager.” While developing the recovery scenarios, some configurations need to be done through the Recovery Scenario Manager. The configurations are Triggering Event, Recovery operations, and Post-Recovery Test Run Options.
Q61.Which programming language is followed by UFT for scripting?
Ans: VBScripting is used.
Q62. Write the conditional structure in UFT scripting?
excelFile – Represents the excel file name which which will be created in external location.
sourceSheet – Represents the name of the datatable which will be exported.
destSheet(Optional) – Represents the external excel sheet name.
Q67. What configuration do we need to create to run the test case in a loop based on the entries in datatable?
Ans: Open the test setting window from the navigation “File->Setting” and select the Run tab. In this section, by selecting either “Run all rows” or “Run from row” radio option, we can enable this looping set.
Q68. How can we connect the database and execute select statements?
Ans: Below steps can be useful to work with database –
‘Create ADODB connection object
Set objConn = CreateObject(“ADODB.Connection”)
‘Create Recordsetobject
Set objRS = CreateObject(“ADODB.Recordset”)
‘Connect to DB using provider and server
objConn.open <connection string for the database>
‘Define SQL Query
sqlQuery=”Select * from student”
‘Execute SQL
objRS.open “Select studentname from student where role=1”, objConnection
‘Display student name
msgbox objRS.fields.item(0)
‘Close connections
objRecordSet.Close
objConn.Close
Set objConn = Nothing
Set objRecordSet = Nothing
Q69. Explain the different approaches to handle synchronization?
Ans: Synchronization issues can be handled by using the below approaches –
Synchronization can be handled using Wait(timeout) statement with the hardcoded wait time in seconds. At this point, the script will wait for a specified duration and then move on to the next step. Based on the application performance, we need to provide the timeout value.
WaitProperty – In this approach, we need to provide the property name with values for which execution needs to be a wait and the maximum wait times in mili-seconds. Once the specified property is getting satisfied with expected value, the script execution will proceed with the next step. Example –
Also we can use loop to check the appearance of the object to handle the synchronization.
Q70. How to store UFT test cases in ALM?
Ans: Firstly, we need to connect the ALM from UFT through the Connect ALM option. During the connection, we need to provide the ALM Server, Credential, and project details to connect. After the successful full connection, we need to choose the ALM path while saving the test scripts.
Q71. How can we execute UFT test cases from ALM?
Ans: Goto the ALM Test Lab and select the corresponding test cases from the Test Set. By clicking on the Run button to initiate the execution. We can trigger the execution for multiple or entire testset at a time. After initiation, ALM will invoke the UFT in the background and start the execution based on the selection.
Run From ALM
Q72. What setting is available to enable remote execution in UFT?
Ans: Open the Options window from navigation “Tools->Options.” In the General tab, we need to select the Run Sessions section to enable a remote execution setting.
Here we need to set the check box and provide valid credentials of the remote test systems.
Remote Execution Setting
Few more important UFT Interview Questions and Answers:
Q73. Explain the merits of UFT over Selenium?
Ans: The merits of UFT over Selenium are mentioned below –
· Selenium only supports web applications where UFT supports different platforms such as web, SAP, Windows, Mobile, etc.
· Easy to develop/ maintain test scripts in UFT over Selenium.
· Easy to learn UFT in a shorter span of time.
· End-to-end testing is possible in UFT.
· We can test different application interfaces through web services which is not possible in Selenium.
· UFT saves the costs and efforts, mostly in regression testing over Selenium.
Q75. Explain the approach of the automation recording option?
Ans: It is an approach to generate linear test cases by recording the manual navigation through the UFT. During the recording, the raw test cases are created where data are hardcoded with zero script reusability. It’s useful for one time test execution. It’s not advisable to create the test case for longer run through the recording feature of UFT.
The recording can be initiated by pressing F6 key or clicking on Record button which is available in Record Tab.
Q76. Explain the steps of script debugging?
Ans: Debugging is an approach to identify the script issues through a dummy run. The steps are –
· Create the breakpoint by pressing after the selection of a particular script line from where we need to start the debugging.
· Run the test or start debugging from the first step (Run->Debug from step). Here in the first case, execution will be halted at the breakpoint.
· Now we can debug each code of line by pressing F10(Step Over) or F11(Step into) key. F10 will debug each line in the parent function, but through F11, we can drill down into the sub-functions.
· During the debugging, we can view any variable or state of objects by pressing the “Ctrl+Alt” keys together.
Q77. How to log verification status in UFT reports?
Ans: We can log the verification status using the ReportEvent method. The structure of this method is –
status – four options are available based on the verification result. micPass, micFail, micWarning, micDone.
step_name – need to provide the actual step name or the expected result.
details – need to provide the actual result.
image_file_name – This is an optional step to provide the screenshot filepath.
Q78. Explain the different types of recording modes in UFT?
Ans: Different recording modes in UFT are mentioned below,
· Normal mode – The normal mode is the default recording mode available in UFT which uses all the features to identify the test objects. The normal mode is also referred as Contextual, which is applicable only for UFT compatible applications.
· Low-level recording mode – The low-level recording mode is applicable for applications which are not identified by the UFT. In this mode, scenario is getting recorded based on the co-ordinates of the test objects.
· Analog Recording – Analog recording mode records the movement of mouse and keyboard actions..
Q79. Explain the concepts of a logical name for any object?
We have broken the entire Tosca tutorial into the below list of articles. Now we are going to understand about the concepts of Tosca Test Case Design and Test Data management through out this tutorial. We have wrote this article with simple words and keep the write up shorts which help the new comer to understand the concept easily with lesser time.
In this Tosca Test Case Design and Test data Management article, we will learn about the step by step implementation approach of Tosca Test Case Design and overview of Test Data Management. If you want to prepare for TOSCA Interview Questions, please click here.
Tosca Test Case Design (TCD)
This is an approach to isolate the test data from the technical sections of test cases. So, the data and test cases are kept separately. The Tosca Test Case Design section has the capability to break our test cases into a logical structure. It is also help us to plan and design the testcases in a efficient and structured way to reduce the development and maintenance efforts.
Use the Tosca Test Case Design section is performing the below activities –
Create the testsheets, which is a combination of all possible test cases for any particular scenario or template. Basically, testsheets are holding the data for different combinations.
The concept of class in test case design approach, helps to reuse the common data across the test cases which reduce the efforts of data management.
With the help of instances, we can create the specific data for TestSheets, TCD Attributes, or TCD classes.
Create TestCase Templates and assign the Testsheets.
We need to instantiate or re-instantiate Templates to generate the instance test cases as per the testsheets.
Manage test data in testsheets and execute the instance test cases
Test Case Design objects:
The table below lists all components available in the Test Case Design section, and keyboard shortcuts where applicable.
Objects of Test Case Design
Folder – The test case design folder is used to group the test sheets or classes in a logical way.
TestSheet – TestSheet is a list of data for all possible combinations of Tosca test cases. Each data set represents one unique test case.
Attribute – It’s referred to as the different data parameters corresponding to each application field.
Attribute(not business-relevant) – It’s used for comment or description purposes.
Attribute(result) – It’s used for result purposes.
Instances Collection – It holds the Instances i.e., all possible values available for particular attribute.
Instances – This is the value of each attribute/parameter. It can be created TestSheets, Attributes, or Class level. Instances of Testsheets are basically a test case name.
Class – This is similar to testsheets, but it’s used for the reusable purpose. All the common data are stored here, which can be reused in multiple testsheets.
Class reference – It’s acting as a link of Classes from Testsheets. We can create it with the drag-drop method.
Object hierarchies in Test Case Design:
A TestSheet may have Attributes, Instances, TestSteps, and class references.
A class may be the combinations of class Attributes and Instances.
Again, an Attribute can keeps further Attributes and Instances.
A Step can keeps more Steps and Attributes.
Step-by-step process to implement Test Case Design:
Step1: Create the Class if there is some common sections are available for multiple test cases. For example, Login is a common section in most of the application. So, we need to create a class as per the below diagram –
Test Case Design – Define Class
Step2: Create testsheets as per the below structure and link the classes. Testsheets are used for the unique individual scenario. Based on the different data combinations, different test cases will be generated as per the instances of testsheets.
Test Case Design – Refer Class from TestSheet
Step3: Create template test cases. We can convert any existing technical test case into a template test case by selecting “the Convert to Template Testcase” option after right-clicking on it.
Step4: Assign the testsheet into the template test case by drag and dropping the testsheet into the template test case. Only one testsheet can be assigned to one template. After this, we can assign the Test Case Design data Attributes/ parameters into the test steps by drag-drop method or typing. Syntax for linking the parameters – {XL[parameter_name]}. The template test case can not be executed.
Test Case Design – Create Template
Step5: After assigning the data parameters, we need to generate the instance test cases. It can be done by opting the option Instantiate or Re-instantiate by right-clicking on template test cases. After the, all the possible test cases will be generated based on the data combinations of test sheets.
Test Case Design – Create Instances
Step6: Now, we can create an execution list to execute the instance test cases.
Advantages to TCD:
· Dynamic handling of objects/data is easy
· Reusability of test cases
· No scripting involved
· Data and technical components are kept separately. In the case of data change, no need to modify the test cases.
Disadvantages of TCD:
· Test case design section is very complicated
· A little expensive
· The UI takes time to understand
Reference Link – https://documentation.tricentis.com/tosca/1300/en/content/testcase_design/testcase_design_intro.htm
Tosca Test Data Management (TDM)
Test Data Management is an approach to manage the required test data for test execution. It will help us to use the data which are stored externally.
Overview of Tosca Test Data Management
Test data management is an another important component for data management which is available along with the standard installation of Tricentis Tosca Test suite.
DB2, MS SQL Server and Oracle repositories – Tosca test data management (TDM) component uses the same database which is used to create the common repository of the workspace.
SQLite repositories – For SQLite, TDM uses the separate repository to store the data.
After creation of a new workspace, by default Tosca is getting connected with the repository.
If required, Tosca is able to connect different database as TDM repository instead of default database.
Connecting to a TDM repository: Create Configuration parameter as TDMConnection in the root level and assign connection string in below format -<Databasetype>(<ConnectionString>)[dynamicmode=<on or off>,schema=<Schemaname>]
Standard module to handle TDM:
The standard module path – “Standard modules->Test Data Management->Test Data Management – Legacy.”
TDM Create Object – The TDM Create Object module helps to create a fresh TDM object for a specific object type. Initially, the new TDM object can be created with empty value.
TDM Find Single Object – It is used to search for a TDM object within the TDM repository.
TDM Set Attribute – Set Attribute module is able to set the values for any existing TDM object.
TDM Set State – This module is able to set the values of state for any existing TDM object.
TDM Add Association – This module is used to define an association between two TDM objects. This association receives an individual role name which allows the mapping.
TDM Remove Association – This module is used to remove the association between TDM objects.
TDM Delete Object – This module is used to delete the TDM Objects from the TDM repositories.
TDM Save – This Module saves the TDM object in the TDM repository.
In this Tosca Test Case Design and Test data Management article, we have learned about Test Case Design and Test Data Management. Click here to understand more from the Tricentis Support portal on this topic.
We have segregated the entire Tosca tutorial into the below articles. We have wrote this “Tosca Execution” article in a simple wording with examples which can be very helpful for entry level software tester to understand the concept easily. The moto of this article is to understand the concepts of Tosca Execution.
Through out the “Tosca Execution and Tosca Issues” article, we will provide the step by step guidance on Tosca Execution process . Also, we will explain the overview of Tosca Issues.
Tosca ExecutionList – Overview of Test Execution
Why Automation Test Execution?
Test execution is a process to verify the application functionality based on the test cases. The test execution can done manually or through automated approach. In this article, we will learn the automation test execution for the test cases developed in Tosca. The primary purposes of automation test executions with the help of Tosca are –
Reduce human efforts.
Increase functional coverage.
Ensure the quality of the delivery by avoiding unwanted human efforts.
Reduce costs and test execution duration.
Easy to data management and test maintenance.
More professional way of test reporting to the stack holders.
Unattended test execution through the distributed execution model of Tosca.
Approach to capture screenshots during execution?
Screen Capture of Failed TestSteps: Tosca is able to capture the screens for each test steps that failed due to verification of dialog failures. For the test cases which are created using Classic Engines, Tosca allows to capture screen on user aborts. The captured screenshot will be available in the path – @{Environment.ProjectDir}\\Screenshots. Path to configure this setting –
Tosca Execution – Screen Capture for Failed Test Step
Off – Tosca will not take the screenshot.
Dialog Failure – It allows Tosca Commander to capture a screenshot for dialog failure.
Verification Failure – It allows Tosca Commander to capture a screenshot for verification failure.
Screen Capture of TestStepValues: Based on the configuration, Tosca is allows to capture the screens for each TestStepValues that uses the action mode as Input during the execution. We can use the same configuration, to check the screens which are captured during test execution.
The option for screen capture of test step values, is available for following Engine 3.0 – DotNet, AnyUI, XBrowser, UIA, and the test automation, done based on the image.
To activate it, we need to change the global setting Screen Flow from path Project->Settings->Engine->Doku Snapper.
Tosca Execution – Screen Flow Setting
Also, the same thing can be achieved by adding the configuration parameter ScreenFlow and ScreenFlowPath in the execution list.
DokuSnapper: It is used to generate a Microsoft® Word document that contains screenshots and data on all executed TestSteps. Instead of capturing screenshots in every TestStep, DokuSnapper consolidates all data in one word document.
We can enable it by changing the Enable Snapper value to True from the path – Project->Settings->Engine->Doku Snapper.
The generated document will be looks like –
Tosca Execution – Dokusnapper
How to execute test cases in Tosca?
Once we are done with the Test Case creation with the Tosca Commander TestCases section, we will follow the below mentioned approaches for further proceedings:
· Execute test cases in ScratchBook
· Execute test cases from Execution List
Execute test cases in ScratchBook:
Tricentis advises using the ScratchBook for a dry run (to check the test case readiness) only, as the results do not store for future reference. We also could perform the execution of individual TestSteps.
Executing the test cases from the list of Execution :
The Execution segments provides a feature of selecting and preparing multiple TestCases for execution. Execution performed in ExecutionList will be available for further future reference.
Step-by-step procedure to prepare and run test cases from Execution Section:
Step1# Create Execution List Folder in the Executions section by selecting the “Create Execution List Folder” icon after right-clicking on any folder.
Step2# Similarly, we need to create our execution List component under the newly created execution list folder.
Step3# We can add the test cases(which are created in the last article) into the execution list from the TestCases section by the drag-drop method. The complete execution list will look like below –
Tosca Execution – ExecutionList
Step4# Now, we need to configure the execution behavior, such as the screen capture mechanism. For our learning purpose, we have enabled Take screenshots of TestStepValues and DockuSnapper.
Step5# Now, we can execute the one, multiple, or entire test cases based on the selection. We execute the test case by pressing the F6 key or click on the run button after right-clicking on the selected test cases/ execution list.
Step6# Understand and process your test results. The execution log is showing below with highlighted screenshot path –
Tosca Execution – ExecutionList Log
Also, the dokusnapper has been created in the default path “%AppData%\\TRICENTIS\\TOSCA TestSuite\\7.0.0\\dokusnapper\\” with the document name staring with the test case name.
Tosca Issues
Explain the concept of Tosca Issues?
The issue is nothing but the reason for the test failure. The route cause of the issue is a valid valid defect in the application or there is a enhancement in the application (FeatureRequest). During the automation execution, the issue or defect has to be logged and linked to the test case.
Defect – This is an application issue i.e., the application is not working as per test steps (expectation). The defect has to be fixed by the application developer.
Feature-request – If the application has been enhanced, the application will not be in synched with test cases which results the failure of the test case. As it’s a valid change in the application, the test case has to be updated based on this. This scenario has to be treated as a feature request.
We can log the issues in the Issues section or in the Execution section.
Step#1: Navigate to the Issues section.
Step#2: To create an issue, we need to right-click on Issue folder and select either of the issue type option between Create Defect or Create FeatureRequest which are available in context menu. After selection of type, Tosca Commander creates a new issue and automatically asks to change the name.
Step#3: In the next step, we can either provide a new name or use the default name by pressing Enter.
Step#4: Now, we need to enter the below details for the different fields available –
ID – We can define our own ID standards or use the Ids from any external systems.
State – The state field explains the current status of the issue. The value range can be customized based on the standards.
Type – Always two types are available here which can be changed at any time.
Description – This field represents the problem statements of the issue. Based on the description, developers take the action. The description should contain all the information to recreate the issue.
Severity – The severity represents the impact of the issue. This field accept the integer value only.
Priority – It describe the urgency of the issue to get it fixed. This field also accepts the integer values.
Tosca Issues
Conclusion:
In this article of Tricentis Tosca Tutorial, we have learned about how to perform Tosca Execution and raise Tosca Issues. Please click here to get more information from the support portal.
We have combined the entire Tosca tutorial with the below articles. You can read each of the articles by clicking on the link.
In this “Create Tosca Test Cases..” article, we have explained the step by step approach to develop Tosca Test cases in simple words which will help the new comers to understand easily. Also, we are going to learn about Tosca Parameters and Reusable TestStepBlock. To get the flavors of Tosca interview questions, please click here.
Create Tosca Test Cases
What is Test Case in software testing?
Test case is a set of instructions to ensure the quality of the software product. In other word, it is a combination of steps to walk-through the application with defined checkpoints. The test cases are written based on the requirements. Test cases can be designed for manual or automated testing. In this Tosca Test Case Creation article, we are going to discuss about Test Cases that are automated by Tosca. The Tosca Test Cases are created by using the both standard and user defined modules with required test data and verification points.
Tosca Test Case Classification: Two types of test cases are available in Tosca. Those are –
Technical Test Cases
Business Test Case
Technical Test Cases
Technical Test Case:
This are the actual test cases in Tosca which keeps all the technical information to steer the controls during execution. The technical test cases can be created by right-clicking on any folder which are available in TestCase section and selecting the blue colored circular arrow icon. The short cut key for new test case creation are “Ctrl+N” and “Ctrl+T.”
Test Step:
Test steps are created by adding the modules (standard or user defined) into the test case by drag-drop or insert method. For each of the modules in test cases are treated as test step. In the left panel of any testcases is showing the test steps and in the right side, the details about step actions are shown.
In this test step details section, we need to choose/enter appropriate attribute values for ActionMode and Value to complete the Test Cases. The different ActionModes are –
Input – Mostly used while entering data, perform click operations.
Insert – It’s used for insert purpose.
Verify – Need to select this option during verification. In the value field, we need to provide the condition.
Buffer – It’s used to set the value to buffer.
Walton – It’s used for synchronization purposes to wait(predefined time) until the condition is satisfied.
Select – Used while hierarchy levels are available and need to work on child items.
Constraint – Used for checking for a particular value, mostly used in the table’s column.
Also, there is another attribute WorkState, is optionally used for displaying the status of Tosca Test Case development. Different states are –
PLANNING – When the Test Case development is in the planning and analysis phase.
IN_WORK – It shows the development is in progress.
COMPLETED – It shows that development is completed.
Different Operation Supported by Tosca:
If-Else condition – Tosca allows us to add “if-else” condition by right-clicking on Test Case and selecting the option “Create If statements…”. Under the condition section of the “If-Else” section, we need to write the verification step for the condition.
tosca test cases – ifelse statement (Create Tosca Test Cases)
Looping Statement – Tosca supports While and Do-While looping structure. Create a loop; we need to right-click on Test Case, click on the ‘…’ icon, and after that, select the required looping type.
tosca test cases – loops
Also, we can convert a test case folder into a loop by defining the Repetition property with a looping counter.
Tosca Condition – We can add a condition in the Test Case, folder, test step, reusable test step block, step attribute level by updating the condition property. The condition can be implemented based on the business parameter, TCD Parameter, constant value, etc.
Conditions (Create Tosca Test Cases)
Step-by-step Guide to Create Tosca Test Cases
Sample functional scenario: We are going to automate below test scenario with the help of Tosca –
Step2: Click on Automobile Tab to open the “Enter Vehicle Data” section.
Step3: Enter mandatory fields and click on Next and verify that the “Enter Insurant Data” section appears.
Step4: Click on the Prev button.
Step5: Verify that the “Enter Vehicle Data” section is displayed with previously entered data.
Technical Test Case creation steps:
Step1: Open the URL manually to scan Modules for Home page, “Enter Vehicle Data” section, and “Enter Insurant Data” section with required controls. You can refer to the last article about Tosca Modules while creating modules. The modules will look like –
Create Tosca Test Cases – Step1
Step2: Create a folder structure and a new Test Case in the Test Cases section. Also, create three folders in Test Case as the best practices –
PreCondition – Open application, initial dataset related test steps are kept here.
Workflow – Application navigation, data entry, verification steps are kept here.
PostCondition – Closing of applications are kept here.
Step3: Drag & Drop the standard modules “Open Url” and provide URL in the value attribute. We can change the module names after adding it in Test Case based on the test steps.
Create Tosca Test Cases – Step3
Step4: Drag and drop the module “Tricentis Vehicle Insurance | Home” into the Test Case (Workflow folder) to click on the Automobile tab.
Create Tosca Test Cases – Step4
Step5: Drag and drop the module “Enter Vehicle Data” into the Test Case. Enter input data and click on Next.
Create Tosca Test Cases – Step5
Step6: Drag and drop the module “Enter Insurant Data” into the Test Case to verify the availability of “First Name” and “Last Name.” After verification, you need to perform click operation on “Prev” button control.
Create Tosca Test Cases – Step6
Step7: Again, using the module “Enter Vehicle Data,” verify that previously selected data are stored here.
Create Tosca Test Cases – Step7
Step8: Add module to close the browser and rename all the test step modules based on the functional step.
Create Tosca Test Cases – Step8
Step9: Now execute the Test Case in the scratch book (Right-click on Test Case and click on Run in Scratch book) to check the correctness of the Test Case. By default, execution will start in browser Internet Explorer. The log will be generated. If we want to execute from Chrome, we need to add TCP Browser with value as “Chrome.”
Business Test Case
The business test cases are the logical groups of technical test cases. Each of the business test case represents the functionality coverage which is designed based on the requirements. The business test cases are not executable. Only, we can monitor the testing coverage through this.
Steps to create business Test Cases –
Step1: Create a folder structure and a new Test Case in the Test Cases section.
Step2: The business test cases can be created by right-clicking on any folder, available in TestCase section and choosing the orange colored circular arrow icon. Also, business test case can be created by clicking on short cut keys “Ctrl+N” and “Ctrl+B.”
Step3: Drag and drop selected technical Test Cases into this business Test Case.
Business Test Case(Create Tosca Test Cases)
Tosca Parameters and Library
In the last example, we have provided the test data directly in the Test Cases as a hardcoded value. The main disadvantage of this approach is whenever we need to change the data; we need to update the Test Case. Also, the common test step block, such as log in with different credential, can not be reused. So, to bypass this, we need to go for parameterization.
Parameterization is a methodology to avoid use of hard coded data to make the test case dynamic and test data driven. Tosca allows many ways to perform parameterization. The important approaches are Buffer, Test Configuration Parameter (TCP), Business Parameter, TCD, TCP, etc. We will explain the buffer and test configuration parameter (TCP) in this article.
Buffer
We can say the buffer is a special kind of variable in Tosca to store run time values. Only difference is that the buffer keeps the value after the execution over. The scope of buffer is restricted to the local workspace only as the buffere value can not be updated to shared repository. There is different standard modules are available in Tosca to work with buffers. The important modules are –
TBox Set Buffer – This module is used to create the buffer as per the name provided in the attribute section. The value provided in the attribute’s value section will be stored in the buffer. We can create more than one bufferers using this module.
TBox Name To Buffer – This module is used to store the Test Case name into the buffer for which name is provided in the attribute value field. We need to execute the Test Case from the execution list to store the Test Case name. Otherwise, it will store as “Scratch book.”
TBox Delete Buffer – It’s used to delete the existing buffers. The buffer name should be mentioned in the attribute’s value section.
TBox Partial Buffer – This module is used to extract or verify the partial text of a buffer.
Modules to Handle Buffers (Tosca Parameters)
The syntax of buffer to read the value is {B[Buffer_Name]}
Buffer can be created by using ActionMode as Buffer for any test step (buffer name should be the test step value) instead of using Set Buffer module. Also, using {XB[Buffer_Name]}, buffer can be created from a verification test step dynamically.
Test Configuration Parameters – This is the another way to parameterize the test data. The Test Configuration Parameters(TCP) can be created in test case, folder or execution list level. If the test configuration parameters are defined in parent folder level, same parameter values can be retrieved from sub folder and all the test cases available under that parent folder. To create TCP, we need to select the “Create Test Configuration Parameter” option after right-clicking on test case or folder level. The syntax to read TCP parameter is {CP[TCP Name]}. The TCPs are visible in the Test Configuration section of every Test Case, folder, or execution list.
Ideally, we should use the test configuration parameters for the common or configuration related data which are applicable for through out the test suites. The examples of the TCP are Application path or URL, credential, environment details, reporting path, etc.
Tosca provides basic test configuration parameters that are used for test settings in the Tosca workspace. Like if we want to execute the Test Case in the Chrome browser, we need to add TCP as Browser with value Chrome.
To add TCP, right-click on Test Case and click on a small square shape with violet color (Create test configuration parameter…). Also, it can be created by pressing on “Ctrl+N, Ctrl+.”. Click here to learn more.
In the below screenshot, we have changed the previously created Test Case with TCP as a part of parameterization.
Step1: Create Test Configuration Parameters to store the test data.
Tosca Parameters – Create TCP
Step2: Create buffers to store the values of TCP. This is an optional step; through this step, we try to show the usage of buffers as data parameterization.
Tosca Parameters – Set Buffers from TCP
Step3: Replacing the hardcoded test data from the test case with buffers.
Tosca Parameters – Buffer To Test Cases
Note: In this section, we have learned about the basics of parameterization. In the advanced level of Tosca, we will learn advanced parameterization techniques such as TCD, TDM, TDS, etc.
Tosca Library
The Tosca library, available in TestCase section, is a place to store the reusable components of the test cases. The each element with in the Library is known as Reusable Test Step Block.
Test Step Block
It is a grouping of test steps/ modules to perform some specific task such as login, logout, create record, etc. The test step block can be created using the Test case level folder. It helps to increase the readability and reduces the efforts for maintenance.
For an example, application launch functionality is involved with steps – invoke exe, enter user credential, and verify login. Here, we need to define a folder in a test case with a logical name as Launch Application and write three steps there.
Test Step Library –
This is the place, where we can create the reusable test step block. The Library can be created with in any folder available in TestCase section. But, there is a restriction that only one library can be created with in single folder. To create the Library, we need to right-click on any folder and select the folder icon(Create TestStep Library) which have the symbol “L”. Also, we can create the library using the shortcut keys Ctrl+N, Ctrl+L.
Reusable Test Step Block – When we defined a Test Step Block within the Test Step Library section, it’s acted as Reusable Test Step Block. We can create it in two ways –
New Reusable Test Step Block – Right-click on the Library folder and click on Create Reusable TestStepBlock icon(folder icon with a reusability symbol). Shortcut key for this – Ctrl+N, Ctrl+R. After the creation of the reusable block, we need to write the test steps here.
Convert Existing Test Step Block – By the drag-drop method, we can convert any existing TestStepBlock into Reusable TestStepBlock.
After the creation of Reusable TestStepBlock, we can drag and drop it into any Test Case to use. In the test cases, it’s only referred to as a link instead of physical steps. It can only be modified from the Library section.
Business Parameter –
It’s an approach to pass test data into the Reusable Test Step Block through the parameters. The parameters of the Reusable Test Step Block is called a Business Parameter. So, with the help of this, we can use the Reusable Test Step Block for a different set of test data. Steps to create Business Parameters –
Right-click on Reusable Test Step Block and click on icon [P] to create Business Parameter Container.
Right-click on this container, click on the blue-colored square icon to create each of the parameters.
Rename the Parameters based on data type and implement it in the test steps by removing the existing data.
Pass the data from the Test Cases through this business parameters.
Reusable Test Step Block structure with business parameters:
Tosca Parameters – Create Reusable TestStepBlock
Test Case after calling the Reusable Test Step Block:
Tosca Parameters – Use of Reusable TestStepBlock
In this “Create Tosca Test Cases” article of Tricentis Tosca Tutorial, we have learned about how to create Tosca Test Cases and parameters. Please click to read the next article of TOSCA Tutorial – Understanding of Tosca Execution List and Reports.
The Tosca Tutorial are consists of below articles which are explained the different components of Tosca. While writing the article, we have considered the knowledge of entry level software tester so that they can understand this article easily.
In this Tosca Modules with Tosca Scan article , we will discuss about the Tosca Scan procedure to create Tosca Module with brief descriptions of different terms. Step by step screens are attached for easy understanding of Tosca Scanning approach.
Tosca Modules
Concepts of Tosca Modules:
Tosca Modules keeps the technical properties of any control that is refer to any test object.
Basically, module creation is the first step to start with test case development in Tosca Commander. Module has to be created for the unit of functional block of the test application. These functional units are, for instance, pages or screens of test websites or any window applications. Any input fields such as buttons, text box, combo list, etc. are known as controls. The controls which are required for test execution, has to be captured in Module as ModuleAttributes.
Tosca modules are classified into below two categories –
· Classic Modules – It is created by classic engines during the scanning.
· XModules – It uses XEngines which are based on the Tosca TBox framework.
Icons of Tosca Modules
The each components of a module are known as ModuleAttributes and the components are known as controls. The Classic Modules have the classic ModuleAttributes, and on the other hand, the XModules have the XModuleAttributes.
Classic Engines: In the early phase of Tosca, Classic Engines are developed to processes the the TestCase information and steers the test object. There is respective engines are available to steer any test object.
TBox: The reference of Tosca Tbox framework algorithm is the basis for XEngines to steer any controls. Same can be applied to steer GUI and non-GUI objects.
XEngines: With the help of XDefinitions, the XEngines are defined in Tosca. The controls for the test objects are hierarchically structured through the XDefinition. So, the tree structure of the test objects are mapped with controls of any modules.
The Tosca TBox is compatible with the below engines:-
· Tosca XScan 3.0 – After scanning the test objects (GUI or Non GUI), each time Tosca creates Modules which contains the technical properties. This technical properties are required to steer any test objects as controls. Scanning can be done from Modules sections only. So, modules are saved in “Module” section. We can scan any application by Right-clicking onto a Module folder and select the technology of the application such as, desktop, mobile, html, SAP, etc.
· Tosca AnyUI Engine 3.0 – It allows applications with user interfaces to be steered, independent of the underlying technology.
· Tosca API Engine 3.0 –API Engine creates modules for application programming interfaces which is accessed through web service media.
· Tosca Database Engine 3.0 – It allows to work with databases as a part of database automation.
· Tosca DotNet Engine 3.0 – It allows WinForms applications to be tested that were built with Microsoft dotNET Framework 4.6.
· Tosca Java Swing Engine 3.0 – It is used to scan the Java Swing applications for test automation.
· Tosca JavaFX Engine 3.0 – It is used to scan the JavaFX applications for test automation
· Tosca Java SWT Engine 3.0 – It is used to scan the Java SWT applications for test automation
· Tosca JSON Engine 3.0 – JSON is the shorter form of JavaScript Object Notation which defines a compact format for data communication. Tosca JSON Engine is used to create, modify or verify the JSON.
· Tosca Mobile+ Engine – It allows different types of mobile applications (e.g. web, native, hybrid apps) to be steered on both smartphones and tablets. For older version of android/ios, these engines are used for scanning.
· Tosca Mobile Engine 3.0 – It is used to test mobile apps on both smartphones and tablets.
· Tosca SAP Engine 3.0 – It is used to scan and test the SAP applications.
· Tosca Webservice Engine 3.0 – Tosca Webservice Engine 3.0 allows Webservices to be steered via Hypertext Transfer Protocol (HTTP). Webservices using SOAP (Simple Object Acces Protocol) or REST Webservices (Representational State Transfer) can be steered.
· Tosca XML Engine 3.0 – It is used to interact with XML data to change, create or verify the data.
What is the Standard Module?
With the workspace creation, Tosca provides few modules which are used to perform very common operations such that open file, invoke application, string operations, buffer operations, close application, verifications, etc. These modules are known as standard modules. The most important standard modules are –
TBox Automation Tools:
· Basic Windows Operations
· Buffer Operations
· Expression Evaluation
· File Operations
· Folder Operations
· Numeric Operations
· Process Operations
· Resource Handling
· Selenium
· Timing
TBox XEngines:
· Parameter Data
· Database
· Html
· File, XML, JSON
· Mail
· Mobile
· SAP, Java
· Excel
· Pdf
· Host
Test Data Service:
· TestData – Find & provide record
· TestData – Create & provide new record
· TestData – Update Record
· TestData – Move record to TDS type
· TestData – Delete Record
· TestData – Update type
· TestData – Expert Module
Tosca Scan:
Scanning through Tosca is an approach to create Tosca modules which contain all the technical information for any test application.
Step-by-step guide of Tosca Scan to create a module:
We can initiate Tosca scan either right-clicking on Module folder or selecting the dynamic menu Modules and click on Scan icon. In this application, we will learn the scanning with a sample web application.
tosca modules – scan options
Tosca Scan – Classic Modules:
Tosca wizard is a part Tricentis Tosca and used for classic scanning to create classic modules. Generally, for legacy applications which are not properly compatible for TBox Scan, we are using this approach of scanning. We can open the Tosca wizard as a standalone application from Start Menu or by selecting the option “ScanMore->Legacy Scan” during scanning. Please click here to read more on this topic.
tosca modules – classic wizard
Main Navigation Panel – Shows the scanned controls.
Automation Property – Mandatary technical information about the selected controls.
Scan – Start scanning of the entire region.
Scan Region – Scan selected region.
Create Module – Save to create a module for the scanned region. Classic modules are looking like below image –
tosca modules – custom classic module
Tosca Scan – Tbox Module:
Tosca XScan is a part Tricentis Tosca and used for TBox scanning to create Tbox modules. During the scanning, we need to select the engines based on the test application. Scanning steps –
Step# 1: Go to Modules section and select scan path “ScanàApplication”.
Step# 2: Select the test application from “Application Selection” screen and click on Scan button.
Step#3: Xscan screen will be displayed. Here all the available controls are shown here along with technical properties of each of the controls. Based on the properties selected, the control is getting identified by Tosca. There are four different ways to identify the controls –
Identify by Properties – Here based on the technical properties of the test object, controls are getting identified. Always we should prefer technical properties like name, id, class, test, inner text to recognize the controls in the application.If the properties are not enough to identify any particular controls, we should go for other “Identified by” options which are available in Tbox Scan.
Identify by Anchor – In this method, we need to identify the test object with the reference of any other object which was identified uniquely. It uses algorithm Shortest Path or Coordinate for referenced controls. Here, we need to follow the options after clicking on “Select on Screen” button.
Identify by Image – Based on the image view of the test object. We can allow Tosca to recognize the control. But this is not a preferred method, and it should have opted at the last when all other options are not able to recognize the test objects.
Identify by Index – Index is basically the number of occurrence of the test object. It’s denoted by numeric value, starting with 1.We can highlight the selected controls using the “Highlight selection” option. Also, we can directly select a control from the application itself by choosing the option “Select on Screen”. Once the object identifies uniquely, we need to click Save or Finish Screen icon (available in the left top) to create a module.
Step# 4: Click on “Finish Screen” to clear the current scanned information. After this, click on Start Screen option to start afresh scanning of a new page.
tosca modules – Identify by properties
tosca modules – Identify by Anchor
tosca modules – tbox scan image
tosca modules – Identify by index
tosca modules – custom tbox module
Conclusion
In this article of Tricentis Tosca Tutorial, we have covered about Tosca Workspace Creation so that we can start with working with Tosca Commander. Need more information, please click here to visit Tricentis Support portal.
