Most Asked QTP Interview Questions and Answers

QTP Interview Questions and Answers most commonly asked for Experienced PDF, Freshers candidates for Employment.

Explain the check points in QTP?

A checkpoint verifies that expected information is displayed in a Application while the test is running. You can add eight types of checkpoints to your test for standard web objects using QTP.

– A page checkpoint checks the characteristics of a Application.
– A text checkpoint checks that a text string is displayed in the appropriate place on a Application.
– An object checkpoint (Standard) checks the values of an object on a Application.
– An image checkpoint checks the values of an image on a Application.
– A table checkpoint checks information within a table on a Application.
– An Accessibility checkpoint checks the web page for Section 508 compliance.
– An XML checkpoint checks the contents of individual XML data files or XML documents that are part of your Web application.
– A database checkpoint checks the contents of databases accessed by your web site.

In how many ways we can add check points to an application using QTP.

We can add checkpoints while recording the application or we can add after recording is completed using Active screen

(Note : To perform the second one The Active screen must be enabled while recording).

How does QTP identifies the object in the application?

QTP identifies the object in the application by Logical Name and Class.

If an application name is changes frequently i.e while recording it has name “Window1” and then while running its “Windows2” in this case how does QTP handles?

QTP handles those situations using “Regular Expressions”.

What is Parameterizing Tests?

When you test your application, you may want to check how it performs the same operations with multiple sets of data. For example, suppose you want to check how your application responds to ten separate sets of data. You could record ten separate tests, each with its own set of data. Alternatively, you can create a parameterized test that runs ten times: each time the test runs, it uses a different set of data.

What is test object model in QTP?

The test object model is a large set of object types or classes that QuickTest uses to represent the objects in your application. Each test object class has a list of properties that can uniquely identify objects of that class and a set of relevant methods that QuickTest can record for it.

A test object is an object that QuickTest creates in the test or component to represent the actual object in your application. QuickTest stores information about the object that will help it identify and check the object during the run session.
A run-time object is the actual object in your Web site or application on which methods are performed during the run session.

When you perform an operation on your application while recording, QuickTest identifies the test object class that represents the object on which you performed the operation and creates the appropriate test object reads the current value of the object’s properties in your application and stores the list of properties and values with the test object chooses a unique name for the object, generally using the value of one of its prominent properties records the operation that you performed on the object using the appropriate QuickTest test object method. For example, suppose you click on a Find button with the following HTML source code:

QuickTest identifies the object that you clicked as a WebButton test object. It creates a WebButton object with the name Find, and records the properties and values for the Find WebButton. It also records that you performed a Click method on the WebButton. QuickTest displays your step like this:

Browser(“Mercury Interactive”).Page(“Mercury Interactive”).

What is the Diff between Image check-point and Bit map Check point?

Image checkpoints enable you to check the properties of a Web image. You can check an area of a Web page or application as a bitmap. While creating a test or component, you specify the area you want to check by selecting an object. You can check an entire object or any area within an object. QuickTest captures the specified object as a bitmap, and inserts a checkpoint in the test or component. You can also choose to save only the selected area of the object with your test or component in order to save disk Space. For example, suppose you have a Web site that can display a map of a city the user specifies. The map has control keys for zooming. You can record the new map that is displayed after one click on the control key that zooms in the map.

Using the bitmap checkpoint, you can check that the map zooms in correctly. You can create bitmap checkpoints for all supported testing environments (as long as the appropriate add-ins is loaded). Note: The results of bitmap checkpoints may be affected by factors such as operating system, screen resolution, and color settings.

How many ways we can parameterize data in QTP?

There are four types of parameters:

– Test, action or component parameters enable you to use values passed from your test or component, or values from other actions in your test.

– Data Table parameters enable you to create a data-driven test (or action) that runs several times using the data you supply. In each repetition, or iteration, QuickTest uses a different value from the Data Table.

– Environment variable parameters enable you to use variable values from other sources during the run session. These may be values you supply, or values that QuickTest generates for you based on conditions and options you choose.

– Random number parameters enable you to insert random numbers as values in your test or component. For example, to check how your application handles small and large ticket orders, you can have QuickTest generate a random number and insert it in a number of tickets edit field.

How do u do batch testing in WR & is it possible to do in QTP, if so explain?

