CS-6306 UNIFIED FUNCTIONAL TESTING

Preparing to Record Page|1

Module 003 –Preparing to

Record

“Quality is never an accident; it is always the result of

intelligent effort.”
– John Ruskin

Overview of the Course

At the end of this module, you should be able to:

 Create basic scripts from a manual test case

 Enhance basic tests with synchronization and

verification
 Parameterize tests to run with multiple sets of data
 Create and reuse modular actions

 Use the Object Repository

 Use debugging tools

 Write custom checkpoints to create more precise
verification points within a test
 Use the Object Repository Manager
 Resolve object recognition problems

Researching beyond the coverage of this module is highly

encouraged to supplement your understanding of the topics
covered. Always, think and see beyond the box.

The citation provided is a guideline. Please check each citation

for accuracy before use.

So, what are we waiting for? Let us now explore the Unified
Functional Testing 12.0
CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record Page|2

Module Objectives:

After completing this module, you should be able to:

 Identify functional testing principles, and the benefits of

automated testing

 Navigate the typical GUI testing workflow

 Document the steps of a business process

 Prioritize business processes using effective criteria

 Gather sufficient test data

 Prepare the test environment for automated testing

Approaches to Functional Testing

The following approaches can be used for functional testing:

 Manual testing – To verify if the AUT performs the

designated tasks, you manually execute a series of tests.

 Automated testing – To verify if the AUT performs the

designated tasks, you automate a series of tests that
run without human intervention.

Drawbacks of Manual Testing

Requirement for Automated Testing
Manual testing is time-consuming and tedious, and
requires a heavy investment in human resources. Worst of all,
time constraints often make it impossible to manually test
every feature thoroughly before the application is released.
This leaves you wondering whether serious bugs have gone
undetected
CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record Page|3

Benefits of Automated Testing

Automated UFT for GUI Testing addresses the problems by
dramatically speeding up the testing process. You can create
tests that check all aspects of your application or Web site,
and then run these tests every time your site or application
changes.

 Fast – Automated tests are significantly faster than

human users.

 Reliable – Tests perform precisely the same operations

each time they are run, thereby eliminating human
error.

 Repeatable – You can test how the Web site or

application reacts after repeated execution of the same
operations.

 Programmable – You can program sophisticated tests

that bring out hidden information.

 Comprehensive – You can build a suite of tests that

covers every feature in your Web site or application.

 Reusable – You can reuse tests on different versions of

a Web site or application, even if the users interface
changes.

Selecting Tests to Automate

Regression testing is any type of software testing that
seeks to uncover new software bugs, or regressions, in
existing functional and non-functional areas of a system after
changes, such as enhancements, patches or configuration
changes, have been made to them.

Data Driven testing is testing the functionality with

dynamic input from UFT for GUI Testing. When we record, the
values become static. In Data driven test we convert that
static value to dynamic so that we can give as many inputs we
want to see the functionality is working for different inputs.

Smoke Tests are the tests conducted immediately after a code

migration to ensure basic functionality of the application is
intact.
CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record Page|4

Do automate:
 Tests that run with each new version of your
application to check the stability of basic functionality across
the entire application (regression tests).

 Tests that use multiple data values for the same

operation (data-driven tests).

 Tests that are run many times (stress tests) and tests
that check a multi-user client/server system (load tests).

Do not automate:
 Tests that are executed only once.

 Tests that require immediate execution.

 Tests that check how easy the application is to use

(usability tests).

 Tests that do not have predictable results.

GUI Testing Workflow

The general workflow of the GUI testing process involves six
main stages.

Stage 1 – Analyzing Your Application

Before you begin creating a test, you need to analyze

your application and determine your testing needs. You need
to:

 Determine the development environments in which

your application controls were developed. Development
environments might include Web, Java, or .NET, and so on.
You must load the required UFT add-ins when you open UFT,
and before creating your test.

 Determine the functionality that you want to test. To do

this, you consider the various activities that customers
perform in your application to accomplish specific tasks.
CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record Page|5
Which objects and operations are relevant for the set of
business processes that need to be tested? Which operations
require customized keywords to provide additional
functionality? Decide how to divide these processes into
smaller units that will be represented by your test’s actions.
Each action should emulate an activity that a customer might
perform when using your application.

 As you plan, try to keep the amount of steps you plan to

include in each action to a minimum. Creating small, modular
actions helps make your tests easier to read, understand, and
maintain.

