QTP Action at a glance

“Happy Path” Test Flow

The screenprint above demonstrates sample “Test” Flow designed using QTP Actions.
“Happy Path” testing, or conformance testing, or checking can be characterized by 2 attributes: it is scripted, and it ignores everything that is out of scope. Scripted here does not mean a program written in scripting language. It means a predefined sequence of actions to perform. 

Action-centric design

Test Action is not only a sequence of steps to perform. They have to be supported with GUI mapping information to recognize objects and test data to use.
QTP provides first in a form of Object Repository component. Each Action is provided with one or more components of this type. Default, automatically attached component is called “Local” repository. All GUI objects, captured during recording operations, are stored there. Additional components, that saved in separate files (*.TSR), can be attached to a number of Actions; they are named shared repositories. Attached shared repository appears in the list under its file’s name (“Login.tsr” in the example).
Even if the all object references are written in Descriptive Programming notation, Local Repository remains attached to Action.
QTP provides a built-in Data Model that comes in forms of a workbook (DataTable object) and XML structure (Environment object). These objects are global, i.e. accessible from any Action. In addition, QTP automatically creates a worksheet for each new Action created. This worksheet, named after the Action, is associated with it. That creates a convenience of automatically loading Test Data, associated with Actions. 

Declaration and calling mechanism

As QTP Actions are not regular sub-routines, like functions and subs, they have to be declared; that includes requirement to specify arguments that can be passed into Actions.  

User can specify arguments by type, or leave it as variant (“Any” item in Type selection list). Value of an argument can be defaulted, i.e. if it was omitted in the calling statement the Action will receive the default value. This mechanism represents a limited overloading capacity. (Read more about custom implementation of overloading and defaulting with VBScript.)  

Inside Actions, parameters are accessed through Parameter object.  

Parameter object is similar to Dictionary object, but does not support Count property, and methods like Items() or Keys() .  

Last but not least: ExitAction statement allows returning only a constant value.  

Applicability Notes

The built-in QTP framework is designed for non-programmers trying to implement “Happy Path” testing. For that purpose, it fits perfectly. It takes care of initialization and finalization steps, provides ready-to-go structure for test scripts, automatically loads/unloads data associated with the tests, provides rich checking functionalities. It represents evolution of Enhanced Record/Playback approach.  

It is applicable at its best for the following scenarios:  

• small application or application with small independent functionalities that are not cross-tested;
• simple GUI that experiences no fluctuations from build to build;
• straight and simple business logic, with no or minimal number of pop-up dialogs;
• extremely simple test logic, implementing positive, “happy path” test cases, with no branching or looping;
• static dataset, or extremely small number of test data, hard-coded in QTP worksheets.