QTP - Interview Question Bank : Part 1

Q. 1: What is Automation Object Model in QTP?======================================
Like we use QTP for automating the testing of our applications, we can use the automation object model of QTP to automate its own operations as well. With the help of objects, methods, and properties exposed by the automation object model of QTP along with standard programming elements like loops and conditional statements, we can write programs which can configure QTP options and run tests or components instead of performing these operations manually using the QTP interface.

Automation programs are especially useful for performing the same tasks several times or on multiple tests or components, or quickly configuring QTP according to the needs for a particular environment or application.

Most of the dialog boxes in QTP have a corresponding automation object. Most of the options in dialog boxes can be set retrieved using the corresponding object property, and most of the menu commands and other operations have corresponding automation methods.
============================
Q. 2: What is a Recovery Scenario?
============================

Recovery scenario gives you an option to take some action for recovering from a fatal error in the test. Such problems are quite frequent especially when the tests are made to run unattended. In such a case the test process halts until the user perform some desired recovery operation.

Recovery scenarios are useful when it is difficult to predict at which step the errors can come or when we are confident that the error will not come in the QTP script, whereas it can be anywhere outside the QTP Script. For illustration; Pop-up message of "out of paper", as caused by the printer device driver. "On error resume next" is preferred when we sure that the error is expected one and wish to perform some other actions.
=================================
Q. 3: What is Smart Identification in QTP?
=================================
QTP has a unique feature by the name Smart Object Identification or recognition which is used for identifying the objects smartly, whenever the normal identification fails due to the dynamic changes in the properties of the objects.

Smart Identification is nothing but an algorithm used by the QTP when it is not able to recognize an object.
=================================
Q. 4: How QTP identifies various Objects?
=================================
During recording QTP identifies various objects and stores them as test objects. For each test object QTP learns a set of default properties called mandatory properties. Simultaneously QTP looks at rest of the objects to check whether these properties are sufficient to uniquely identify the object or not. During the test run, QTP searches for the run time objects, which match with the test objects which, have been captured by it during recording.

==================================
Q. 5: What are Object Repositories in QTP? ==================================
When planning and creation of tests is done, we firstly consider how we would like to store the objects in our tests. In QTP, the test objects can be stored in two types of object repositories

a) Shared object repository: It stores test objects in a file that can be accessed by multiple tests (in read-only mode). If someone is new to QTP, he can prefer to use local object repositories. This way he can record and run the tests without creating, choosing, or modifying shared object repositories because all objects are automatically getting saved in a local object repository which can be accessed by its corresponding action.

b) Local object repository: It stores objects in a file that is associated with one specific action, so that only that action can access the stored objects. If someone is familiar with QTP testing, he can find that it is quite efficient to save the objects in a shared object repository. This way, he can use the same shared object repository for multiple actions - if the actions include the same objects. Test object information that applies to many actions is kept in one centralized location. When the objects in the application change, we can update them in one location for all the actions that use this shared object repository.

==============================================
Q. 6: How QTP recognizes objects in Object Repositories? ==============================================
Object Repository displays a tree of all the objects in the current component or in the current action or in the entire test , depending on the object repository mode selected by the user. We can view or modify the test object description of any test object in the repository or to add new objects to the repository.

QTP remembers the default property values and determines in which test object class it fits. If it is not found enough it automatically adds assistive properties, one by one to the description until it successfully compiles the unique description. If no assistive properties are available, then it adds a special Ordinal identifier such as object location on the page or in the source code.

========================================
Q. 7: How many types of Actions are there in QTP? ========================================
QTP uses following three kinds of actions:
a) Non-reusable action - can be called only in the test with which it is stored, and can be called only once.

b) Reusable action - can be called multiple times by the test with which it is stored (the local test) as well as by other tests.

c) External action - is a reusable action which is stored with another test. External actions are read-only in the calling test, but we can choose to use a local, editable copy of the Data Table information for the external action.

By default, all new actions are non-reusable. We can mark every action created by us in the test as reusable or non-reusable.
===========================================
Q. 8: Is there any built-in function for scripting in QTP? ===========================================
QTP uses an in-built functionality called "Step Generator" to create scripts while appropriate steps are entered into it. Step Generator utility enables us to add steps by selecting from a range of context-sensitive options and entering the required values.

You can open the Step Generator from the Keyword View or Expert View while recording or editing your test. You can also open the Step Generator from the Active Screen while editing.
Method to open the Step Generator from a function library is as under

a) In the function library, click the location in which you want to insert the new step.

