SOFTWARE TESTING

What is Software Testing

Software Testing:

Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to the process of executing a program or application with the intent of finding software bugs (errors or other defects).

Software testing can be stated as the process of validating and verifying that a computer program/application/product: meets the requirements that guided its design and development, works as expected, can be implemented with the same characteristics, and satisfies the needs of stakeholders.

Software testing, depending on the testing method employed, can be implemented at any time in the software development process. Traditionally most of the test effort occurs after the requirements have been defined and the coding process has been completed, but in the Agile approaches most of the test effort is on-going. As such, the methodology of the test is governed by the chosen software development methodology.



Testing can never completely identify all the defects within software. Instead, it furnishes a criticism or comparison that compares the state and behavior of the product against oracles—principles or mechanisms by which someone might recognize a problem. These oracles may include (but are not limited to) specifications, contracts,comparable products, past versions of the same product, inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws, or other criteria.

A primary purpose of testing is to detect software failures so that defects may be discovered and corrected. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions. The scope of software testing often includes examination of code as well as execution of that code in various environments and conditions as well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do. In the current culture of software development, a testing organization may be separate from the development team. There are various roles for testing team members. Information derived from software testing may be used to correct the process by which software is developed.

Every software product has a target audience. For example, the audience for video game software is completely different from banking software. Therefore, when an organization develops or otherwise invests in a software product, it can assess whether the software product will be acceptable to its end users, its target audience, its purchasers and other stakeholders. Software testing is the process of attempting to make this assessment.

Defects and failures 

Not all software defects are caused by coding errors. One common source of expensive defects is requirement gaps, e.g., unrecognized requirements which result in errors of omission by the program designer. Requirement gaps can often be non-functional requirements such as testability, scalability, maintainability, usability, performance, and security.

Software faults occur through the following processes. A programmer makes an error (mistake), which results in a defect (fault, bug) in the software source code. If this defect is executed, in certain situations the system will produce wrong results, causing a failure.Not all defects will necessarily result in failures. For example, defects in dead code will never result in failures. A defect can turn into a failure when the environment is changed. Examples of these changes in environment include the software being run on a new computer hardware platform, alterations in source data, or interacting with different software. A single defect may result in a wide range of failure symptoms.

Input combinations and preconditions

A very fundamental problem with software testing is that testing under all combinations of inputs and preconditions (initial state) is not feasible, even with a simple product. This means that the number of defects in a software product can be very large and defects that occur infrequently are difficult to find in testing. More significantly, non-functional dimensions of quality (how it is supposed to be versus what it is supposed to do)—usability, scalability, performance, compatibility, reliability—can be highly subjective; something that constitutes sufficient value to one person may be intolerable to another.

Software developers can't test everything, but they can use combinatorial test design to identify the minimum number of tests needed to get the coverage they want. Combinatorial test design enables users to get greater test coverage with fewer tests. Whether they are looking for speed or test depth, they can use combinatorial test design methods to build structured variation into their test cases.Note that "coverage", as used here, is referring to combinatorial coverage, not requirements coverage.

Roles

Software testing can be done by software testers. Until the 1980s, the term "software tester" was used generally, but later it was also seen as a separate profession. Regarding the periods and the different goals in software testing,[12] different roles have been established: manager, test lead, test analyst, test designer, tester, automation developer, and test administrator.

Static vs. dynamic testing

There are many approaches to software testing. Reviews, walkthroughs, or inspections are referred to as static testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing. Static testing can be omitted, and in practice often is. Dynamic testing takes place when the program itself is used. Dynamic testing may begin before the program is 100% complete in order to test particular sections of code and are applied to discrete functions or modules. Typical techniques for this are either using stubs/drivers or execution from a debugger environment.

Static testing involves verification whereas dynamic testing involves validation. Together they help improve software quality.

The box approach

Software testing methods are traditionally divided into white- and black-box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases.

White-Box testing

Main article: White-box testing