Stage 2 – Preparing the Testing Infrastructure

To complete the infrastructure that is part of the planning

process, you need to do the following:

 Learn your application, and identify its business

processes. They will become the building blocks of your
scripts. The more you know about your business processes
before you start the scripting process, the more structured
your work will be.

 Build the set of resources to be used by your tests.

Resources can include shared object repositories
containing test objects, function libraries, and other
structures discussed in the advanced segment of this
course.

 Configure UFT according to your testing needs. This can

include setting up your global testing preferences, your
run session preferences, any test-specific preferences, and
recovery scenarios. You can also create automation scripts
that automatically set the required configurations (such as
the add-ins to load) on the UFT client at the beginning of a
run session.

 Create one or more tests that serve as action libraries.

You can create an action repository test to store

reusable actions to be used in your tests. Generally, you
create an action repository test for each area of your
application to be tested. Storing all of your actions in
specific tests enables you to maintain your actions in a
central location. You then associate the shared object
CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record Page|6
repositories with the relevant actions. This enables you to
insert steps into the actions using the objects stored in the
object repositories. When you create your tests, you
insert calls to one or more of the actions stored in this
repository. When you update an action in the action
repository, the update is reflected in all tests that contain
a call to that action. When you run a test, only the relevant
action repository tests are loaded.

Stage 3 – Adding Steps to Your Actions

In this stage, you add steps to the actions in your action
repository tests.

Note: Before you begin adding steps, make sure that you
associate your function libraries and recovery scenarios with
the repository test, so that you can insert steps using
keywords. You can create steps using the keyword-driven
functionality available in the table-like, graphical Keyword
View—or you can use the Editor, if you prefer to program
steps directly in VBScript.

You can also add steps to your test using the following
additional methods:
 Drag objects – Drag objects from your object
repository or from the Toolbox pane to add keyword-
driven steps in the Keyword View or Editor. The object
repository and Toolbox pane contain all of the objects
that you want to test in your application. When you
drag an object into the Keyword View, a step is created
in the action with the default operation for that object.
For example, if you drag a button object into the
Keyword View, the click operation is automatically
defined for the step. You can then modify the step as
needed.
 Record on your application – As you navigate through
your application during a recording session, each step
you perform is displayed as a row in the Keyword
View. A step is something that causes or makes a
change in your application, such as clicking a link or
image, or submitting a data form. In the Editor, these
steps are displayed as lines in a test script (VBScript).
The Documentation column of the Keyword View
displays a description of each step in easy-to-
understand sentences.
CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record Page|7

Stage 4 – Enhancing Your Test

 You can enhance the testing process by modifying your
test with special testing options and/or with programming
statements. For example:

 Insert checkpoints and output values into your test. A

checkpoint checks specific properties or other
characteristics of an object and enables you to identify
whether or not your application is functioning correctly.

 Use output values to extract data from your test. An output

value is a value retrieved during the run session and
entered into your data table or stored in a variable or a
parameter. You can subsequently use this output value as
input data in your test. This enables you to use data
retrieved during a run session in other parts of the test.

 Replace fixed values with parameters to broaden the scope

of your test. When you test your application, you can
parameterize your steps to check how your application
performs the same operations with different data. You may
supply data in the data table, define environment variables
and values, define test or action parameters and values, or
insert a step that generates random numbers for current
user and test data.

 Add user-defined functions by creating function libraries

and calling their functions from your test. Function
libraries contain VBScript functions, subroutines,
statements, and so on. You can call functions from your
test, or use functions as operations in your test or
component.

 For complex testing goals – Use other UFT features to

enhance your test, and/or programming statements.

Stage 5 – Running and Debugging Your

Test
After you create your test, you can perform different types of
runs to achieve different goals.
 Debug the test – You can control your run session to
CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record Page|8
help you identify and eliminate defects in your test, as
follows:
 Use the Step Into, Step Over, and Step Out
commands to run your test step by step.

 Begin your run session from a specific step in

your test, or run the test until a specific step is
reached.

 Set breakpoints to pause your test at

predetermined points. You can view or change
the value of variables in your test each time it
stops at a breakpoint in the Debug Viewer.

 Manually run VBScript commands in the Debug

Viewer.

 Test your application – The test starts running from

the first line in your test and stops at the end of the
test. While running, UFT connects to your application
and performs each operation in your test, including
any checkpoints, such as checking text strings, objects,
tables, and so forth. If you parameterized your test
with data table parameters, the test (or specific actions
in your test) repeats for each set of data values in the
data table.
 Update your test – If you know that your application
