From all the QTP Framework articles that we have posted on this blog till now, this series of articles (about the hybrid framework) is be the most important one. The sole reason for this is –

“Hybrid framework is the most commonly used framework in test automation projects.”

So, if you learn this and get it right, then you would be in a position to work on automation projects in your organization. With this, let us now start with the basics of the QTP hybrid framework.

What is Hybrid Framework in QTP?

Each and every framework type in QTP has its own positives and negatives. You can take the positive points from each of these frameworks and create a customized framework that suites your requirements. This customized framework is called a hybrid framework.

So, in very simple terms – “A hybrid framework is a framework that is created by combining together the features of the different types of QTP frameworks.” This is depicted in the image shown below.

Is there any specific predefined structure of a Hybrid Framework?

Well, a straightforward answer for this question would be – No. Let try to understand why it is this way? In the previous section, you had read about what a hybrid framework actually is. There are two key takeaway points in that explanation –

• 1) A hybrid framework is a collection of features from the other framework types.
• 2) A hybrid framework is one that suites your requirements.

Now, the second point mentioned above is very important. The hybrid framework that you create should suite your requirements or your stakeholder’s requirements. And there can be a lot of factors that influence your decisions. For example –

• – you might want to use a particular feature in your hybrid framework but it might not be useful or necessary for the application you are testing. Example – you might want to use excel sheets to store test data. But in case your application takes the same data every time, it makes more sense to hard-code the data in your code itself or maybe taking it as environment variables
• – you might have a disliking for certain features and hence you always tend to use the features that you like. For example, I’m more biased towards functions and hence I tend to use them more than say, using action calls
• – your client may have a preference towards certain type of framework as they would have seen a similar sort of framework being used previously. So if you can convince the client, then its well and good, else you would have to stick around with what they have suggested (this is something that I have had to deal with in few of my automation projects)

Taking all the above points into consideration, you can safely say that the features that you select to create your hybrid framework may vary vastly from someone else’s framework. And hence, there is no predefined structure of this type of framework. To sum it up, different hybrid frameworks should be like –

But there are certain components (or features) that frequently appear in different hybrid frameworks. These components would be the ones that we would use to create the sample hybrid framework.

Is it easy to identify Hybrid Frameworks?

Well, its easy but not that straightforward to identify a hybrid framework. An important reason for this is that the implementation of hybrid framework varies from person to person and from project to project. But you had also seen in the beginning of this article that most of the frameworks implemented in live projects are in fact hybrid frameworks.

Hence, any good framework worth its salt should be a hybrid framework. And to identify it properly, you need to have a close look at its architecture and its components. You should try to find out if its using keywords extensively, or if its taking its data from excel sheets, or if the code is written in modular format. This way, you would be able to identify the framework types from which the hybrid framework borrows its features.

Useful Tip: Whenever you create or use a hybrid framework, don’t just call it a hybrid framework. Always try to include the names of the other frameworks from which your hybrid framework has derived its features. For example, you can call your framework as –

• – a hybrid framework based on functional and data driven approach
• – a keyword based hybrid framework
• – a hybrid framework implemented with functional and keyword driven components
• – or any other fancy terms that come to your mind

Its always considered a good practice to call your framework this way.

A word about BPT Framework: A good BPT framework will also not just be a BPT framework alone. It would also incorporate the features of a keyword driven, data driven or modular framework in it. And if that’s the case, then it becomes a hybrid framework. But still people tend to call it a BPT framework. So in your case, you can choose to simply call it a BPT framework, or a BPT based hybrid framework or something on similar lines.

Features of a Hybrid Framework

In this section, you would see some of the features that you can be implemented as part of your hybrid framework. Some of these features are pretty common and you would see them being used in many different hybrid frameworks. There would be other features also that are not so important and can be termed as nice to have (but not mandatory). Let us see some of these important features.

1.) The most basic set of features come first. The hybrid framework should be designed in such a way that it is re-usable and easily scalable. Also, the code should be easy to understand and maintain. As a matter of fact, please don’t consider this point as a feature. It is a must-have and you should consider it a rule. Doing this would save you a lot of troubles afterwards.

2.) All the components in the framework can be grouped separately. You can employ a basic folder structure to keep the test cases, function libraries, data sheets and test results grouped together in an efficient manner.