White-box testing (also known as clear box testing, glass box testing, transparent box testing and structural testing) tests internal structures or workings of a program, as opposed to the functionality exposed to the end-user. In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. This is analogous to testing nodes in a circuit, e.g. in-circuit testing (ICT).

While white-box testing can be applied at the unit, integration and system levels of the software testing process, it is usually done at the unit level. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it might not detect unimplemented parts of the specification or missing requirements.

Techniques used in white-box testing include:
API testing (application programming interface) – testing of the application using public and private APIs
Code coverage – creating tests to satisfy some criteria of code coverage (e.g., the test designer can create tests to cause all statements in the program to be executed at least once)
Fault injection methods – intentionally introducing faults to gauge the efficacy of testing strategies
Mutation testing methods
Static testing methods

Code coverage tools can evaluate the completeness of a test suite that was created with any method, including black-box testing. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested.[21] Code coverage as a software metric can be reported as a percentage for:
Function coverage, which reports on functions executed
Statement coverage, which reports on the number of lines executed to complete the test

100% statement coverage ensures that all code paths, or branches (in terms of control flow) are executed at least once. This is helpful in ensuring correct functionality, but not sufficient since the same code may process different inputs correctly or incorrectly.

Black-box testing

Main article: Black-box testing

Black box diagram

Black-box testing treats the software as a "black box", examining functionality without any knowledge of internal implementation. The tester is only aware of what the software is supposed to do, not how it does it. Black-box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, state transition tables, decision table testing, fuzz testing, model-based testing, use case testing, exploratory testing and specification-based testing.

Specification-based testing aims to test the functionality of software according to the applicable requirements.This level of testing usually requires thorough test cases to be provided to the tester, who then can simply verify that for a given input, the output value (or behavior), either "is" or "is not" the same as the expected value specified in the test case. Test cases are built around specifications and requirements, i.e., what the application is supposed to do. It uses external descriptions of the software, including specifications, requirements, and designs to derive test cases. These tests can be functional or non-functional, though usually functional.

Specification-based testing may be necessary to assure correct functionality, but it is insufficient to guard against complex or high-risk situations.

One advantage of the black box technique is that no programming knowledge is required. Whatever biases the programmers may have had, the tester likely has a different set and may emphasize different areas of functionality. On the other hand, black-box testing has been said to be "like a walk in a dark labyrinth without a flashlight."Because they do not examine the source code, there are situations when a tester writes many test cases to check something that could have been tested by only one test case, or leaves some parts of the program untested.

This method of test can be applied to all levels of software testing: unit, integration, system and acceptance. It typically comprises most if not all testing at higher levels, but can also dominate unit testing as well.

Visual testing

The aim of visual testing is to provide developers with the ability to examine what was happening at the point of software failure by presenting the data in such a way that the developer can easily find the information he or she requires, and the information is expressed clearly.

At the core of visual testing is the idea that showing someone a problem (or a test failure), rather than just describing it, greatly increases clarity and understanding. Visual testing therefore requires the recording of the entire test process – capturing everything that occurs on the test system in video format. Output videos are supplemented by real-time tester input via picture-in-a-picture webcam and audio commentary from microphones.

Visual testing provides a number of advantages. The quality of communication is increased dramatically because testers can show the problem (and the events leading up to it) to the developer as opposed to just describing it and the need to replicate test failures will cease to exist in many cases. The developer will have all the evidence he or she requires of a test failure and can instead focus on the cause of the fault and how it should be fixed.

Visual testing is particularly well-suited for environments that deploy agile methods in their development of software, since agile methods require greater communication between testers and developers and collaboration within small teams.[citation needed]

Ad hoc testing and exploratory testing are important methodologies for checking software integrity, because they require less preparation time to implement, while the important bugs can be found quickly. In ad hoc testing, where testing takes place in an improvised, impromptu way, the ability of a test tool to visually record everything that occurs on a system becomes very important.[clarification needed][citation needed]

