HP Unified Functional Testing (QuickTest Professional + HP Service Test)
Can’t wait/afford to get your consultants up to speed with different testing tools? Need to quality assure your applications and want something that integrates seamlessly with other popular HP ALM products like HP Quality Center Enterprise? Struggling with automated testing products that only work with websites? Contact our HP experts today about HP Unified Functional Testing or scroll down for more information on what it does, why it’s useful and its key features.
What it does
HP Unified Functional Testing (UFT) software is HP's main automated functional testing tool and incorporates the features of various important legacy products such as QuickTest Professional, WinRunner, and HP Service Test. UFT automates functional tests by recording the actions of a user on the system under test and replaying the actions on demand to execute a test. The recorded actions are stored in UFT as a simple program known as a script. Scripts can be displayed in UFT either as a Visual Basic Script (VB Script) program (expert view), or as a sequence of steps labelled by icons (keyword view). The tool can test the success or failure of any step with a 'checkpoint', which compares the actual result produced by the system under test at the time of execution, with an expected result stored in UFT at the time of recording.
Why it is useful
HP Unified Functional Testing (UFT) enables functional tests to be carried out automatically to increase the speed and cost effectiveness of application development and delivery. After an initial investment of effort to record and configure a script, the script can be run again and again to verify the functionality of an application under test. This can yield considerable savings in time and money over manual testing. UFT is especially useful for regression tests, i.e. tests which check that the existing functionality of an application still works as it should after other parts of the application have been modified. Like all automated functional test tools, UFT is less well suited to one-off tests or first-time tests of new applications or functionality because the effort of creating a UFT script is at least as great as that of conducting a manual test.
For large applications with regular release cycles, a set of UFT tests can be created for regression testing. Such a set of tests is often known as a 'regression pack'. With each release of the application under test, the regression pack is run to check the existing functionality, thus freeing the test team to focus on manual tests of the new functionality and /or creating new UFT scripts to test it. The regression pack will normally execute tests much faster than a team of manual testers and can also be set to run out of hours.
Outside the domain of testing, UFT can also be used as a 'robot' to automate a variety of repetitive tasks which would otherwise have to be carried out by a human user.
HP Unified Functional Testing (UFT) records the actions of a user on the system under test. Unlike LoadRunner, which records only the network traffic between client and server, UFT records each user action on the graphical user interface (GUI). UFT can record at various levels of granularity. Normally it records only the substantive actions of the user, for example that a button has been clicked. At the finest granularity, UFT records every mouse movement, click and keypress.
The first method is normally preferable because when using it, UFT does not record unnecessary actions and it recognises the objects with which the user is interacting (buttons, fields, menus etc). Object recognition is advantageous because it enables UFT to check the status of an object, for example the contents of a field or whether a button is enabled, and it is not dependent on the vagaries of window location and sizing and screen resolution. High granularity recording is useful where the user is not interacting with discrete, well-defined objects. Examples include drawing programs, flash animations and programs whose internal design does not make use of objects to represent on-screen controls.
A typical application window or web page consists of a collection of objects such as editable fields, buttons, menus etc. In normal recording, UFT recognises these objects and stores representations of them in a repository (the Object Repository). UFT refers to the repository during playback to reproduce the user's actions on each object. It looks up the object's details in the repository and uses the information to reproduce the user's action on the object. Using the details in the repository, UFT is able also to check the status of an object.
When recording user action in the finest granularity, objects are not stored in the repository because the recording is based on literal mouse movements, mouse clicks and key presses.
For teams of testers, each copy of UFT can be configured to use a shared Object Repository. This ensures that the objects are recognised and named consistently across all tests performed by the team which leads to quicker and more cost effective IT project delivery.
UFT is able to recognise a wide range of objects including those which exist in an application which is embedded in another, such as an ActiveX or Java component embedded in a browser.
Checkpoints are the means by which UFT determines whether a test has passed or failed. A checkpoint is a point in the script where UFT stops to compare the actual state of a particular aspect of the application under test with the expected state. The expected state is defined when the script is created. There are several different types of checkpoint, each of which compares a different type of data. The types of checkpoint include checkpoints which verify object status, the presence of text strings on a web page, the presence of a bitmap in a particular place on the screen and the presence of expected data in an application's database.
If the actual result of a check matches the expected result, the check passes; if it does not, the check fails. The pass or fail is recorded in the result of the test. Checkpoints are inserted as desired by the tester after the initial recording. A script may have any number of checkpoints.
Scripts in UFT can make use of dynamic data. A script may be set up to perform an action repeatedly, each time for a different customer. For example, in an online bookshop, a script may be created to order a book and set up to run repeatedly ordering a different book each time. Dynamic data, in this case a list of book identifiers (title, author etc), is stored in UFT's built-in data table. Data may be entered into the data table manually, or imported from outside sources such as Excel spreadsheets and ODBC-compatible databases (which include Oracle, MS Access, and SQL Server).
Parameters can also be used to extract data from the test. In the above example, it might be useful to store the order number for each book purchase. This can be done using an â€˜output parameter'. The values of output parameters are stored in the test results and may be exported to other applications.
The HP Unified Functional Testing solution allows playback to be viewed as an animation. This is useful for (amongst other things) debugging. A tester can use the animation to see exactly what actions were performed on the system by UFT and exactly how the system reacted.
The solution features may have evolved with the introduction of the HP Unified Functional Testing (UFT) solution but our highly skilled teams are still ahead of the software lifecycle curve and as industry leaders in automation we'd be delighted to field any questions you might have about the product, just drop us a line.
The product can be licensed per copy or through a concurrent licence. A concurrent licence allows UFT to be installed on several different machines, but limits the number that may run UFT at any one time to the number of licences purchased. Each machine connects to a licence server which enforces the limit on concurrent users. A concurrent licence typically costs about 40 per cent more than a seat licence.