has changed, run your test in one of the following
modes to update your test accordingly:
 Maintenance Run Mode – Use this mode if you expect
that UFT will not be able to identify the objects in your
test. As your test runs, UFT opens a wizard for each
object that cannot be found in the application, to guide
you through resolving each issue. When the object can
be identified and the issue is resolved, the run
continues.
 Update Run Mode – Use this mode to update the any of
the following:

 Properties used for test object descriptions

 Expected checkpoint values

 Data available to retrieve in output values

 Active Screen images and values

CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record Page|9
Stage 6 – Analyzing Run Results and Reporting
Defects

After you run your test, you can view the results of the
run in the Run Results Viewer, including both a summary and
a detailed report, and you can report defects detected during
the run session.

 View still images or movies – If you captured still

images or movies of your application during the run,
you can view these from the Screen Recorder tab of the
Run Results Viewer.

 Local system monitoring – If you enabled local system

monitoring for your test, you can view the results in the
System Monitor tab of the Run Results Viewer.

 Report defects in ALM – If you have access to ALM, the

HP centralized quality solution, and you can report the
defects you discover to the project database.

 Report defects automatically or manually. You can add

steps to your test that automatically report each failed
step in your test, or you can report them manually from
the Run Results Viewer.

Collecting Relevant Information

CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record P a g e | 10

Ensure You Are Prepared

Before automating a test, you also should identify the

start and end points for each test case. This refers to the state
of the application for the initial and end conditions. An initial
condition refers to the state of the AUT prior to a test run. An
end condition refers to the state of the AUT when a test
completes its run. This will ensure that the test can iterate.

Use the following questions to plan initial and end

conditions for a test:

 Is there a main window where most business

processes start, for example, the search page or
home page?

 What is the state of the AUT that will ensure

most business processes are able to start? For
example, is the login window displayed, or the
home page of the application ready for a new
order?

 If this test is repeated with several sets of data,

does the last step reset the AUT to its initial
condition?

Documenting Business Processes

A business process, sometimes referred to as a
business function or a business transaction, is a segment of
work that a user can perform within an application.
Common business processes include logging in, searching for
and selecting products, adding them to a shopping cart, and
completing the purchase.

Business processes typically do have a beginning and

an end, though it can be difficult to identify those precise points
in an application. Most business processes will consist of three
components:

 A form, wherein the user will supply data

CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record P a g e | 11

 A button, or a control that sends that data to the

application server

 A positive or negative response from the application

server

To completely capture a business process, a script

must capture all of the above components. However, a script
generally should not contain specific steps for navigating to the
screen or page where the business process is located, since
there may be multiple navigation paths that need to be tested.
It is best to control navigation through a separate series of
steps, so the script can assume it should begin executing the
initial steps of the business process (usually entering data).

A script must also end in a condition which is favorable

for it to begin again IF the script is being designed to iterate
through data. Unless the script can seamlessly start at the
beginning, it will fail after the first iteration. For example, if a
script is to repeatedly test a series of logon IDs, that script must
verify each logon then return to the beginning of the logon
process so another ID can be tested.

Prioritizing Business Processes

In an ideal world, there would be sufficient time and
resources to automate every business process. However,
rarely are application teams so lucky, and in fact the nature of
some business processes may make them very difficult to
automate. In fact, business processes each must be evaluated
in terms of the amount of effort that may be required to
automate them, and a select few may reach a point of
diminishing return on that effort.

To help application testing teams select the best

candidates for automation, the team should define a set of
criteria to help identify which business processes will not only
most readily be automated, but also those which are most
important to the business. A core set of criteria should
identify those business processes which are:

 Mission Critical – Functionality without which

users could not operate. For example, without
general search functionality, visitors to a retail
website would be required to know specific
CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record P a g e | 12
product or item codes to purchase products.
Since most consumers would not have this
information readily available, general search
functionality is considered critical to any retail
site

 Data Driven – Those which lend themselves to

processing many combinations of data. The
general search functionality of a retail website
is again a good example of a business process
that might benefit from data-driven testing.
Because visitors to a retail web site will likely
use an exhaustive combination of criteria to
search for products, any automated test must
replicate this behavior. In fact, a well-written
test might not only test an exhaustive
combination of search criteria, but also might
employ random criteria to gauge how the
application responds to unexpected behaviors.

 Dynamic Content – Processes that generate