Visual testing is gathering recognition in customer acceptance and usability testing, because the test can be used by many individuals involved in the development process.[citation needed] For the customer, it becomes easy to provide detailed bug reports and feedback, and for program users, visual testing can record user actions on screen, as well as their voice and image, to provide a complete picture at the time of software failure for the developer.
Further information: Graphical user interface testing

Grey-box testing

Main article: Gray box testing

Grey-box testing (American spelling: gray-box testing) involves having knowledge of internal data structures and algorithms for purposes of designing tests, while executing those tests at the user, or black-box level. The tester is not required to have full access to the software's source code.[28][not in citation given] Manipulating input data and formatting output do not qualify as grey-box, because the input and output are clearly outside of the "black box" that we are calling the system under test. This distinction is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test.

However, tests that require modifying a back-end data repository such as a database or a log file does qualify as grey-box, as the user would not normally be able to change the data repository in normal production operations.[citation needed] Grey-box testing may also include reverse engineering to determine, for instance, boundary values or error messages.

By knowing the underlying concepts of how the software works, the tester makes better-informed testing choices while testing the software from outside. Typically, a grey-box tester will be permitted to set up an isolated testing environment with activities such as seeding a database. The tester can observe the state of the product being tested after performing certain actions such as executing SQL statements against the database and then executing queries to ensure that the expected changes have been reflected. Grey-box testing implements intelligent test scenarios, based on limited information. This will particularly apply to data type handling, exception handling, and so on.

Read More

QTP INTERVIEW QUESTIONS

QTP - Interview Questions: Part 4:

Q. 1: What are the Environment Variables?
===================================
Environment variables are global variables available to all Actions
# They can be used to run a test case on different environment
# To add a new Environment variable go to Test -> Settings...->Environment (Tab)
# Environment variables are of two type:
1. Built in environment variables: Provide information about the system and the current test
2. User-Defined environment variables: are added in the Environment tab of Test Settings. These are Read-only during the test run
============================================
Q. 2: How many types of Parameters are there in QTP?
============================================
There are two types of parameters:
1. Test parameters:
# These can be set in Test->Settings...->Parameters (Tab)
# Test parameters value can be provided when replaying the test
# Test arguments can be accessed in the test using TestArgs("")
2. Action parameters :
# Used to pass parameters to Action
# Output parameters can only be used when Action is being called for a single iteration
# Ex - RunAction "Login", oneIteration, "TestUser", "TestPass", out
# A parameter can be accessed using Parameter("ParamName")
================================
Q. 3: What is Descriptive Programming?
================================
Descriptive Programming is an alternate way of writing test cases without having objects in object repository
Descriptive programming can be done in two ways
1. Using Object description
2. Using String description
In Descriptive programming objects are identified by describing all the identification properties
===================================================
Q. 4: After creating the test, what is the purpose of runing them?
===================================================
1) To check your application: The test starts running from the first line in your test and stops at the end of the test. While running, QTP connects to your application and performs each operation in your test, including any checkpoints, such as checking any text strings, objects, tables, and so forth. If you parameterized your test with Data Table parameters, QTP repeats the test (or specific actions in your test) for each set of data values you defined.
2) To debug your application: You can control your run session to help you identify and eliminate defects in your test. You can use the Step Into, Step Over, and Step Out commands to run your test step by step. You can begin your run session from a specific step in your test, or run the test until a specific step is reached. You can also set breakpoints to pause your test at predetermined points. You can view the value of variables in your test each time it stops at a breakpoint in the Debug Viewer.
3) To update your application: You can run your test using Update Run Mode to update the property sets used for test object descriptions, the expected checkpoint values, the data available to retrieve in output values, and/or the Active Screen images and values.
You can run your test using Maintenance Run Mode when you know that your application has changed, and you therefore expect that QTP will not be able to identify the objects in your test. When you run tests in Maintenance Run Mode, a wizard opens for steps that fail because an object could not be found in the application. The wizard then guides you through the steps of resolving the issue, and, after you resolve the issue, the run continues.
==========================================
Q. 5: What are the main stages of Testing with QTP?
==========================================
Testing with QuickTest involves the following main stages:
1) Planning
2) Creating Tests
3) Running Tests
4) Analysing Results
===========================================
Q. 6 : How can we do the Analysis of Results in QTP?
===========================================
After you run your test, you can view the results.
# View the results in the Test Results window: After you run your test, you can view the results of the run in the Test Results window. You can view a summary of your results as well as a detailed report. If you captured still images or movies of your application during therun, you can view these from the Test Results window.
# Report defects detected during a run session: If you have access to Quality Center, the HP centralized quality solution, you can report the defects you discover to the project database. You can instruct QTP to automatically report each failed step in your test, oryou can report them manually from the Test Results window.
================================
Q. 7: What is Business Process Testing?
================================
# Business Process Testing is a role-based testing model that enables Subject Matter Experts-who understand the various parts of the application being tested-to create business process tests in Quality Center. Automation Engineers-who are experts in QTP and automated testing-use QTP to define all of the resources and settings required to create business process tests.
# Business Process Testing uses a keyword-driven methodology for testing, based on the creation and implementation of business components and business process tests. A business component is an easily-maintained, reusable unit comprising one or more steps that perform a specific task within an application.
============================================
Q. 8: What are Permissions Required to Run QuickTest Professional?
============================================
You must have the following file system permissions:
1) Full read and write permissions for all the files and folders under the folder in which QTP is installed
2) Full read and write permissions to the Temp folder
3) Read permissions to the Windows folder and to the System folder
You must have the following registry key permissions:
1) Full read and write permissions to all the keys under HKEY_CURRENT_USER\Software\Mercury Interactive
2) Read and Query Value permissions to all the HKEY_LOCAL_MACHINE and HKEY_CLASSES_ROOT keys
======================================
Q. 9: What is the role of Keyword view in QTP?
======================================
The Keyword View enables you to create and view the steps of your test in a keyword-driven, modular, table format. The Keyword View is comprised of a table-like view, in which each step is a separate row in the table, and each column represents different parts of the steps. You can modify the columns displayed to suit your requirements.
You create and modify tests by selecting items and operations in the Keyword View and entering information as required. Each step is automatically documented as you complete it, enabling you to view a description of your test steps in understandable English.
Each operation performed on your application during a recording session is recorded as a row in the Keyword View.
====================================
Q. 10: What is the role of Expert view in QTP?
====================================
In the Expert View, QTP displays each operation performed on your application in the form of a script, comprised of VBScript statements. The Expert View is a script editor with many script editing capabilities. For each object and method in an Expert View statement, a corresponding row exists in the Keyword View