b) Choose Insert > Step Generator, or right-click and choose Step Generator. Alternatively, press F7.

====================================
Q. 9: What is a Run-Time Data Table in QTP? ====================================
During the run session, QTP creates a Runtime Data Table, which is live version of the Data Table associated with our test. During the run session, QTP displays the run-time data in the Data Table pane so that we can see the changes taking place in the Data Table.

When the run session ends, the Runtime Data Table closes, and the Data Table pane again displays the stored design-time Data Table. Data entered in the run-time Data Table during the run session does not get saved along with the test. The final data from the run-time Data Table gets displayed in the Run-Time Data Table in the Test Results window.

Runtime Data Table is an excel file, which gets stored in the folder of the test created, its name is Default.xls by default.
====================================
Q. 10: What is the Object Spy feature in QTP? ====================================
Using the Object Spy pointing hand mechanism, you can view the supported properties and methods of any object in an open application. As you move the pointing hand over the objects in the application, their details are displayed in the Object Spy. These details may include the test object’s hierarchy tree, its properties and values, and the methods associated with the object. For methods, the syntax is also displayed.

Keyword: QTP Interview Questions, FAQ QTP

Read more...

Guidelines to select an Appropriate Automation Tool

If your organization is currently using manual means to test your software applications & is believing that it can derive tangible benefits by automating its software testing process, then simply jumping to a conclusion of buying some tool simply because it is popular among many, may not be wise. What should be done now is to take a judicious decision through a scientific process to find out as to which tool will best be suited to your needs. Since this is an capital intensive move aimed at taking your company to the world of Automated Testing, needs careful examination.

When you are shopping for a proper automation tool, you will come across several people ambitiously marketing their products, which may provide solution to variety of automated testing needs. Now the question arises as to whether a particular tool is really suitable to your needs or not. Are you not inclining your choice for a particular tool by making lot many compromises in features. Think that in times to come, your testing needs may become more complicated by the variety of applications coming across for testing & that too under variety of operating systems.

Thus following guidelines shall be helpful in evaluating & zeroing down your choice of an appropriate tool for the job at hand, out of a bunch of many testing tools sold by different vendors.

Guideline – 1: Understand your True Requirement

First of all don’t look at & form any type of opinion about any XYZ tool available in the market. This is high time for doing deep introspection of your real needs. It is wise to prepare a comprehensive list of your requirements of software testing at the present moment. Identify the time consuming problems, which you want to solve with the new tool. Identify the technical capabilities your prospective tool should have to be compatible with the environment of your application.

Following checklist can be helpful in a judicious compilation of your requirements:

a) List down the Compatibility issues: Remember that the tool selected by you has to be compatible with:
# The operating systems supported by your application to be tested

# The development environments under which the application shall be created

# Third party software if any with whom your application needs to be integrated at some stage

b) List down the Users of the Tool
# List down the people who will be actually using the prospective tool. Keep the skill levels of the available persons at the back of your mind.

# Remember that more powerful tools are bound to be more complex as well. If the skill level of the available manpower (who will be expected to use the prospective tool everyday), does not match the complexity level of the tool, believe me, you are likely to land into many problems in smooth implementation of the tool in your organization.

# Think as to whether there is enough time for training your staff within the prevailing time & budgetary constraints, if any.

c) List down the Testing requirements
Technical requirements like the following needs to be listed down before zeroing down your choice on a particular automation tool.
# Identify the types of your own testing problems you wish that your new tool should solve for you.

# Identify the problems faced by you during manual testing.

# Identify the time constraints coming across while making minor changes to your system.

# Identify the shorter regression testing time frames.

# Identify the Test data setup requirements.

# Identify the Defect tracking requirements you are aiming at.

# Identify the Increased test coverage you are looking for.

# Identify the Increase in efficiency of the testing process you are looking for.

Guideline – 2: Understand the constraints you have

You need to understand various factors, which may compel you to drop down some of the tools from your initial selection list. Such crucial factors need to be identified during the early stages of your tool selection process.

a) Environmental constraints

# Environmental constraints can be either related to hardware or the software itself.

# The prospective tool must be able to work on the desired operating systems

# The prospective tool must not dictate the terms of having some specialized hardware for its working.

# Up-gradation of existing hardware like providing more hard disk / More Ram etc. to cope with the requirements of additional scripts and test data likely to be added.

# Consider your likely objections to your new tool running under some specific environment, while the software application might be required to run under different environment or operating system. This issue may gain importance from the consideration of the future use of the new tool.