unique identifiers. While values generated by
an application, such as a confirmation number
or an order number, might seem relatively
simple, the fact is they may require a
considerable amount of back-end effort. For
example, a flight confirmation number
represents not just a completed credit card
transaction, but also a seat reservation, a meal
order, and most likely other resource
allocations unknown to the average passenger

Business processes that fall into these categories

should be considered strong candidates for automation,
especially if they fit into more than one. In fact, using a grid to
document each business process and each criterion then
sorting that grid can be a very effective way to determine
which should receive top priority.

In this simple example, the grid was created by listing

business processes on the left and criteria across the top. Note
that additional criteria were selected because the business
wanted to give priority to those which generate revenue.
Naturally, the system team was also concerned about those
business processes which impact downstream applications,
and those with a high risk rating.

Originally the business processes were listed in an

order which reflected how they were encountered within the
application—Login, then Search, then Purchase, and finally
Itinerary Check. However, upon sorting the grid to move those
CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record P a g e | 13
business processes with the most checkmarks to the top, it
quickly became apparent that the Purchase process required
the highest priority. Consequently, the team will only
automate the Itinerary Check process should there be
sufficient time and resources.

Naturally this grid is only a guideline, and many

additional factors will go into deciding where to focus
automation resources. Certain criteria, such as whether a
business process is required by federal regulation, and even
whether or not a business process generates revenue, may
end up being “trump cards” over other criteria. In the end,
there may be no better criterion than a little common sense
too.

Determining Test Data

Before recording a test, you need to determine the
input data that you will use to test the application.

To determine the nature of input data:

 Interview the Subject Matter Expert (SME) to

determine the valid and invalid input data for
your AUT.

 Determine the extreme ranges of input data.

 Decide what should happen when invalid data

is given as input to the application.

Test data may originate from several sources. Most

commonly, the application’s system or record can provide a
good sampling of data that can be masked (to protect privacy)
and used for input data. If feeds from other applications
contribute to your application data, a special extract may be
necessary to support your testing process.

Another option is to allow UFT to generate the data

using built-in functions that can generate random numbers,
future dates, and other types of calculable data. And finally,
the data might already be present in the application itself,
such as the items in a drop-down field or a series of radio
buttons, in which case UFT can select that data using VBScript
programming structures.
CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record P a g e | 14

Engage Project Contributors Early

Don’t be caught off guard by data that might need to
come from another application. Unless that area has been
engaged as part of your testing process from the beginning,
they might require a lead time to generate that data that could
delay your testing process. It is crucial to engage your SMEs
and application support areas at the beginning of your testing
process to avoid these delays.

For example, if your test requires a number of logon

IDs, and those IDs are managed by your own application
database, then someone on your team will need to create
them prior to the start of testing. But if generating logon IDs is
the responsibility of your data security department, they
might require weeks of lead time and your application might
even incur a charge for the work. Failing to anticipate these
lead times and costs may strain your project budget.

Generate Data Using VBScript Functions

Meaningful data can be difficult to capture, and on

occasion a field may require data values that hold little
significance to the testing process. If a field requires data for
your script to execute properly, but the actual data values are
of little importance, one option is to use VBScript functions
built into UFT to generate the data. For example, UFT could
generate a random series of digits to use in a phone number
field, or a string of characters to use for a customer name.

Utilize Data within Fields

The UFT Data Table provides a convenient and
familiar interface for creating input data, or for receiving data
extracted from the application. It is easy to build extensive
combinations of test data in the Data Table using standard
copy and paste functions, but it’s also surprisingly easy to also
build combinations of data using VBScript statements.

For example, given two dropdown fields containing

departure and arrival cities, it would be easy to create many
combinations of these cities in the Data Table simply by
CS-6306 UNIFIED FUNCTIONAL TESTING
Preparing to Record P a g e | 15

copying and pasting valid cities into two columns. Clearly,

there are potential maintenance issues with this approach
though, because the combinations in the Data Table need to
be updated as service changes between cities.

Again, this is where VBScript can help. In fact, UFT

provides methods that allow a script to extract data from
application controls, such as dropdowns, then VBScript
statements can manipulate that data to create exhaustive
combinations with minimal effort.

References and Supplementary Materials

Books and Journals

Micro. Customized Unified Functional Testing 12.0

Essentials Student Guide
Hewlett-Packard Development Company, L.P.
http://hp.com/software/education