Q. 11: Where can we use a Function or an Action?
========================================
It all depends on the scenario.
If you want to use the OR feature then you have to go for Action only. If the functionality is not about any automation script i.e. a function like getting a string between to specific characters, now this is something not specific to QTP and can be done on pure VB Script, so this should be done in a function and not an action. Code specific to QTP can also be put into an function using DP. Decision of using function/action depends on what any one would be comfortable using in a given situation.
===================================================
Q. 12: What is the difference between an Action and a Function?
===================================================
Action is a activity specific to QTP while functions are a generic thing which is a feature of VB Scripting. Action can have a object repository associated with it while a function can't. A function is just lines of code with some / none parameters and a single return value while an action can have more than one output parameters.
================================================
Q. 13: What are the various events available in the Recovery Scenario Manager?
================================================
1) Application Crash: This event is useful in handling crashed applications at runtime.
2) Pop Up Window: This event is useful in managing various unwanted application windows, which get built-up at runtime.
3) Test Run Error: This event is useful in handling VBScript statement errors at runtime.
4) Object State: This event is useful in handling object related errors at runtime.
=========================================
Q. 14: What are the Elements of Recovery Scenario?
=========================================
Steps to handle the exceptions are
1) Trigger Event: Is an unexpected event like appearance of a Pop-up window, object state, test run error causing application crash or interruption in our running session.
2) Recovery Steps: Constitutes a series of steps required to be performed to enable QTP to proceed further with the process of test after some trigger event has interrupted the run session. Examples of a recovery operation can be 1) A keyboard or mouse Operation like a Click over the "OK" button in the Pop-up window 2) Close Application Process 3) Function Call 4) Restarting the OS etc.
3) Post-Recovery Test Run: Are a set of instructions designed to be provided to QTP on proceeding further with the test after some recovery operation has been carried out. Examples of Post Recovery actions can be repeating the complete test from the beginning or some steps may be skipped altogether & continuing with the remaining steps in the test.
=====================================================
Q. 15: When to use a Recovery Scenario and When to use "on error resume next"?
=====================================================
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. 16: What are the key features of QTP at a glance:
=========================================
# Ease of use: QTP allows even novice testers to become productive in minutes. You can create a test script by simply pressing a Record button and using an application to perform a typical business process. Each step in the business process is automated documented with a plain-English sentence and screen shot. Users can easily modify, remove, or rearrange test steps in the Keyword View.
# Simple interface: QTP is much simpler to understand. It presents a test case as a simple business workflow to the tester.
# Simple Language: QTP uses Microsoft's VBScript for its test procedures, and to manipulate the objects and controls of the application under test. VBScript is a real programming language where several existing functions & resources are easily available for implementation these days.
# Use of zero-configuration Technology: QTP uses next-generation "zero-configuration" Keyword Driven testing technology. This helps in faster test creation, easier maintenance, and provides more powerful data-driving capability.
# Automatic insertion of checkpoints: QTP enables thorough validation of applications through a full complement of checkpoints. QTP can automatically introduce checkpoints to verify application properties and functionality, for example to validate output or check link validity.
# Marvelous interface with Data-tables: QTP allows entry of test data into the Data Table, an integrated spreadsheet with the full functionality of Excel, to manipulate data sets and create multiple test iterations, without programming, to expand test case coverage. Data can be typed in or imported from databases, spreadsheets, or text files. QTP has better and easier to use Data table integration compared to WinRunner.
# Better object identification mechanism: QTP Identifies objects with Unique Smart Object Recognition, even if objects change from build to build, thereby enabling reliable unattended script execution.
# Support of variety of environment: QTP supports functional testing of all popular environments, like Windows, Web, .Net, Visual Basic, ActiveX, Java, SAP, Siebel, Oracle, PeopleSoft, terminal emulators, and Web services.
# Easy adaptability of Microsoft Object Models: QTP can easily create and implement Microsoft Object Model like: Outlook objects, ADO objects, FileSystem objects, supports DOM, WSH, etc.
# Auto-documentation technology: QTP renders test documentation and test creation to a single step with the help of its auto-documentation technology
=================================================
Q. 17: What are various types of properties when using object identification in QTP?
=================================================
QTP uses three types of properties when identifying a object
1. Mandatory Properties - Always learn these properties for the object
2. Assistive Properties - Learn in case Mandatory properties are not enough to identify the object uniquely
3. Ordinal identifiers - Learn in case both mandatory and assistive properties are not able to recognize the objects correctly
=====================================================
Q. 18: What are the various ways to insert a Action in a test in QTP?
=====================================================
There are three ways to insert a Action in a test
1. Insert Call to New...
2. Insert Call to Copy...
3. Insert Call to Existing...
========================================
Q. 19: What is the use of Parameterization in QTP?
========================================
Parameterization is helpful in following aspects.# Parameterization allows us to pick different values at run time.
# Reduces Time and Effort.
# Usage of data drivers allows us to use the same data for various input boxes.
# Parameterization can also be done for checkpoints.
=============================
Q. 20: What are Data Tables in QTP?
=============================
Data Table is MS Excel like spreadsheet which can be used for parameterizing a test case
DataTable are of two types:
1. Global Data Table - Data table for Test flow
2. Local data table - Data table for every action