Batch Testing in WR is nothing but running the whole test set by selecting “Run Testset” from the “Execution Grid”. The same is possible with QTP also. If our test cases are automated then by selecting “Run Testset” all the test scripts can be executed. In this process the Scripts get executed one by one by keeping all the remaining scripts in “Waiting” mode.

does it mean when a check point is in red color? what do you do?

A red color indicates failure. Here we analyze the cause for failure whether it is a Script Issue or Environment Issue or a Application issue.

What do you call the window test director – testlab?

Execution Grid”. It is place from where we Run all Manual / Automated Scripts.

How does you create new test sets in TD?

– Login to TD.
– Click on “Test Lab” tab.
– Select the Desired folder under which we need to Create the Test Set. (Test Sets can be grouped as per module.)
– Click on “New Test Set or Ctrl+N” Icon to create a Test Set.

How do u do batch testing in WR & is it possible to do in QTP, if so explain?

You can use Test Batch Runner to run several tests in succession. The results for each test are stored in their default location.

Using Test Batch Runner, you can set up a list of tests and save the list as an .mtb file, so that you can easily run the same batch of tests again, at another time. You can also choose to include or exclude a test in your batch list from running during a batch run.

How to Import data from a “.xls” file to Data table during Runtime?

Datatable.Import “…XLS file name…”
– DataTable.ImportSheet(FileName, SheetSource, SheetDest)
– DataTable.ImportSheet “C:\name.xls” ,1 ,”name”

How to export data present in Datatable to an “.xls” file?

DataTable.Export “….xls file name…”

Syntax for how to call one script from another and Syntax to call one “Action” in another?

RunAction ActionName, [IterationMode , IterationRange , Parameters]

Here the actions become reusable on making this call to any Action.
IterationRange String Not always required. Indicates the rows for which action iterations will be performed. Valid only when the IterationMode is rngIterations. Enter the row range (i.e. “1-7”), or enter rngAll to run iterations on all rows.
If the action called by the RunAction statement includes an ExitAction statement, the RunAction statement can return the value of the ExitAction’s RetVal argument.

How to export QTP results to an “.xls” file?

By default it creates an “XML” file and displays the results.

Differences between QTP & Winrunner?

– QTP is object bases Scripting ( VBS) where Winrunner is TSL (C based) Scripting.
– QTP supports “.NET” application Automation not available in Winrunner.
– QTP has “Active Screen” support which captures the application, not available in WR.
– QTP has “Data Table” to store script values , variables which WR does not have.
Using a “point and click” capability you can easily interface with objects, their definitions and create checkpoints after having recorded a script without having to navigate back to that location in your application like you have to with WinRunner. This greatly speeds up script development.

How to add a runtime parameter to a datasheet?

By using LocalSheet property. The following example uses the LocalSheet property to return the local sheet of the run-time Data Table in order to add a parameter (column) to it:

MyParam=DataTable.LocalSheet.AddParameter(“Time”, “5:45”)

What scripting language is QTP of?

VB Script.

Analyzing the Checkpoint results

Standard Checkpoint: By adding standard checkpoints to your tests or components, you can compare the expected values of object properties to the object’s current values during a run session. If the results do not match, the checkpoint fails.

Table and DB Checkpoints:

By adding table checkpoints to your tests or components, you can check that a specified value is displayed in a cell in a table on your application. By adding database checkpoints to your tests or components, you can check the contents of databases accessed by your application.

The results displayed for table and database checkpoints are similar. When you run your test or component, QuickTest compares the expected results of the checkpoint to the actual results of the run session. If the results do not match, the checkpoint fails.

You can check that a specified value is displayed in a cell in a table by adding a table checkpoint to your test or component. For ActiveX tables, you can also check the properties of the table object. To add a table checkpoint, you use the Checkpoint Properties dialog box.

Table checkpoints are supported for Web and ActiveX applications, as well as for a variety of external add-in environments.

You can use database checkpoints in your test or component to check databases accessed by your Web site or application and to detect defects. You define a query on your database, and then you create a database checkpoint that checks the results of the query.

Database checkpoints are supported for all environments supported by QuickTest, by default, as well as for a variety of external add-in environments.

There are two ways to define a database query:

