Formerly known as HP QuickTest Professional (QTP), Unified Functional Testing (UFT) provides functional and regression test automation. It uses the Visual Basic Scripting Edition (VBScript) as its scripting language. UFT automates testing through an intuitive, visual user experience that ties manual, automated, and framework-based testing together in one IDE. This article is to introduce few basic concepts of UFT Automation.
A brief History
HP QTP was originally written by Mercury Interactive. Mercury Interactive was subsequently acquired by Hewlett Packard (HP) in 2006. In 2012, HP renewed QTP with the new name UFT; during renewal HP’s UFT version was 11.50. UFT 11.5 combined HP QuickTest Professional and HP Service Test into a single software package. The name “Unified” reveals that UFT is an advanced and combined “GUI and API (service)” testing tool. UFT has enhanced, and brand new functionalities that are not available in previous versions of HP Service Test or HP QuickTest Professional. The integrated HP Unified Functional Testing software allows you to test all three layers of a program’s operations: the interface, the service layer and the database layer.
What’s new with HP UFT (over QTP)?
Let’s see some of the new features offered by “HP Unified Functional Testing” over the older version “HP QuickTest Professional”:
GUI + API Test
UFT is a combination of “HP QuickTest Professional” and “HP Service Test” – test three layers of the software applications; the Interface layer, the service layer and database layer. QTP only support GUI testing for Windows and Web applications, but UFT support GUI and API testing both.
Business Process Testing
In addition to GUI and API testing, UFT 12.0 also provides option for Business Process Testing – Subject matter and component-based customized automation testing platform providing new framework (window) to design, create, maintain, and execute the test and manage the data of the test. To work on Business Process Testing, you must have to connect an ALM project with BPT support.
Mobile testing with UFT
UFT provides a better support for mobile testing. With the help of HP UFT Mobile, HP claims that you will be able to create mobile platform agnostic scripts, hence a script created for iOS would be expected to work for Android. The mobile application testing solution will support emulators as well as real devices. The real devices can be sourced from the public cloud of shared real devices and/or private cloud of dedicated real devices.
New Add-Ins – Flex and Qt
These add-ins facilitate users to test GUI part of Flex and Qt applications. UFT Flex add-in is required to test Flex applications or objects. But this add-in faces problems in case of accessing UFT Flex Agent and finding Flex based web applications. Solution – compile a Flex application with a UFT Flex pre-compiled agent. To run Qt applications in UFT, no additional process is required; simply work with Qt applications as like other supported applications by UFT.
With Image-based object identification you can now learn an object’s (or images) different states and convert that into a recognizable object within the object library. It recognizes those objects and applications that UFT do not recognize using simple techniques. It is also helpful in recognizing applications run on remote system.
Multiple script Debugging
This was a much needed and requested feature. You will now be able to debug two or more scripts at the same time from within UFT’s IDE.
You can now directly compare PDF files and run checkpoints on them.
Support for Apple Safari
UFT runs on all main browsers including Apple Safari (on remote Mac PC) but QTP doesn’t run on Apple Safari. Using Apple Safari browser, UFT runs the test on remote Mac PC efficiently due to secure communication between the UFT PC and the Mac PC and detect the browser object during test to take the snapshot.
Improved Debug process
During the test, debugging is an important process of an automation tool.
- Call Stack – see all methods and functions that are presently available in the call stack.
- Loaded Modules – Useful for API testing, displays all .dll files of a particular application executed using API test.
- Threads– This is also for API testing, displays all info about threads presently running as part of the run session.
- Local Variables Pane– Displays all types of variables and their current values.
- Console Pane– During debugging process; run the line of codes written in VB Script language for GUI testing and C# code for API testing.
- Watch– Displays the current value and type of variables, properties or expressions in the Watch pane.
- Debug pane– Displays all values and types of variables, properties, and expressions written in VBScript or C# language.
Applicable for API testing, a small feature, but very much helpful to run any step, function or object displayed on the canvas using the new “Run step” feature. You can access this “Run step” feature by right clicking any object on the canvas.
External authentication for ALM
With UFT 12.0 you can connect to ALM 12.00 server and project by external authentication, such as; CAC (Common Access Card) or SiteMinder. UFT facilitates users to install external authentication certificates or single sign-on mechanisms to avail ALM service, now no need to remember user name and password for the same purpose.
And of course the Icons!
What are your thoughts on this new version with the big name change, overhaul of UI and added features? Know any other added features of UFT? Please mention in the comments below…
Supported OS, Browsers & Free Trial
HP UFT Supports only WINDOWS OS but all the major Browsers like Internet Explorer, Mozilla Firefox and Google Chrome. A 30-Day Free Trial of UFT is available which includes add-ins for ALM, extensibility, and Web 2.0 tool-kits, license server, and a run results viewer. The compressed package still provides full UFT functionality, & is much faster to download – https://lnkd.in/fqUGXmF
Common UFT Components
To start your Automation journey –
- UFT Add-ins
- Objects, UFT Object Spy, Object Model and Object Repository
- Recording and UFT Recording Modes
- Actions, Functions and Function Library
- Data Tables
- Debugging, Error Handling and Recovery Scenarios
- Framework and its Types Short descriptions to follow…Stay tuned!!
Understanding UFT Add-ins
UFT supports automation for wide range of development environment like Windows (.Net, Java), Web, SAP, Oracle, etc. And this is made possible by the corresponding UFT Add-ins you install. I hope you understand the basics of Windows application, Web application, SAP, Delphi, Java application, etc.? It’s nothing but the development environment or the technology used for application’s development. And via Add-ins we are telling UFT in advance, that we want to automate what all type of technologies (Applications).
For example – We want to automate “Facebook” web application. What if we don’t install the ‘UFT Web Add-in’? Simple – UFT will not be able to correctly identify the Web Objects within Facebook, & will try identify them as standard Windows objects (Winobject). Result – Automation failure!
- You can install UFT add-ins (which will be available to select at UFT launch) when you install UFT, or you can install the add-ins at a later time by running the installation again in Modify mode.
- When UFT opens, you can choose which of the installed add-ins you want to load using the Unified Functional Testing Add-In Manager dialog box, but to maximize performance, you should load only the add-ins you need for that testing session.
- UFT includes built-in support for testing standard Windows applications. Standard Windows testing support is automatically loaded when UFT opens.
- Default Add-in:- ActiveX, Visual Basic and Web
After you load an add-in, you can record and run tests or business components on applications in the corresponding development environment. When you work with UFT add-ins, you can use special methods, properties, and various special options to create the best possible test or business component for your application.
Add-ins list – ActiveX, Visual Basic, Web, Delphi, Flex, Java, .NET, Oracle, PeopleSoft, PowerBuilder, Qt, SAP, Siebel, Stingray, Terminal Emulator (for Mainframe applications), VisualAge, Mobile application, etc.
“Objects” – The fundamental building blocks for Automation!
“Objects” are the Fundamental Building Blocks for any Test Automation & its necessary that you fully understand the concept of Objects & Object Identification. In this post let’s see what does “Objects” really mean!
Say you want to open Google in a browser >> Enter a keyword in the search bar >> Click ‘Google Search’ >> Select the first result hyperlink — all this using Automation. What will be your first steps?
- Open browser
- Identify Address/Location bar
- Action: Enter Google.com
- Action: Hit Enter button
- Identify Search textbox
- Action: Enter keyword
- Identify ‘Google Search’
- Action: Click ‘Google Search’
- Identify the first result hyperlink
- Action: Click on the hyperlink
Now every Automation tool (including UFT) uses a “human” like technology for the ‘Identify’ steps above. It’s all about “Objects”. Textbox, Button, Image, Checkbox, Dropdown, Hyperlink, etc. – everything which is visible in an application is known as “Object”. Automation is all about identifying these “Objects” in the application and the subsequent “Actions” to-be-performed on it.
For example a simple statement like
directs UFT to identify Browser with Title ”Google“ >> Page with Title “Google” (within Browser ) >> WebButton with Name “Google Search” (within Page) >> Perform Click action on this button.
UFT Licensing Models
As you all might know – HP UFT is a commercial (licensed) tool. There are two main types of UFT licenses:
“Seat” here refers to a particular machine. Seat License is tied to the “computer on which it is installed”. The trial or a demo license of UFT is a seat license which has a validity of 30 days.
Concurrent License (also known as floating license)
A pool of licenses are assigned to the concurrent license server (installed in your office/local network). Let’s say your company has purchased 50 concurrent licenses of UFT. All these 50 licenses would be assigned to the license server. Now at any point of time, maximum 50 people in the local network of your company can work on UFT.
- Commuter License: a special type of concurrent license which can be used when you don’t have access to the license server. Say you need to travel on work where you can’t connect to your company’s concurrent license server. In that case checkout a license from the concurrent license server for ‘n’ days where n <= 180 >> go about your work >> and check-in back the license to the pool upon return. The duration during which the licensed is checked out, it will behave like a seat license on your machine.
- Remote Commuter License: This is used when you want a license for a particular machine (say D’s machine) but D’s machine is not able to connect to the license server for checkout purposes. In that case, you would take help of a machine (say A’s machine) which is able to connect to the license server and checkout a license for D’s machine.
UFT License is sold to organizations and not to individuals. Typically a Concurrent license is more costly than a seat license. Moreover License cost depends on the region, location, organization, the number of add-ins, etc. It is advisable to get in touch with HP sales representative.
Object Identification via Mandatory & Assistive properties
As stated in previous post – Textbox, Button, Image, Checkbox, Dropdown, Hyperlink, etc. – everything which is visible in an application is known as “Object”. Automation is all about identifying these “Objects” in the application and the subsequent “Actions” to-be-performed on it. But the question is – How do you identify different ‘Objects’ in the application via HP UFT?
For Object identification, UFT needs a way to create a unique ‘object description’ for each object in an application. And UFT uses ‘Object properties’ to create that Object’s description. Let’s take an analogy – Say you want to post a letter to your friend’s house (Object). Can you do that without an address (Object Description)? You will need complete address like House No, Street, Locality, City, State, Country & a Pin code (Object Properties). Hope you got it J A set of Property values >> Object Description >> Object.
Mandatory properties: represents the core object properties.
E.g. Name & Text properties for a Link Object.
Assistive properties: But say more than one object have the same values for Mandatory properties, i.e. mandatory properties are not enough to uniquely identify the object >> Assistive properties are additional properties which will then be used to uniquely identify the object.
E.g. Two links have the same Name & Text but different URLs >> In that case URL is the assistive property.
Ordinal identifiers: indexes of the objects with respect to mandatory and assistive properties.
E.g. Index, Location, Creation Time, etc.
- Fetch all the mandatory properties of the object and check if the unique object description can be created. If not then, continue to step 2.
- Add one assistive property at a time to the object repository and try to create a unique object description.
- If unique description cannot be created then, UFT will use the ‘ordinal identifiers’.
The Basic UFT approach
- At Record time, store some Object properties so that it can be identified uniquely (Test Object: Stored Object & its properties)
- At Run time, identify the object using above stored Object properties (values) – independent of its location on screen (Run-time Object: Run-Time actual object available on the application under test)
- Perform required action on that object
This is HP UFT’s “Test Object Model”. If Object cannot be uniquely identified using above approach, then there are other methods for Object Identification – like Smart Identification. Will talk about those in future posts. Hope this post helped to get a basic understanding of how UFT identifies the Objects!
Most used UFT Utility – “Object Spy”!
The next obvious step is ‘How do you extract the ‘attribute-value’ pair for an object’s properties? This is where “Object Spy” comes to rescue!
Object Spy is a utility within UFT to,
- Highlight the object.
- Adding objects to Object repository.
- Check the properties of object (also to copy that to clipboard). For e.g. values for object attributes like name, class, outertext, etc.
- Check what all the operations can be performed on the object, say click, select, etc.
Object Spy is used to identify an object’s properties to access it through automation script. The general steps are – Click on Object Spy (Hand symbol) >> Hover over the object in the application >> Select it >> Try to highlight (to cross check that correct object is captured) >> Add to OR / Copy to clipboard / Check properties or operations that can be performed on object >> Use it for Automation scripting.
Object Repository – collection of objects and its properties!
‘Repository’ is a generic term meaning a central location in which data is stored and managed. And why would someone need a central location? To access data from a single source of truth, which can be accessed across-locations by multiple users. Now apply the same concept to Automation.
Say you want to test multiple application flows wherein some objects are referenced in each flow. What does your logic say? Yeah! To have a repository of these objects & access it for different flows. Now what should this repository contain w.r.t. Automation Testing? Yeah, as you would have guessed – Objects & their properties so that UFT can refer repository to identify these objects during run-time.
Object Repository is a collection of objects and its properties with which QTP will be able to recognize the objects and act on it. These objects and properties play a vital role in UFT, without these two things UFT could not play back the scripts. When a user records a test, the objects and its properties are captured by default.
Object Repository Types
UFT stores test objects in following types of object repository files,
- Local Object Repository: Object Repository applicable only for that Action. Local Object Repository is preferable when application is not dynamic with respect to time. These objects are stored within a “.BDB” file and the default file name will be “ObjectRepository.bdb”. As the name suggests these files are local to particular action and for each action there will be a separate “.BDB” file. This is the default OR in QTP. Resources >> Object Repository
- Global / Shared Object Repository: The Object Repository that is shared across actions/modules which would be mapped for two or more actions. Shared Object Repository is preferable when application is dynamic and object description change frequently. Resource >> Object Repository Manager
- Per Action vs. Across multiple actions
- Available for each test by default VS. Usually used in Frameworks
- Editable VS. Read-only by default (can be edited using OR Manager
- Extension .bdb VS. .tsr
- Should be used when not many tests are working on the same screens of the application under test VS. Should be used when there are different scripts interacting with the same type of the object
One of the important aspects when planning your tests (or choosing a framework for your project) is to consider where and how you want your objects to be stored and how they have to be made available to the tester. To maintain ORs in your test there is a specialized Object Repository Manager that QTP provides. It can be accessed from the menu item “Resources->Object Repository Manager” (CTRL+R OR Click on Object Repository button).
Ease of Automation with different Recording modes
During automation, there will be cases when we need to record object using its properties, or continuous mouse movements, or object’s co-ordinates, or to record images of the object. The purpose defines the type of UFT Recording mode you select.
Record and Playback
Recording a test corresponds to recording the user actions of the application under test so that UFT automatically generates the scripts that can be played back. It is used as the preliminary investigation method to verify if UFT can support the technology/application and to create a test script to check the basic functionality of an application that does not require long-term maintenance. It is one of the start point for any Automation, post which the scripts are enhanced with Object repositories, Checkpoints, Parameterization, etc.
Records the objects (using its properties) in the application and the operations performed on them. This mode is the default and takes full advantage of UFT’s Test object model.
‘Record’ (menu bar option) >> ‘Record’ | Select “Record” option from Toolbar | Use short cut key “F6”
Record the exact mouse and keyboard operations you perform in relation to either the screen or the application window – UFT records and tracks every mouse movement as you drag it around a screen or window. This mode is useful for recording operations that cannot be recorded at the level of an object, for example, recording a signature produced by dragging the mouse. Note: You cannot edit analog recording steps from within UFT. The main funda behind this recording mode is it records continues mouse movements in the form of a track and save this track file on your computer.
Records at the object level and records all run-time objects as Window or WinObject test objects. Use low-level recording for an environment or on an object not recognized by UFT. The recording is done on the bases of co-ordinates not its properties and i.e. QTP/UFT records the co-ordinate location of the object on which action has been performed.
One of the main competitive advantages of HP Unified Functional Testing (UFT) is its wide support for different technologies. But even after supporting multiple technologies, there are always technologies that that are too rare or complex for UFT to identify objects based on its properties.
In order to bridge the gap, UFT 11.50 introduced Insight, an image-based form of automation. Insight uses an image in order to identify a test object and is fully integrated into UFT so it can leverage the full range of UFT capabilities such as Record, Learn and Visual Relations Identifiers to name but a few. Insight can be used on unsupported technologies such as Flash, or even on a remote desktop connection. An Insight Object’s description is based on an image, instead of its properties. UFT inserts the actual image of the test object into the script, which has the added benefit of making the test understandable and maintainable.
Double clicking the Insight image will open the test object in the object repository. Insight does not use simple image matching. Instead, Insight looks for controls that are similar to the image in the description. The best match is always used.
- The first preference should always be Normal recording mode. Use Analog or Low-level recording only when normal recording mode does not accurately record your operation.
- Analog recording and Low-level recording require more disk space than Normal recording mode
UFT Scripts Storage
Any idea where UFT scripts are stored? Nah! Not in UFT…UFT is just an Automation tool with no scripts database. The scripts are either stored in HP ALM (if integrated with UFT) or else you need to save scripts @ Local / Shared drive. There are many threads/discussions/utilities/tools to help in transferring scripts from Drive to ALM or vice versa!!
Start Scripting | Working with Actions
UFT action is a component in which you can write your code, i.e. code for a specific functionality. Scenario: Say you want to send a mail from Gmail & then logout. What would the steps be for this Test script?
- Login to Gmail
- Compose an Email
- Send Email
Keeping actions in mind, now our UFT Test script for above scenario will be like,
- Call Action1: Login to Gmail
- Call Action2: Compose an Email
- Call Action3: Send Email
- Call Action4: Logout
As you may notice – Actions help to divide the Test script into logical units or business flows. In fact, a UFT Test script is itself a collection of one or more actions. Each Test case in UFT consists of one or more actions and the flow of the Test case is determined by the order of action calls.
Different Types of UFT Actions
Based on reusability
- Reusable Action – can be called from any Tests (by setting the Reusable Flag in Action properties)
- Non-reusable Action – can be called only once and that too in the Test where they are stored.
Based on where the actions are stored
- External Action – stored in some other Test case. External actions should be reusable otherwise it can’t be used outside the Test case.
- Internal Action – stored within the same Test case. This action can be reusable as well as non-reusable.
By default when a script is created it consists of only one action. But you can add more Actions to your UFT Script as per requirements.
The entire purpose of creating Actions is to use them in other Test Scripts.
- Call to COPY of an Action: The action is copied in its entirety (including checkpoints, parameterization, and the corresponding action tab in the Data Table) into the calling test. As it is copied, it is editable in the calling test.
- Call to an EXISTING Action: Calls to reusable actions from another action. Since it is just a call – original action is read-only in the calling test. They can only be modified in the test in which they were created.
- Readability: A Test script can be read Action by Action in the order of calling
- Reusability: Actions can be used within multiple scripts to verify the same functionality (like Login)
- Modular: By creating tests that call multiple actions, you can design tests that are more modular and efficient.
- Efficient: HP UFT Actions enable you to parametrize and iterate over specific elements of a test.
- Maintainability: Make it easier to modify steps in one action when part of your application changes.
- Debugging is very easy i.e., finding logical errors in the script
A Test comprises calls to actions. When you create a new test, it contains a call to a single action. For every action called in your test, QTP creates a corresponding action sheet in the Data Table so that you can enter Data Table parameters that are specific to that action only.
Introduction to UFT Functions
If you have segments of code that you need to use several times in your tests, you may want to create a function and then call that function from within the main action. Say you want to display a message box repeatedly >> Just create a function and reuse it every time. By using functions, tests are shorter, easier to design, read and maintain.
MsgBox “This is a Test Function”
Please note UFT has some built-in functions and methods that might help testers during test. But there can be a situation where user performs some important task that is not available by default. In this case, we can create a user-defined function and save it in a function library file to re-use.
General Steps: Create New Function Library >> Write Function Code >> Save >> Associate Function library with your test >> Call the function within your test as many times as required.
- A Function Library can contain multiple functions, sub procedures or modules
- Associating a function library with a test permits user to call any of the functions in the function library from that test.
Don’t know programming? Use the Keyword view!
View – the ability to see something or to be seen from a particular perspective. In UFT context, it is the GUI view to facilitate automation scripting. What if I tell you that apart from general code editor UFT also offers a Keyword view for non-programmers? Yeah! As simple as that. But let’s first look at the code editor or the ‘Expert view’!
In laymen terms – Expert View is the editor where you actually write a VB script code, i.e. each line represents a Test Step in VB Script. For e.g.
In the Expert View, UFT displays each operation performed on your application in the form of a script, comprised of VBScript statements. The Expert View is a script editor with many script editing capabilities.
The Keyword View is comprised of a table-like view where each step is a separate row in the table and each column represents different parts of the steps. You can modify the columns displayed to suit your requirements. When you add or modify a step, you select the test object or other step type you want for your step, select the method operation you want to perform, and define any necessary values for the selected operation or statement. Working in the Keyword View does not require any programming knowledge.
- Item Column contains the item on which you want to perform the step. This column uses icons displays the hierarchy of the GUI object on which operation is performed
- Operation Column contains the operation to be performed on the item.
- Value Column contains the argument values for the selected operation,
- QTP automatically documents each step for easy understanding in the Documentation Column
- These 4 columns are default but you can also use assignment & comment columns in Keyword View
Each operation performed on your application during a recording session is recorded as a row in the Keyword View. That’s all to the Keyword View
If you compare a line of script in QTP, you will observe that the same object hierarchy is displayed in both Expert & Keyword Views and they map to the same operation and argument value. Essentially, Keyword & Expert view contain the same data but arranged in different format. Advanced testers can view and edit their tests (code) in the Expert View. If you focus on a specific step in the Keyword View and switch to the Expert View, the cursor is located in that corresponding line of the test. Any changes made in the Expert View are automatically synchronized with the Keyword View.
Parameterization using ‘Data Tables’ | After all the scripts need ‘Test Data’
Say you are testing a payment initiation form. One of the most important pre-requisite is to have relevant ‘Test Data’ in place, i.e. the values you are going to fill in the form attributes. Now think of it from UFT Automation perspective. What are the options? Hard-coding these Test data values in your automation script is one of them. But what if you need different sets of data for each run of the test case? Yeah! There is no sense in updating the code for each & every run. Then how do you achieve automation? Or how do you tell UFT which data to use for Test runs?
The answer – “Parameterization”!
Parameterization is nothing but telling UFT to how & from where to fetch the Test Data for running the Test cases. One of the simplest method for parameterization is using the “Data Tables”! Data Table is just like Microsoft Excel file, viewable in UFT. Parameterize your test so that it run ten times, each time using a different set of data (row by row). Each iteration should begin with the AUT being the same state and ending in the same state. Always try to return your application to the state where it began.
We have two types of Data Tables:
- Global: available to all actions in the test
- Local: available to the corresponding action
To execute a particular test case for specified number of iterations, one can set the iterations of global data table in the Test Settings dialog, that can be accessed using File >> Settings >> Run (Tab)
Data Table Object Model
This means that in UFT – ‘Data Table’ is also an Object, i.e. it also has associated properties and methods. Similarly DTSheet and DTParameter are also Objects.
Import and Export Excel Sheet into Data Table
DataTable.Import(“C:\Users\Deepanshu\Documents\Project_Work\HP Project\Automation Work\HP TestAutomation\Data Files\SupportUFT_Page.xls”)
DataTable.Export(“C:\Run-Time DataTable.xls”) >> Export run-time data table in “Run-Time DataTable.xls”
Read Data from Data Table
From Global Data Table
- Value(“ColumnName”, dtGlobalSheet)
- Value(“ColumnName “, 1)
- Value(“ColumnName “, Global)
From Local Data Table
- Value(“ColumnName “, dtLocalSheet)
- Value(“ColumnName “, 2)
- Value(“ColumnName “, “Action1”)
Types of Data Table
- Design Time: While scripting in UFT, you enter test data directly in the data table displayed in UFT (View >> Data Table).
- Runtime:Used while running the test. It can be same as design time data table and/or can be entered by importing data from excel sheet, text file etc. It may contain values that are changed during script execution and can be seen in the ‘Test Results’ window when run session ends. The changes made to the data table during the run-time are not saved to design time data table. Data like parameterized output, checkpoint values, and output values are stored in the Run-time Table. It is an .xls file which is stored in the Test Results Folder. It can also be accessed in the Test Fusion Report.
Checkpoints | Expected vs. Actual values
Checkpoints, as the name says it all, it refers to a validation point that compares the current value with the expected value for specified properties of an object or current state of an object with the expected value, which can be inserted at any point of time in the script. If the current and expected value match it generates a PASS status otherwise FAIL status.
- Standard: compares the expected values of object properties captured during recording to the object’s current values during a run session.
- Bitmap: Verifies the bitmap of an image or a full web page. It does a pixel by pixel comparison between actual and expected images. Bitmap checkpoints are supported for all add-in environments.
- File Content: Verifies the text in a dynamically generated or accessed file such as .txt,.pdf.
- Table: Dynamically verifies the information within a table (contents of cells of a table (grid) appearing in your environment). Not all environments are supported. You can also check various table properties like row height, cell width and so on.
- Text: Check expected text in a web-page or application. This text could be from a specific region of the application or a small portion of text displayed.
- Text Area: Verifies if the text string is displayed within a defined area in a Windows-based application, according to specified criteria.
- Accessibility: Verifies the page and reports the areas of the Web site that may not confirm to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines. These Guidelines make it easy for disabled to access the web. For example, check if the images on a Web page include ALT properties, required by the W3C Web Content Accessibility Guidelines. Accessibility checkpoints are supported for the Web add-in environment.
- Page: A Standard Checkpoint created for a web page. It is used to check total number of links & images on a web page. Page Checkpoints can be used to check Load Time i.e. time taken to load a web page. It can also check for broken links.
- Database: Verifies the contents of a database accessed by the application under test. It creates a query during record time and database values are stored as expected values. Same query is executed during run time and actual & expected values are compared. Database checkpoints are supported for all add-in environments.
- XML: Verifies the content of the .xml documents or .xml documents in Web pages and frames. The XML Checkpoint option is supported for all add-in environments.
- Image: Enable you to check properties like source file location of a web image (XML Data, XML Schema, XML Data, etc.). Image checkpoints are supported for the Web add-in environment.
When the user wants to insert a checkpoint, one has to ensure that most of the checkpoints are supported during the recording sessions only. Once the user stops recording, checkpoints are NOT enabled.
Viewing Checkpoint Properties
After Inserting, in case a tester want to change the values, we can do so by performing right click on the keyword ‘checkpoint’ of the script and navigating to “Checkpoint Properties”.
- By default, the checkpoint name receives the name of the test object on which the checkpoint is being performed. We can change the name of the checkpoint if needed.
- You can locate the same checkpoints in object repository as well. It exactly shows what type of checkpoint and what are the expected values, time out values.
- After we add a checkpoint, UFT adds a checkpoint to the current row in the Keyword View and adds a “Check Checkpoint” statement in the Expert View.
- Standard checkpoints can be created for all supported testing environments (as long as the appropriate add-in(s) are loaded).
Hope this article was of help. If Yes, don’t forget to share with friends & colleagues!