Read More

DATABASE TESTING

Data base testing materials with real time scenarios:

Basics of Database testing contains the following:

1. How to connect to the database?

2. Ability to write simple queries to retrieve data and manipulate the data using DML operations.

3. Functional flow should be very well known!

4. Good knowledge on table level, column level constraints, ability to understand and execute complex queries related to joins is added advantage.

Data base testing basically include the following. 

1)Data validity testing. 

2)Data Integritity testing 

3)Performance related to database. 

4)Testing of Procedure triggers and functions. 

For doing data validity testing you should be good in SQL queries 

For data integrity testing you should know about referintial integrity and different constraint.

For performance related things you should have idea about the table structure and design. 

For testing Procedure triggers and functions you should be able to understand the same.


This document is to discuss general test specification issues for SQL server back end testing and

to provide testers a test design guide that includes test methodology.

Most systems, i.e. Forecast LRS, Delta, KENAI, KBATS and so on, that are developed by ITG

have client-server architectures. However, only a few projects have their back end completely tested.

1. Why back end testing is so important

2. Characteristics of back end testing

3. Back end testing phases

4. Back end test methods

1. Why back end testing is so important

A back end is the engine of any client/server system. If the back end malfunctions, it may cause system deadlock, data corruption, data loss and bad performance. Many front ends log on to a single SQL server. A bug in a back end may put serious impact on the whole system. Too many bugs in a back end will cost tremendous resources to find and fix bugs and delay the system developments.

It is very likely that many tests in a front end only hit a small portion of a back end. Many bugs in

a back end can not be easily discovered without direct testing.

Back end testing has several advantages: The back end is no longer a "black box" to testers. We have full control of test coverage and depth. Many bugs can be effectively found and fixed in the early development stage. Take Forecast LRS as an example, the number of bugs in a back end was more than 30% of total number of bugs in the project. When back end bugs are fixed, the system quality is dramatically increased.

2. Differences between back end testing and front end testing

It is not easier to understand and verify a back end than a front end because a front end usually
has friendly and intuitive user interfaces.

A back end has its own objects, such as, tables, stored procedures and triggers. Data integrity and protection is critical. Performance and multi-user support are big issues. Slowness in operation can be vital to the project’s future.

There are no sufficient tools for back end testing. SQL language is mainly a testing tool. MS Access and MS Excel can be used to verify data but they are not perfect for testing. However, there are a large number of test tools available for front end testing.

To be able to do back end testing, a tester must have strong background in SQL server and SQL language. It is relatively difficult to find testers who understand both SQL server and SQL testing. This causes a shortage of back end testers.

3. Back end testing phases

There are several phases in back end testing. The first step is to acquire design specifications for an SQL server. The second step is test specification design. The next step is to implement the tests in this design with SQL code. The test specification design should contain information concerning component testing (individual pieces of the system), regression testing (previously known bugs), integration testing (several pieces of the system put together), and then the entire system (which will include both front and back ends).

Component testing will be done early in the development cycle. Integration and system tests (including interfaces to front ends and nightly processes) are performed after the component tests pass. Regression testing will be performed continuously throughout the project until it is finished. The back end
usually does not have an independent beta test, as it only exercised by the front end during the beta test
period. The last step is to deliver users a quality product.

4. Back end test methodolodogy

Back end test methodology has many things in common with front end testing and API testing. Many test methods can be used for back end testing. Structural testing and functional testing are more effective approaches in back end testing. They are overlapped in some test cases. However, the two methods may discover different bugs. We strongly recommend testers to do both types of testing.
There are many other test methods that can be applied to back end testing. We list a few below.
For other test methods, please check other test design references.

Structural testing:

A back end can be broken down into a finite number of testable pieces based on a back end’s

structure. Tests will verify each and every object in a type of structure.

Functional testing:

A back end can be broken down into a finite number of testable pieces based on application’s functionality. The test focus is on functionality of input and output but not on the implementation and structure. Different projects may have different ways to break down.