– Use Microsoft Query. You can install Microsoft Query from the custom installation of Microsoft Office.
– Manually define an SQL statement.

The Checkpoint timeout option is available only when creating a table checkpoint. It is not available when creating a database checkpoint.

Checking Bitmaps:

You can check an area of a Web page or application as a bitmap. While creating a test or component, you specify the area you want to check by selecting an object. You can check an entire object or any area within an object. QuickTest captures the specified object as a bitmap, and inserts a checkpoint in the test or component. You can also choose to save only the selected area of the object with your test or component in order to save disk space.

When you run the test or component, QuickTest compares the object or selected area of the object currently displayed on the Web page or application with the bitmap stored when the test or component was recorded. If there are differences, QuickTest captures a bitmap of the actual object and displays it with the expected bitmap in the details portion of the Test Results window. By comparing the two bitmaps (expected and actual), you can identify the nature of the discrepancy.

For example, suppose you have a Web site that can display a map of a city the user specifies. The map has control keys for zooming. You can record the new map that is displayed after one click on the control key that zooms in the map. Using the bitmap checkpoint, you can check that the map zooms in correctly.

You can create bitmap checkpoints for all supported testing environments (as long as the appropriate add-ins is loaded).

Note: The results of bitmap checkpoints may be affected by factors such as operating system, screen resolution, and color settings.

Text/Text Area Checkpoint:

In the Text/Text Area Checkpoint Properties dialog box, you can specify the text to be checked as well as which text is displayed before and after the checked text. These configuration options are particularly helpful when the text string you want to check appears several times or when it could change in a predictable way during run sessions.

Note: In Windows-based environments, if there is more than one line of text selected, the Checkpoint Summary pane displays [complex value] instead of the selected text string. You can then click Configure to view and manipulate the actual selected text for the checkpoint.

QTP automatically displays the Checked Text in red and the text before and after the Checked Text in blue. For text area checkpoints, only the text string captured from the defined area is displayed (Text Before and Text After are not displayed).

To designate parts of the captured string as Checked Text and other parts as Text Before and Text After, click the Configure button. The Configure Text Selection dialog box opens.

Checking XML

XML (Extensible Markup Language) is a meta-markup language for text documents that is endorsed as a standard by the W3C. XML makes the complex data structures portable between different computer environments/operating systems and programming languages, facilitating the sharing of data.

XML files contain text with simple tags that describe the data within an XML document. These tags describe the data content, but not the presentation of the data. Applications that display an XML document or file use either Cascading Style Sheets (CSS) or XSL Formatting Objects (XSL-FO) to present the data.

You can verify the data content of XML files by inserting XML checkpoints. A few common uses of XML checkpoints are described below:

– An XML file can be a static data file that is accessed in order to retrieve commonly used data for which a quick response time is needed—for example, country names, zip codes, or area codes. Although this data can change over time, it is normally quite static. You can use an XML file checkpoint to validate that the data has not changed from one application release to another.

– An XML file can consist of elements with attributes and values (character data). There is a parent and child relationship between the elements, and elements can have attributes associated with them. If any part of this structure (including data) changes, your application’s ability to process the XML file may be affected. Using an XML checkpoint, you can check the content of an element to make sure that its tags, attributes, and values have not changed.

– XML files are often an intermediary that retrieves dynamically changing data from one system. The data is then accessed by another system using Document Type Definitions (DTD), enabling the accessing system to read and display the information in the file. You can use an XML checkpoint and parameterize the captured data values in order to check an XML document or file whose data changes in a predictable way.

– XML documents and files often need a well-defined structure in order to be portable across platforms and development systems. One way to accomplish this is by developing an XML schema, which describes the structure of the XML elements and data types. You can use schema validation to check that each item of content in an XML file adheres to the schema description of the element in which the content is to be placed.

Object Repositories types, which & when to use?

To choose the default object repository mode and the appropriate object repository mode for each test, you need to understand the differences between the two modes. In general, the object repository per-action mode is easiest to use when you are creating simple record and run tests, especially under the following conditions:

– You have only one, or very few, tests that correspond to a given application, interface, or set of objects.

– You do not expect to frequently modify test object properties.

– You generally create single-action tests.

Conversely, the shared object repository mode is generally the preferred mode when:

– You have several tests that test elements of the same application, interface, or set of objects.

– You expect the object properties in your application to change from time to time and/or you regularly need to update or modify test object properties.

– You often work with multi-action tests and regularly use the Insert Copy of Action and Insert Call to Action options.

Can we Script any test case with out having Object repository? or Using Object Repository is a must?

No. You can script with out Object repository by knowing the Window Handlers, spying and recognizing the objects logical names and properties available.

How to execute a WinRunner Script in QTP?

TSLTest.RunTest TestPath, TestSet [, Parameters ] –> Used in QTP 6.0 used for backward compatibility

Parameters: The test set within Quality Center , in which test runs are stored. Note that this argument is relevant only when working with a test in a Quality Center project. When the test is not saved in Quality Center , this parameter is ignored.
e.g : TSLTest.RunTest “D:\test1”, “”

(b) TSLTest.RunTestEx TestPath, RunMinimized, CloseApp [, Parameters ]
TSLTest.RunTestEx “C:\WinRunner\Tests\basic_flight”, TRUE, FALSE, “MyValue”
CloseApp : Indicates whether to close the WinRunner application when the WinRunner test run ends.
Parameters : Up to 15 WinRunner function argument

How to handle Run-time errors?

On Error Resume Next : causes execution to continue with the statement immediately following the statement that caused the run-time error, or with the statement immediately following the most recent call out of the procedure containing the On Error Resume Next statement. This allows execution to continue despite a run-time error. You can then build the error-handling routine inline within the procedure. Using “Err” object msgbox “Error no: ” & ” ” & Err.Number & ” ” & Err.description & ” ” & Err.Source & Err.HelpContext

How to change the run-time value of a property for an object?

SetTOProperty changes the property values used to identify an object during the test run. Only properties that are included in the test object description can be set.

How to retrieve the property of an object?

using “GetRoProperty”.

How to open any application during Scripting?

SystemUtil, object used to open and close applications and processes during a run session. A SystemUtil.Run statement is automatically added to your test when you run an application from the Start menu or the Run dialog box while recording a test
E.g : SystemUtil.Run “Notepad.exe”
SystemUtil.CloseDescendentProcesses (Closes all the processes opened by QTP)

Types of properties that Quick Test learns while recording?

(a) Mandatory (b) Assistive .

In addition to recording the mandatory and assistive properties specified in the Object Identification dialog box, QuickTest can also record a backup ordinal identifier for each test object. The ordinal identifier assigns the object a numerical value that indicates its order relative to other objects with an otherwise identical description (objects that have the same values for all properties specified in the mandatory and assistive property lists). This ordered value enables QuickTest to create a unique description when the mandatory and assistive properties are not sufficient to do so.

What is the extension of script and object repository files?

Object Repository : .tsr , Script : .mts, Excel : Default.xls

How to supress warnings from the “Test results page”?

From the Test results Viewer “Tools > Filters > Warnings”…must be “Unchecked”.

When we try to use test run option “Run from Step”, the browser is not launching automatically why?

This is default behaviour.

How to “Turn Off” QTP results after running a Script?

Goto “Tools > Options > Run Tab” and Deselect “View results when run session ends”. But this supresses only the result window, but a og will be created and can viewed manually which cannot be restricted from getting created.

How to verify the Cursor focus of a certain field?

Use “focus” property of “GetRoProperty” method”

How to make arguments optional in a function?

This is not possible as default VBS doesn’t support this. Instead you can pass a blank scring and have a default value if arguments are not required.

How to covert a String to an integer?

CInt()—> a conversion function available

Inserting a Call to Action is not importing all columns in Datatable of globalsheet. Why?

Inserting a call to action will only Import the columns of the Action called

What kinds of testing should be considered?

• Black box testing – not based on any knowledge of internal design or code. Tests are based on requirements and functionality.

• White box testing – based on knowledge of the internal logic of an application’s code. Tests are based on coverage of code statements, branches, paths, conditions.

• unit testing – the most ‘micro’ scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.

• incremental integration testing – continuous testing of an application as new functionality is added; requires that various aspects of an application’s functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.

• integration testing – testing of combined parts of an application to determine if they function together correctly. The ‘parts’ can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