b) Credentials of the Vendors & their Clientele
It is certain that you won’t desire to hang on with problems with your new testing tool. Certainly anyone would like to have a quick, competent & professional solution to the tool related problems arising may be occasionally.

Following checklist may come handy in such a situation.
# The tool supplier must represent a genuine company.

# The tool as a product & its supplying company must be matured enough.

# The tool may not be worthwhile at all unless there is enough technical support available.

# Find out the clientele of the prospective tool & try to obtain the feedback from such organizations if possible.

# Find out the past history of the prospective tool?

c) Understand the Quality related characteristics
Following quality related constraints of the prospective tool should be helpful
# Identify the skill level required for using the prospective tool

# Verify as to whether it is possible to have multiple user access

# Identify the support and help documentation required.

# Verify as to whether it is possible to integrate the prospective tool with other tools.

# Ensure that there should not be any possibility of getting your data corrupted by the tool.

# Frequency of failure during realistic use

# Identify the budgetary constraints if any. Such financial constraints can restrict your choice of buying a particular tool.

Remember that it is not the question of just purchasing a particular tool by spending some money. In fact it has been seen that in many cases, the cost of fully implementing the tool can be much higher than the cost of the tool itself. Budgetary constraints shall be applicable not only to the tool purchase cost, but shall cover costs of licensing / AMC’s, costs of training and cost of tool implementation etc.

We can be in a position to evaluate various tools available in the market after compiling a comprehensive list of our requirements and various constraints.

Guideline – 3: Shortlist the most likely suitable tools

This is the stage when an extensive research is needed to identify various types of tools available in the market. WWW can be a good place to explore the tool. Preliminary study of the technical brochure of every tool shall reveal the capabilities of the tool fitting your requirements & constraints.

We can identify various features of every tool by classifying them like a) Essential features b) Desirable features c) Less relevant features etc.

a) Essential features: are the ones, which are extremely necessary to meet your requirements within the defined constraints.

b) Desirable features: are the ones, which will make a particular tool standout among many of its competitors. Based upon the presence of variety desirable features, your decision can be favor of a particular tool among many more.

c) Irrelevant features: are the ones, which are not of any great significance & may not be able to provide some tangible benefit to you in your present requirements.

Evaluation of the above types of features is the next exhaustive & iterative exercise. At this stage you should evaluate as much number of tools as possible and try to zero down your focus on around 5-6 tools any one of which could qualify to be the final tool fitting your ultimate choice.

The next step in the process should be establishing a contact with the tool suppliers & organizing a practical demonstration. If possible you can ask for an evaluation or trial version of the tool for refining your decision. At this stage you should clearly explain all your requirements of testing along with set of constraints to the tool supplier, who shall be in a better position to clarify many points left out by you during your short-listing process.

Guideline – 4: Making a Final Choice

Having gone through the above-defined rigorous process of evaluation, the time has come for you to take a decision in favor of one particular tool, which suits best into your slot of requirements & constraints.

a) Final Comparison of Features:
# With the help of all available data now you should be able to draw a clear comparison of the performance related features of the tools as desired by you vis-a-vis features claimed to be present in the technical literature provided by the persons marketing the tool.

# This is stage to go on for verification of the credential of the particular tool from the present users by visiting their web sites or making contact through other channels. This shall help you in refining your choice of a particular tool.

b) Practical demonstration at your site:
If a particular tool has already caught your attention, you can ask the supplier to organize a live demonstration of the tool under your actual working environment. This way you will be able to judge the technical capability of the supplier as well in providing support later-on.

c) Maintenance of Test Script
Proper maintenance of automation scripts & ease of handling them is very important aspect of the tool under evaluation. Although we may not be able to make an on the spot judgement about this capability, but this aspect gets confirmed during the second or third release of testing after implementing the new tool.

d) Final Comparative Trial
Now this is the time for conducting same test on one particular application time & again on each & every short-listed tool independently. This way you shall be in a position to make a final decision in favor of a particular tool out of a box of many.

Key Word : Automation Tool, Tool Selection


Read more...

Introduction to Test Automation Framework

Judiciously testing all possible permutations of such components creates a highly complex testing situation with hundreds or thousands of testing scenarios. Under such situations there comes a need for automating the testing process with the help of automation framework approach, which can help in achieving detailed testing with great reduction in testing time.

It can never be a workable idea to automate all the test cases. Hence it is important to scientifically understand the areas which can be automated. Remember that an ad-hoc approach to test automation can in fact, lead to longer testing time and poor quality irrespective of the name & fame of the testing tool selected by you.