Boundary testing:
Many columns have boundary conditions. For example, in a column for percentages, the value can not be less than zero and can not be greater than 100%. We should find out these types of boundary conditions and test them.

Stress testing:
It involves subjecting a database to heavy loads. For incidence, many users heavily access the same table that has a large number of records. To simulate this situation, we need to start as many machines as possible and run the tests over and over.

Read More

INTERVIEW QUESTIONS ON QTP

QTP 4 years real time interview quetions and answers:

1.How many types of Parameters are available in QuickTest Professional (QTP)?

QTP provides three types of Parameter-

* Method Argument

* Data Driven

* Dynamic

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

This is default behaviour.

3. How Does Run time data (Parameterization) is handled in QTP?

You can then enter test data into the Data Table, an integrated spreadsheet with the full functionality of Excel, to manipulate data sets and create multiple test iterations, without programming, to expand test case coverage. Data can be typed in or imported from databases, spreadsheets, or text files.

4. If I give some thousand tests to execute in 2 days what do you do?

Adhoc testing is done. It Covers the least basic functionalities to verify that the system is working fine.

5. 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 manulaly which cannot be restricted from getting created.

6. Explain about the Test Fusion Report of QuickTest Professional (QTP) ?

Once a tester has run a test, a TestFusion report displays all aspects of the test run: a high-level results overview, an expandable Tree View of the test specifying exactly where application failures occurred, the test data used, application screen shots for every step that highlight any discrepancies, and detailed explanations of each checkpoint pass and failure. By combining TestFusion reports with QuickTest Professional, you can share reports across an entire QA and development team.

7. 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..

8. How to handle the exceptions using recovery secnario manager in QuickTest Professional (QTP)?

You can instruct QTP to recover unexpected events or errors that occured in your testing environment during test run. Recovery scenario manager provides a wizard that guides you through the defining recovery scenario. Recovery scenario has three steps

1. Triggered Events

2. Recovery steps

3. Post Recovery Test-Run

9. What’s the basic concept of QuickTest Professional (QTP)?

QTP is based on two concept-

* Recording

* Playback.

10. Why use Regular Expressions?

you created a text checkpoint that searched for a specific text string. You can use regular expressions to increase the flexibility and adaptability of your tests.

Regular expressions enable QuickTest to identify objects and text strings with varying values. You can use regular expressions when defining the properties of an object, the methods of an argument, when parameterizing a step, and when creating checkpoints with varying values.

Read More

INTERVIEW QUESTIONS ON OBJECT REPOSITORY

Object Repository Interview Questions -QTP:

Define Object Repository in QTP.

Object Repository is used to store objects which QTP learns. Object repository stores things like logical name, properties (identification) etc. of an object.

Define Object Repository Manager.

Object Repository Manager enables you to create and modify single/multiple shared object repositories. You can save the shared object repository to your Quality Center project using the Object Repository Manager. Object Repository Manager helps you to Work with Repository Parameters, merge two Shared Object Repositories, import and export Shared Object Repositories using XML.

Can you export Local Objects to a Shared Object Repository using Object Repository Manager?

No, its done with the help of Object Repository Window.

What are the Drawbacks/Disadvantages of Shared Object Repository?

Multiple users working on Shared Object Repository can’t edit it concurrently.

Any small or big change in shared Object Repository affects all associated test cases.

There MAY be performance issue(s) if size of shared Object Repository is big. For example, if any object is vague / unclear then QTP has to assign some additional properties in order to recognize it uniquely and many other similar issues may slow down Object Repository performance.

Explain Object Repository parameter.

Repository parameters are useful when you want to create and run tests on an object that changes dynamically. As an example suppose there is a button whose text property value changes in a localized application depending on the language of the user interface. You can parameterize the name property value using a repository parameter, and then in each test that uses the shared object repository you can specify the location from which the property value should be taken. For example, in one test that uses this shared object repository you can specify that the property value comes from an environment variable.