• functional testing – black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn’t mean that the programmers shouldn’t check that their code works before releasing it (which of course applies to any stage of testing.)

• system testing – black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.
• end-to-end testing – similar to system testing; the ‘macro’ end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

• sanity testing or smoke testing – typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a ‘sane’ enough condition to warrant further testing in its current state.

• regression testing – re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing.

• acceptance testing – final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.

• load testing – testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails.

• stress testing – term often used interchangeably with ‘load’ and ‘performance’ testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.

• performance testing – term often used interchangeably with ‘stress’ and ‘load’ testing. Ideally ‘performance’ testing (and any other ‘type’ of testing) is defined in requirements documentation or QA or Test Plans.

• usability testing – testing for ‘user-friendliness’. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.

• install/uninstall testing – testing of full, partial, or upgrade install/uninstall processes.

• recovery testing – testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

• security testing – testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.

• compatability testing – testing how well software performs in a particular hardware/software/operating system/network/etc. environment.

• exploratory testing – often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.

• ad-hoc testing – similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.

• user acceptance testing – determining if software is satisfactory to an end-user or customer.

• comparison testing – comparing software weaknesses and strengths to competing products.

• alpha testing – testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.

• beta testing – testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.

• mutation testing – a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (‘bugs’) and retesting with the original test data/cases to determine if the ‘bugs’ are detected. Proper implementation requires large computational resources.

What makes a good QA or Test manager?

A good QA, test, or QA/Test(combined) manager should:
• be familiar with the software development process
• be able to maintain enthusiasm of their team and promote a positive atmosphere, despite
• what is a somewhat ‘negative’ process (e.g., looking for or preventing problems)
• be able to promote teamwork to increase productivity
• be able to promote cooperation between software, test, and QA engineers
• have the diplomatic skills needed to promote improvements in QA processes
• have the ability to withstand pressures and say ‘no’ to other managers when quality is insufficient or QA processes are not being adhered to
• have people judgement skills for hiring and keeping skilled personnel

be able to communicate with technical and non-technical people, engineers, managers, and customers.

  • • be able to run meetings and keep them focused

What is ‘configuration management’?

Configuration management covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and who makes the changes. (See the ‘Tools’ section for web resources with listings of configuration management tools

What steps are needed to develop and run software tests?

The following are some of the steps to consider:
• Obtain requirements, functional design, and internal design specifications and other necessary documents
• Obtain budget and schedule requirements
• Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes (such as release processes, change processes, etc.)
• Identify application’s higher-risk aspects, set priorities, and determine scope and limitations of tests
• Determine test approaches and methods – unit, integration, functional, system, load, usability tests, etc.
• Determine test environment requirements (hardware, software, communications, etc.)
• Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.)
• Determine test input data requirements
• Identify tasks, those responsible for tasks, and labor requirements
• Set schedule estimates, timelines, milestones
• Determine input equivalence classes, boundary value analyses, error classes
• Prepare test plan document and have needed reviews/approvals
• Write test cases
• Have needed reviews/inspections/approvals of test cases
• Prepare test environment and testware, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data
• Obtain and install software releases
• Perform tests
• Evaluate and report results
• Track problems/bugs and fixes
• Retest as needed
• Maintain and update test plans, test cases, test environment, and testware through life cycle

What’s the role of documentation in QA?

Critical. (Note that documentation can be electronic, not necessarily paper.) QA practices should be documented such that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented. There should ideally be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. Change management for documentation should be used if possible

What if the application has functionality that wasn’t in the requirements?

It may take serious effort to determine if an application has significant unexpected or hidden functionality, and it would indicate deeper problems in the software development process. If the functionality isn’t necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer. If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only effects areas such as minor improvements in the user interface, for example, it may not be a significant risk.

How does a client/server environment affect testing?

Client/server applications can be quite complex due to the multiple dependencies among clients, data communications, hardware, and servers. Thus testing requirements can be extensive. When time is limited (as it usually is) the focus should be on integration and system testing. Additionally, load/stress/performance testing may be useful in determining client/server application limitations and capabilities. There are commercial tools to assist with such testing.


Popular posts from this blog

TOP Agile Testing Interview Questions and Answers

Latest Agile Testing Interview Questions and Answers

Most Asked ADO.NET Interview Questions and Answers