3.) One click execution. This is a good feature that you can implement in your automation framework. With just a single click of a button, the framework should execute all the test cases. In most of the cases, this feature is implement using MS excel + macros. This is because the excel sheets provide you with more control on how you can select your test cases.

4.) Another important point is how you display your test results. You should aim to display the test results at minimum 2 different levels of abstraction. These are – summarized report and detailed report. A summarized report can simply be an excel sheet that provides the list of the test cases that were executed, whether they passed or failed, and a link pointing towards the detailed report for each of  the test cases. You can also add more parameters to this report if required. An example of a summarized report is shown in the below image.

A detailed report would be the actual QTP result which you would have saved in appropriate result folders. The detailed report will mostly be used for investigative purpose. For example, in case a test script fails, or it takes more than expected time for completion, you can open the detailed result and try to find out the exact cause for the issue.

5.) Automated Email Notification. This is another important feature that you can incorporate in your automation framework. This is especially useful when you execute your test scripts in batch execution mode. You can write some logic in your framework that will automatically send emails to intended recipients after the completion of the batch run. You can also include the summarized excel report as an attachment in the email.

6.) Automated SMS Notification. This can be considered as an extension of the above point. Here, you can have your framework send an SMS to a select list of people with the test execution status.

If you intend to use this feature, then please keep in mind that the messages that you send should be short and crisp. For example, you could send something like this as an SMS – “TCs executed-100. Passed-85. Failed-15.”

Also, please note that this feature is used very rarely. So from the usability point of view, its very difficult justify the use or need of sending SMSes. Also you would need to factor in the cost of sending SMSes.

A scenario where sending SMS can be useful: You can configure your framework to send an SMS to certain people when, say 5 or 10 consecutive test cases fail one after the other. Such a scenario normally indicates that there is some big issue going on. Maybe the environment went down, or some other problem. Having an SMS sent in such a situation can help the teams identify the issue in a more timely manner.

7.) Framework should be externally configurable to a certain extent. This is a nice feature that I have started using recently. The idea behind this feature is – there should be certain functionalities in your framework that you should be able to configure without having to touch the code. Consider the following scenarios as examples –

• a) Consider a case that on a particular day, the test environment is pretty slow. This requires you to increase the default load time of the pages. Your framework should provide a provision to do this easily for all the test cases.
• b) Consider another situation where you need to modify the details of the people to whom the email should be sent. Or maybe you don’t want to send email for a particular batch run. You framework should provide you a means with which you should be able to do these tasks without touching the code.

The best way to create an externally configurable sheet is to use an excel sheet. The below image shows an example of such a sheet.

8.) Intermediate Status Reports. This is another nice to have feature that you can incorporate in your automation framework. Consider a scenario where you have set up a batch execution of 100 test cases. Its obvious that you wouldn’t be sitting in front of your system all the time to monitor the execution. Suppose you move away from your desk and come back to see the execution after say, 1 hour.

At this point the test cases might still be executing but you would not know how much more time your scripts will take to execute or maybe how many test cases are still pending. In such situations, intermediate status reports come in handy.

Intermediate status report can be as simple as a auto-closing popup that appears after the execution of each test case, gives you the updates and closes automatically (in 3 to 5 seconds). A simple message like the one shown below will be more than enough.

These were some of the features that you can incorporate in your automation framework. It’s not necessary that you add all the features at once. A good approach would be create the framework with the minimum necessary features. And then you can add these nice-to-have features to your framework as enhancements.

In the upcoming articles in this series, we will create a hybrid framework from scratch where we will be incorporating some of these features. Please note that we will not be adding all the features to the sample framework as it leads to code complexity. The goal of the upcoming articles would be to keep the framework creation process as simple as possible, so that it is easily understood by everyone.

Over to you

This was all about the basics of hybrid framework and some cool features that can be implemented as part of this framework. We are waiting to hear your thoughts on these. Did you find this article helpful? Did you find the features interesting? Was there any feature that you were not aware about? Or something that you have seen or used but is not mentioned here? You can let us know your thoughts using the comments section.

Visit QTP Frameworks Main Page for more articles on QTP Frameworks. You can also visit our QTP Tutorials page for more QTP Tutorials.