“One Ring to rule them all, One Ring to find them, One Ring to bring them all and in the darkness bind them”
The question of the week comes from Kirti, who writes, “I have seen people asking question about what is your automation framework. I'd really like to know what your QTP framework is, and how QTP framework should be set up.”
I actually get this question a lot. What follows is my attempt to answer it.
First, my Automation Framework rant (you can skip this if you want)
First off, I believe every company/application has different needs with regard to an automation framework.
Sorry, to say it, but there is no “one-size-fits all” framework that can possibly work across a wide range of software application and companies or even across groups within the same company. If one works for a large company that has many unique divisions and someone starts talking about enforcing a one-framework-to-rule-them-all solution that must be used be everyone, be very afraid.
The point of this post is to take you through one approach I implemented and used successfully for my application under test AUT. Your situation may require different needs, and therefore a completely different approach. (You are, of course, free to disagree with my approach, or even say that it sucks if you wish.)
Why I did what I did with my UFT Test Framework
About four years ago I began a job with a new company and based on the technology and skill sets around, I decided to use a function-based approach.
I'll try and describe the pros and cons of this approach and attempt to justify why I made certain decisions.
What do you call your UFT Automation Framework approach?
If I look up “framework” in the book Just Enough Software Test Automation, mine would fall under the Framework-Driven (Structured) Test Scripts approach.
What this basically means is that it has a bunch of functions located in a shared QTP function library.
FAST (stands for Function Action-based Software Testing) is how I like to jokingly describe my framework.
When you use the FAST framework in QTP, you use the functions as if you were using standard QTP command in QTP's VBScript programming language.
Our application is composed of 12 main “component objects“ that we use all the time:
| Object Type | Image |
| Textboxes |  |
| ComboBoxes |  |
| Buttons |   |
| Grids |  |
| ActionCodes |  |
| Dialogs |  |
| Horizontal Toolbars |  |
| Vertical Toolbars |  |
| Headers |  |
| Links |  |
| PopUps |  |
| Labels: | 
|
Each of these common objects has two flavors. One is .NET, and the other is an old proprietary technology called ICW.
How to use the QTP framework
If you wish to begin scripting in QTP using my framework, you'll need to know these three main things:
- field type
- technology type
- the action that you want to perform
For example, if you wanted to enter text in a textbox on an ICW screen, the code would look like this:
TextBoxICW_ENTER “the obj id”,”value to enter”
When a user clicks on the “application keyword pane” icon in QTP
He or she can easily see all the functions and keywords available for use:
In my opinion, using functions rather than QTP Actions is much simpler.
Do you have an Object Repository?
Another decision we made was to use a minimal object repository in QTP. Our application contained hundreds of screens, with some screens containing many objects. The amount of time it would have taken to create an OR would have been considerable.
Our application came in two flavors: a browser version and a thick client version which would double our OR since we'd need to have both included.
The initial approach we used for object recognition in our app was a high-level OR path. We then completed the rest using descriptive programming. Most of the fields live in AUT live under the following two common paths:
- Is at a browser.page.frame.swf level
- Brower.page.frame.swf.activeX level
Therefore, when we call one of the functions in our library, it is basically building the field's path dynamically.
This is a big plus; in large part due to the fact that the framework is smart enough to know if the app under test is a browser or thick client version.
A common automation user login function
All of our scripts utilize a common login function that determines which environment it is running against and writes that info to a textenv.txt file.
The first function called is a zGetPath function that reads from the text file and determines what path to use for the current field.
That's it for my UFT framework
So that's my QTP Framework in a nutshell.