In another test it can come from the data table. In a third test you can specify it as a constant value.

Can we update an Object Repository parameter at run-time?

You can set or retrieve the value of repository parameters using the Repository object [An object that enables you to work with repository parameters.]. All changes made to repository parameters using the Repository object are temporary, and are valid only for the current run session.

In order to set the value of a repository parameter use:

Repository (RepositoryParameterName) = NewValue

In order to retrieve the value of an existing repository parameter use:

CurrentValue = Repository (RepositoryParameterName)

How would you load an Object Repository at run time?

Using "Add" Method of RepositoriesCollection, as this adds an object repository file to the specified index position in the run-time collection of shared object repository files associated with the current action.

Syntax:

RepositoriesCollection.Add RepositoryPath [, Position]

RepositoryPath is the absolute or relative path of the shared object repository that you want to add and Position Number is the index position to which you want to add the shared object repository in the run-time list of associated shared object repositories. If you do not specify a position, the object repository is added to the end of the list (position = -1).

Explain kind of conflicts that occur when you try to merge two Shared Object Repositories?

An object in the primary object repository could have the same name as an object in the secondary object repository, but have a different description.

Read More

OBJECT IDENTIFICATION IN QTP

QTP : Object Identification

The process of uniquely identifying an object from the application window is known as Object Identification. QTP uses two modes object identification. to recognize the object uniquely.

• Normal Identification mode
• Smart Identification mode
• Ordinal  Identifiers

Normal Identification

QTP has two lists of properties based on which it will identify the object uniquely. The first list is the list of mandatory properties. QTP learns these default property values and checks if any object matches the description. If no object in the application is identified uniquely it adds properties from the second list called as assistive properties. All the properties in the assistive list are added one by one till a unique object is identified.
 
 Ordinal Identifiers

Even after using mandatory and assistive properties if the object is not uniquely identified then QTP uses the ordinal identifiers to identify the object uniquely.There are three types of ordinal identifiers :

1. Index: This identifier indicates the order in which the object appears in the application code. This order is unique even though identical objects are present.
2. Location: This identifier indicates the order in which the object appears within the window, frame or dialog box irrespective of objects with identical description.
3. Creation Time: This identifier is applicable only to web applications. This identifier indicates a unique id in the order in which the browser were opened. This identifier is handy in identifying the browser to be worked on when a group of identical browsers are open.

Smart Identification

When normal identification fails to identify a unique object. QTP switches to next mode of identification called smart identification, the smart identification mode must be enabled for the test. The smart identification mechanism uses two lists of properties:

• Base Filter Properties: The list of properties contain the most fundamental properties of a particular test object class whose values cannot be changed without changing the original object. 
• Optional Filter Properties: Other properties that can help identify objects of a particular class as they are unlikely to change on a regular basis, but which can be ignored if they are no longer applicable.

Read More

REGULAR EXPRESSION IN QTP

REGULAR EXPRESSION EXAMPLE

Regular Expressions

A regular expression is a special text string for describing a search for describing a search pattern. You can think of a regular expression as a wild card.You are probably familiar with wild card notations such as *.doc to find all word files in a file manager.

Grouping Regular ExpressionsMultiple Regular Expressions Characters can be combined in a Single Expression. For example :

Window("text:= .*(Report|Graph)").Close

The above line closes a window with Text Report or Graph preceded by any set of alphanumeric characters.

Using  the Backlash Character( \ )

The backlash can be used along with a Regular Expression Character to indicate that the next character be treated as a literal character. ex:-

Browser("Yahoo").Page("Yahoo").Link("text:= .*\..*").Click

Here the backlash is preceded by the .(period) so the .(period) will be considered literal & not a Regular Expression.

Regexp Object

You can use regular expressions in VBScript by creating one or more instances of the RegExp object. This object allows you to find regular expression matches in strings, and replace regexp matches in strings with other strings. You can create this object in scripting as shown below:

Regexp Rx = New Regexp

Read More