“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.
Good post, Joe. I’ve always been a fan of function-based frameworks. I avoid Actions whenever possible. I figure those are meant for people who use the “Keyword” view of QTP to attain function-like capabilities.
One interesting topic for any framework involves the target audience, and users looking to apply something like this will surely want to know who authors most of the tests with this framework. How successful have you been getting non-scripters to still consume your framework, what have been the challenges, what have you overcome, and what still remains?
Boyd Patterson » Hi Boyd – good question. To be honest getting non-scripters to use any form of automation has always been a challenge for me. At my current job I’ve created an automation framework WIKI with intro videos, done many company wide demos, and have an open invention to show anyone who wants to learn how to get started but still have not had much success in getting people to use the tools. We also recently finished up what seemed to be a successful pilot of a BPT framework but it too has been slow to take off. Not sure why this is. This year I’m trying to use baby steps like having the manual testers at least start running the test sets I have setup in QC for their automated regression tests. How about you? Do you have any tips that would help get this process going? Cheers~Joe
I agree, this is a great article, we too use a function based approach and it works very well. One thing I wanted to ask is what do you feel the benefits of descriptive programming are over using the OR. We use descriptive programming for those objects that the OR can’t or won’t recognize but the rest of the time when the OR works fine it is used. Using the OR means there is one place to make changes if something in the app changes. As some of our automation is done during development of the application we can see some pretty large changes that would require rewrites to descriptive programming. Is it just a speed issue, i know QTP had issues with large OR’s but that appears to be resolved a while ago?
Greg Woffindin » Hi Greg,
Our application comes 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 app has literally hundreds of screen and thousands of fields. We also did have performance issues with OR’s larger then 3 MB. Because of this and because or apps screens and fields never change we felt the mix OR was the best solution.
I’m not against using a full OR. I agree if you have an application that has screens and fields that often change the OR is the way to go.
Thanks for your feedback!
Cheers,
Joe
Joe, Great topic! We use shared OR, reusable actions, and function libraries. Lately we are using more function libraries. Easier to maintain and use. Two questions: Do you save your function libraries in QC Test Resources? Or do you just put them on the QTP host machines file system? With the shared OR methhod, is it better to have many small SORs or s few large SORs? How large is too large?
Paul » Thanks Paul! We do store all our test artifacts in QC. So our function libraries and ORs are all under QC resources. Good question about ORs I can’t say I know for sure what the right answer is – I guess its depends. If prefer to have larger Ors but you also don’t want to have them so large that they become hard to maintain and start creating performance issues. I’m going to HP Discover this year and I will definitely ask a QTP engineer what the best practice is and what is considered large. Last I checked (4 years ago) with HP they recommended to keep the OR size below 3 MB. Ours was up to 4.5 and was creating performance issues for us. Cheers~Joe
I hope you post a summary of your trip to HP Discover. I went to Mercury World in 2006 – It was awesome!
Nice one Joe.I took a lot of time in understanding this when I was working with you.Your scripts really helped me understanding automation as a whole.I am currently based in Delhi,will start working with Test complete shortly.Keep posting..
Thnanks,
Malay
Malay » Thanks Malay! We miss you at GE :) Hope you learn a lot at your new job and share it with us! Cheers~Joe
Thank you very nice tutorial
QTP Framework, or in general a Test Automation Framework, is nothing but a set of guidelines which you can follow during scripting to achieve the above mentioned ‘desired’ results – See more at: http://www.automationrepository.com/2012/03/qtp-framework-types-an-introduction/#sthash.6EQUnLrt.dpuf