Now let us understand what is ‘Test Automation Framework’?

Test Automation Framework is a set of assumptions, concepts and practices which provide necessary support for the automated software testing.

The main advantage of such a framework is the low cost for maintenance. If there is change to any test case then only the test case file needs to be updated and the Driver Script and Startup script will remain the same. There's no need to update the scripts in case of changes to the application.

Types of Automation Framework:

1) Modularity driven framework: It requires the creation of small, independent scripts that represent modules, sections, and functions of the application-under-test. These small scripts are then used in a hierarchical fashion to construct larger tests, realizing a particular test case. It applies the principle of abstraction or encapsulation in order to improve the maintainability and scalability of automated test suites.

2) Data driven framework: It involves bunch of several interacting test scripts clubbed with their related data results. In this framework, variables are used for both input values and output verification values: navigation through the program, reading of the data sources, and logging of test status and information are all coded in the test script. It is quite suitable framework for use in RFT using Data-pools. This approach reduces coding effort to a great extent in case of large test cases, which otherwise could be quite time-consuming & cumbersome.

3) Keyword driven framework: It involves automated tests, which have inherent reusability and therefore ease of maintenance of tests that have been created at a high level of abstraction. It divides test creation into two stages like

a) Planning Stage: Involving analysis of the requirements for the application to determine which operations and objects have to be tested. E.g. an application having web based questionnaire will require a large amount of text entries.

b) Implementation Stage: It differs according to the tool or framework used. Generally automation engineers implement a framework that provides keywords like "check" and "enter". Testing engineers (who don’t have to know the coding) write the test cases based on the keywords defined in the planning stage that have been implemented by the engineers. The test is executed using a driver who reads the keywords and executes the corresponding code.

Keyword Driven Framework methodology requires more planning and a longer initial time-investment than going directly to the test creation stage and recording a test, it does make the test creation and test maintenance stages more efficient and keeps the structure of individual tests more readable and easier to modify.

4) Hybrid framework: Is a combination of three frameworks. This type of frameworks evolve over a passage of time and across multiple projects. It is the most successful automation frameworks, which generally accommodates both Keyword-driven testing as well as Data-driven testing. This allows data driven scripts to take advantage of the powerful libraries and utilities that usually accompany a keyword driven architecture.

In this case, the framework utilities can make the data driven scripts more compact and less prone to failure. The utilities can also facilitate the gradual and manageable conversion of existing scripts to keyword driven scripts as & when required. On the other hand, the framework can use scripts to perform some tasks that might be too difficult to re-implement in a pure keyword driven approach, or where the keyword driven capabilities are not yet in place.

Ten Steps for Test Automation Framework Methodology:

1) Identification of the Scope of Testing: Company oriented, Product oriented, Project Oriented.

2) Identification of the Needs of Testing: Identify Types of testing e.g. FT, Web Services etc. and application / modules to be tested.}

3) Identification of the Requirements of Testing: Find out the nature of requirements, identify type of actions for each requirement & identify high priority requirements.

4) Evaluation of the Test Automation Tool: Evaluation checklist, Identify the candidate tools available in the market, Sample run, rate & select the tools, Implementation & Training

5) Identification of the Actions to be automated: Actions, Validations & requirements supported by the Tool

6) Design of the Test Automation Framework: Framework guidelines, validations, Actions Involved, Systems involved, Tool Extensibility Support, Customs messages & UML Documentation.

7) Design of the Input Data Bank: Types of Input file. Input files – Categorization & Design of file prototypes.

8) Development of the Automation Framework: Development of script based upon framework design, Driver scripts, Worker Scripts, Record / Playback, Screen / Window / Transaction, Action / Keyword & Data Driven.

9) Population of Input Data Bank: Different Types of data Input, Populate data from different data sources, Manual input of data and Parent – Child data hierarchy.

10) Configuration of the Schedulers: Identify scheduler requirements & configure the schedulers.

Benefits of Test Automation Framework Approach:
Test Automation Framework built with systematic approach yields following benefits:

# Ensures consistency
# Significant reduction in the amount of code to develop & maintain thereby reducing the testing cycle time.
# Comprehensive coverage against requirements.
# Use of a "Common Standard" across the organization / Product team / Project team
# Maximizes reusability of test scripts ( Utility Functions)
# Provides a structured for test library having systematic maintenance of automation scripts
# Data Pooling
# Protects non-technical testers from the code

Key Word: QTP, Automation, Automation Framework,

Read more...