QTP Certification Practice Questions To Test Your Skills-1

I have posted the answers below.

1. How many tabs are there in Test Settings (File->Settings) window

A) 5
B) 6
C) 7
D) 8

2. 'Browser navigation timeout' is in which tab of Test Settings (File->Settings) window?

A) Properties
B) Resources
C) Web
D) Web Settings

3. Identify the tabs in the Test Settings (File->Settings) window

A) Properties, Run, Resources, Parameters, Environment, Web, Recovery
B) Properties, Run, Resources, Parameters, Environment, Web Settings,Recovery
C) Properties, Run Options, Resources, Parameters, Environment, Web, Recovery
D) Properties, Run, Resources, Input Parameters, Environment, Web, Recovery

4. 'Generate Script' is in which tab of Test Settings (File->Settings) window

A) Properties
B) Resources
C) Web
D) Recovery

5. For each object and method in an Expert View statement, a corresponding row exists in the Keyword View.

A) True
B) False
C) There is some problem with the statement.
D) None of above

6. The following are the four main columns in the Keyword view

A) Item, Operation, Value, Comments
B) Item, Operation, Value, Documentation
C) Item, Operation, Property, Documentation
D) Number, Operation, Value, Documentation

7. You can work on one or several function libraries at the same time.

A) True
B) False

8. You can insert additional steps on the test objects captured in the Active screen after the recording session.

A) True
B) False

9. The Active Screen enables you to parameterize object values and insert checkpoints

A) True
B) False

10. A QTP user can increase or decrease the active screen information saved with the test.

A) True
B) False

Answers:

1. C
2. C
3. A
4. A
5. A
6. B
7. A
8. A
9. A
10.A

Read more...

Am I doing Too Little or Too Much Automation.

We shall be able to count a large number of possible test cases for any system although fact may be that we might be having too little a time to execute only a few of them. Even if this number may be small, still we would expect to detect majority of our bugs out of these whatever small number of test cases.

Hence identification of test cases to be created & to be executed is an important activity. Random selection of our test cases is not a good approach for testing. Hence for the development of good test cases, a carefully designed approach is necessary

Am I trying to do too much of Automation:
Testers usually commit this common mistake of doing too much of automation & that also too soon. Intuitively, testers would be tempted to feel that having more number of automated tests better it would be. But this would be wrong. This belief would leave us with plenty of poorly automated tests, which shall become quite difficult & uneconomical to maintain.

If we go on adding more & more automated tests we shall land up with unwanted duplication, redundancy & increased cost of their maintenance. Hence it is better to start with small numbers of good but diversified tests and automate them. Here it is ideal to begin with say 10-15 tests involving 2-3 hours of interactive testing.

Am I automating the Wrong Tests:
It is not wise to attempt to automate every test case just because the benefit of automating some of the tests is outweighing the cost of automating them. In fact some of the test cases cannot be automated however if some dedicated tester pulls up his strings, can get success in automating them at a very high cost but with no tangible benefit.

However after gaining some reasonable experience of automation testing one can predict with reasonable accuracy the time it will take to automate a particular test. The decision as to which of the test cases to be automated and which of these to be automated first, is quite crucial & is based upon the likely pay back.

Attributes of test case, which can be likely candidate for automation, are as under:
1) Any test which can be expected to run several times. It is quite natural that more the times a test case is made to usefully run the more beneficial an automated version of it will be. Regression tests, which are made to run every time a new version of software is created, are best suitable for automation.

2) Input verification tests, for example checking that an edit box accepts values in a valid range only. Such tests are quite boring by nature & prone to error for manual operation.

3) Tests, which are expensive to execute manually, for example multi-user tests, which take a long, time to run.

4) Tests, which are difficult to execute manually, for example test cases which are timing critical or are complex to execute.

5) Tests, which require persons having special knowledge, like business knowledge or system’s knowledge can be good candidates for automation.

Attributes of test case, which are unlikely to be candidate for automation, are as under:
1) Any test which will not be expected to run many times. If a test case is not run many times just because there had been no need to run it often (rather than because it could be costly to run it often manually) then it should not be automated.

2) Test cases, which are not important, will definitely not find important bugs. Naturally, If a bug is not important it is not wise to invest time & money in finding it, especially when such bugs are not going to be fixed.

3) Usability test, which cannot be automated because usability, is an issue related to human interactions.

4) Any test which is difficult to automate. Test cases, which would take a lot of effort to automate, are generally not worth automating.

5) Any test which is expensive to maintain. Even if a test case is quite simple to automate but if it is vulnerable to changes in the software it would not be worth automating, because it would be very costly to maintain it.

6) A test case which might have a lot of value in itself, but if it duplicates some or all of the value of an existing test case then the value of the new one gets reduced to almost zero. Such test cases are also not worth automating.

Best Lessons learnt:
1) Where full automation is not warranted, consider partial automation.

For example, it may be difficult to automate the execution of a particular complex test case but it may be possible and beneficial to automate the comparison of some of the results of the test case with the expected results. Alternatively, where the execution of test case cannot be automated may be due to some technical reasons, but it may be possible and beneficial to automate some parts of it like data preparation and clear-up.

2) There is a great learning curve in the beginning, hence it is best not to automate many test cases to start with because they may not be as good & fit for automation, compared to the ones we could automate later on after having learnt more about good practices.

3) It is better to focus on relatively few tests, trying out different implementations and assessing their relative strengths and weaknesses before automating large numbers of tests.

Remember that many case histories have made startling revelation, that over 70% of bugs are found by manual testing & not by automated testing in-spite of the fact that the automated tests had been designed & developed with great efforts of many years. Hence think well before automating your tests.

Keyword: Test Automation, Best Practice,


Read more...

Points to Think while buying an Automation Tool

While deciding to buy a particular automation tool, following key indicators are given due consideration .
Automation Tool Evaluation:
* Platform/OS independence
* Data driven capability
* Customizable Reporting
* Email Notifications
* Easy debugging and logging
* Headless execution for unattended runs
* Support distributed execution environment
* Distributed application support
* Licensing (Cost) and Support
* Ease of use, available training and documentation

Key Word : Automation, Tool Selection


Read more...

An Overview of the Testing Process in QTP

To have an understanding of the basics of QTP, you can visit http://qtpgoodtutorials.blogspot.com

Introduction to QTP:

QTP (Quick Test Professional) is an excellent Record/Playback tool which enables us to create tests and business components by doing a live recording of all the operations being performed by us on our application.

Introduction to Tests in QTP:

A Test is a set of several steps organized into one or more actions, which can be used to verify the compliance of our application in line with our expectations. In QTP, Test comprises of three types of actions like

1) Non-reusable action.
2) Reusable action.
3) External action.

Testing in QTP follows following six simple steps:

Step – 1: Planning

Prior to building a test in QTP, it is essential to do necessary planning for preparation of a sound infrastructure required. Planning may include:

a) Making a decision on the functionality we wish to be tested.

b) Making a decision as to whether to conduct brief tests aimed to check some specific functions of the application or checking the complete application / site.

c) Making a decision as to how to organize the object repositories.

Step – 2: Creation of Tests or Components

In QTP, a test or a component can be created by either of the following:

Method –1: Recording a session on the Application or the Web site
While doing navigation across our application, each & every step followed by us is graphically displayed by QTP as a row in the “Keyword View”.

The “Documentation” column of the “Keyword View” displays an easy to understand & self-explanatory description of each & every step taken by us. Here the term “Step” is an activity, which creates some change in our application, like clicking a link or an image or submitting a data form etc. etc.

Method –2: Building an object repository
An object repository is built & these objects are used to manually add steps in the “Keyword View” or the “Expert View”. The Test or components can subsequently be modified by using special testing options or with programming statements.


Step – 3: Insertion of Checkpoints in the Tests or Components

A checkpoint is a verification point, which draws a comparison among a recent value for some specified property with respect to the expected value for that property. The idea of inserting checkpoints in tests or components is to enables us to identify as to whether the application is functioning properly or not.


Step – 4: Replacement of Fixed Values with Parameters

Fixed values are replaced with parameters thereby broadening the scope of our test.

The test or component can be parameterized in order to ascertain the performance of the application under different set of input data. When parameterization of test or component is done, QTP automatically replaces the fixed values with parameters. Every execution, which uses a particular set of parameterized data, is known as an “Iteration”.

“Output Values” can be used to extract the data from our test or component. An “Output Value” is a value retrieved during the run session and subsequently fed into the Data Table or saved as a variable or a parameter. Such Output Value can be used as an Input Data in the Test or Component.

QTP is a highly versatile functional testing tool having several great features to improve the testing process. We can include several programming statements to QTP process for achieving highly complex testing goals.

Step – 5: Execution of the Test

Once the Tests or components are created, they are executed to check the application.

During execution of the test or component, QTP integrates with the application and performs each & every operation in the test or component, checks all text strings, objects, or tables already specified.

In case parameterization of the test has been done with parameters defined in Data Table, QTP repeats all the specified actions for every set of data values already defined by us.

Run the tests or components with a view to debug it. We can control the run session to identify and eliminate the defects in them.

We can use the following commands to execute a test or component step by step.

Step Into,
Step Over,
Step Out

Breakpoints can also be defined to pause the test or component at some pre-defined point. We can view the value of all variables in the test or component every time it pauses at some predefined breakpoint in the Debug Viewer.


Step – 6: Analysis of Results

It is the concluding portion of the test after running the test or component.

Results are viewed in the Results window: We can view a summary of all the results as well as have a detailed report.

Reporting of Defects: HP Quality Center is a very good Bug Logging tool having excellent compatibility with QTP. All the detected defects can be logged in its database. QTP can be pre instructed to automatically report every failed step during the run alternatively reporting can be done manually as well.

Keywords: QTP, quicktest, HP, quality center, record/playback, expert view, keyword view, reusable actions

Read more...

Learn the Basics of Closing the Processes using QTP

The article will discuss on how to close processes in QTP. First we will discuss the SystemUtil object and then later in the article few other approaches.

SystemUtil Object

SystemUtil is utility object provided by QTP. It can be used to launch or closes a process. Let's look at various methods supported by this object:

SystemUtil.Run file, [params], [dir], [op], [mode]

The Run method allows running a new process. The code below illustrates few example on how to launch a process using SystemUtil object

'Run internet explorer
SystemUtil.Run "iexplore.exe"

'Run internet explorer and open google.com
SystemUtil.Run "iexplore.exe", "http://www.google.com"

'Run a IE Process in Maximized window
Const SHOW_MAXIMIZED = 3 'Activates the window and displays it as a maximized window.
SystemUtil.Run "iexplore.exe", "http://www.google.com", , , SHOW_MAXIMIZED

SystemUtil.CloseProcessByName (bsProcessName)

CloseProcessByName method allows closing a process by its name. The code below illustrates few examples

'Close all internet explorer windows
closedCount = SystemUtil.CloseProcessByName("iexplore.exe")

'Display # of closed windows
MsgBox closedCount

The problem with using the above method is that it will also close Quality Center (QC) window even if script was launched from QC. This method should be used in case you are not concerned about running scripts from QC.

SystemUtil.CloseProcessByWndTitle (bsTitle, [bRegExp])

CloseProcessByWndTitle method allows closing a process by its title. The title can also be supplied as a regular expression by setting the bRegExp to True

'Launch a notepad window
SystemUtil.Run "notepad.exe"

'Close the window just launched using the exact title
SystemUtil.CloseProcessByWndTitle "Untitled - Notepad"

'Launch a notepad window
SystemUtil.Run "notepad.exe"

'Close the window just launched using a pattern string
SystemUtil.CloseProcessByWndTitle ".*Notepad", True

SystemUtil.CloseDescendentProcesses

CloseDescendentProcesses can be used to close any process launched by QTP. The code below illustrates the usage

'Launch explorer
SystemUtil.Run "iexplore.exe"

'Launch excel using COM
Set oXL = CreateObject("Excel.Application")
oXL.Visible = True

'Close processes launched by QTP. This will close
'the internet explorer and Excel as well
SystemUtil.CloseDescendentProcesses

This method is best suited to be used during the end of a script to cleanup any process left open.

Closing all open Browsers

Many times it's required to close all open browsers at the start of the script. There are various ways of achieving this; one is to use the SystemUtil.CloseProcessByName method which we discussed earlier. But that approach is not generic as it won't close other browsers that QTP does support (like firefox and netscape). We can come with a generic 3 lines code which can close all supported QTP browsers

'Check the existence of a browser and close it
'until no more browsers exist
While Browser("creationtime:=0").Exist(0)

'Close the browser
Browser("creationtime:=0").Close

Wend

QTP assigns creation time to each browser based on the launch time of that browser. A browser started earlier will have a lower creationtime and a browser started at a later point of time will have a higher creationtime. So when we start closing the browser with creationtime:=0, other browser's creationtime is decreased. Which means that the creationtime:=0 browser will always exist until there is no browser open. This approach of closing browsers suffers from 2 issues

* QTP has a bug which makes it wait 10 second on Browser identified using creationtime when there is only one browser open. So above code will always take 10 secs to close the last browser
* The code does not allow to ignore any specific browser (like Quality Center)

Though there another way by which can enumerate all open browser and close them in QTP and below demonstrates the same

'Create a description for browser
Set oBrowser = Description.Create
oBrowser("micclass").Value = "Browser"

Set oPage = Description.Create
oPage("micclass").Value = "Page"

'Get all browsers
Set allBrowser = Desktop.ChildObjects(oBrowser)

Dim i, iCount

iCount = allBrowser.Count - 1

For i = 0 To iCount
'Get the page object from the browser
Set oPg = allBrowser(i).ChildObjects(oPage)(0)

'Get the URL of the
If InStr(oPg.GetROProperty("title"), "Quality Center", vbTextCompare) = 0 Then
'Close the browser
allBrowser(i).Close
End If
Next

By now you must be wondering about the line

'Get the page object from the browser
Set oPg = allBrowser(i).ChildObjects(oPage)(0)

So why didn't we use allBrowser(i).Page("micclass:=Page"), well this a Bug or Limitation in QTP which does not allow using any further Test objects on objects returned from ChildObjects. This might be because of the fact that a QTP TestObject does not have any property or method as other Test Object. Ex - a Browser supports no method or property named Page. But QTP interprets that as way of hierarchy to decide where to look for that object. Anway this is all my opinion and might not be accurate. So the only workaround of using further TestObjects is to use ChildObjects again.

Closing processes using WMI

Another way to close a process is to use Window management instrumentation (WMI)

'Name/IP of the computer
sComp = "."

'Get the WMI object
Set WMI = GetObject("winmgmts:\\" & sComp & "\root\cimv2")

'Get collection of processes for with name iexplore.exe
Set allIE = WMI.ExecQuery("Select * from Win32_Process Where Name = 'iexplore.exe'")

'Loop through each process and terminate it
For Each IE in allIE
IE.Terminate()
Next

Above code can also be used to close any process on a remote machine by changing sComp to the IP of the remote machine

Closing Internet explorer using Shell

Let's take a look at another way which is generic to VBScript and not dependent on QTP. For this we will use the COM object of "Shell.Application". This COM library provides a collection of all open windows (Explorer + Internet Explorer). We can access each windows property and close if it is iexplore.exe process. The code below demonstrates the same

'Create the shell application object
Set shlApp = CreateObject("Shell.Application")

'Get all open windows collection
Set allWins = shlApp.Windows

'Loop through each window and close if IE
For Each window In allWins
If InStr(window.fullName, "iexplore.exe") Then
'Close the IE window
window.Quit
End If
Next

The code above will only close alternate windows. This happens because we are loop through a collection of windows and closing a window in that collection reduces the collection and hence the for loop skips one window after closing a window. This issue can easily be resolved by adding the windows to be closed into an array and the closing them later

Dim windows2Close

'Initialize with negative upper bound
ReDim windows2Close( -1)

'Create the shell application object
Set shlApp = CreateObject("Shell.Application")

'Get all open windows collection
Set allWins = shlApp.Windows

'Loop through each window and close if IE
For Each window In allWins
'Close all IE windows but ignore Quality Center
If InStr(window.fullName, "iexplore.exe") And InStr(Window.LocationURL, "/qcbin/") = 0 Then

'Increase the array size by 1
ReDim Preserve windows2Close(UBound(windows2Close) + 1)

Set windows2Close(UBound(windows2Close)) = Window
End If
Next

'Loop through all array elements and close each window
For Each Window In windows2Close
Window.Quit
Next

The above code shows how to ignore few internet explorers and close rest.

Summary

In this article we explored various ways of Closing processes and browsers using QTP.


Read more...

Quick Introduction to QTP 9.2

New to Quick Test Pro 9.2?

Are you new to HP Quick Test Pro 9.2 (QTP)? Say yes and you are at the right place, at the right time. This article is for newbie’s who want to start their carrier with QTP or have just started with QTP. The article will give you a brief overview of various features of QTP, and since it is for newbie’s we won’t be going into too much details of every feature.

What is QTP 9.2?

* HP Quick Test Pro 9.2 is a functional automation and regression testing tool
* QTP provides record and playback of events
* Uses VBScript as the scripting Language
* Provides keyword view and expert view to view test cases.
* Latest versions of QTP is 9.5 (launched in mid Jan 2008)
* Previous version of QTP: 6.5, 8.0, 8.1, 8.2, 9.0, 9.1
* QTP was previously owned by Mercury Interactive®

Installing QTP 9.2

You can download a 14 day Trial version from HP site.

QTP 9.5 14 day Evaluation

With introduction of QTP 9.5, Trial version of QTP 9.2 is not available. QTP 9.5 does not have any huge enhancement and hence most of the features discussed in this article will still hold

Launching QTP

When you launch QTP for the first time, Add-in manager window is displayed

What is Add-in?

* QTP requires Add-in for recognizing object of a specific environment
* By default QTP 9.2 comes with 3 Add-ins: Web, ActiveX and VB
* Some of the Add-ins available for QTP 9.2 are

1. Terminal Emulator (TE)
2. .NET
3. Java
4. SAP
5. Siebel
6. Stingray
7. VisualAge
8. Web Services

* QTP does not require any Add-in to work on Standard windows application
* Add-ins can only be loaded when starting QTP

Once the selected Add-ins are loaded, QTP window will show up

Hit the record button to start recording. If you are recording for the first time, the Record and Run Settings dialog box opens.

What all tabs are shown in above dialog would depend on Add-ins that is loaded. Using above dialog we can set on what all application should QTP record on.

Note: If QTP does not record anything on your application then make sure you have the correct settings specified in Record and Run Settings…

Keyword view

The Keyword View enables you to create and view the steps of your test in a keyword-driven, modular, table format. This is the only view where complete Test flow can be viewed.

Expert View

In Expert View, QTP displays each operation performed on the application in the form of a script, comprised of VBScript statements. Complete test flow is not available/visible in this view.

Test and Run-time Object

* QTP works on objects in Application Under Test (AUT) by storing object description
* This object description is known as a Test Object
* Each Test Object supports predefined sets of Methods and properties
* The actual object in the AUT which is identified for a Test Object is called the Run-time object.
* A Test Object can always be present without the AUT
* Run-time object can only be present when AUT is up and running

Object Spy

Object Spy is a tool that can be used to spy Test and run time object for looking at properties and methods supported by object being spied

Object Identification

* QTP uses three types of properties when identifying a object

1. Mandatory – Always learn these properties for the object
2. Assistive – 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

* Ordinal identifiers are of three types:
1. Index – index of object (0, 1, 2 …)
2. Location – Location of the object on the screen (0, 1, 2 …)
3. CreationTime – Used only for Browser. Launchtime of browser (0, 1, 2 …)

Object Identification Settings

Launch from menu Tools->Object Identification…

Here we can Add/Remove properties from/to Mandatory and Assistive properties. Objects in application represent certain special characteristics which allow QTP to map them QTP Test object. For window objects this characteristic is mostly define by ”regexpwndclass“. In case application developers don’t use standard class names while creating object QTP won’t be able to identify the object correctly. Below is a checkbox in Search window recognized by QTP as WinObject

By clicking on the ”User Defined…“ button on Object identification settings window, we can add such objects and map. Once added QTP will now be able to recognize the object correctly

Object Hierarchy

* QTP uses object hierarchy to identify object inside a AUT
* QTP only adds those objects from hierarchy which are necessary for it to identify the object later.
* In this case QTP will add
Browser(”Google“).Page(”Google“).WebEdit(”q“).Set ”test“ (WebTable object ignored)
* QTP cannot be configured to record such objects automatically.

Object Repository (OR)

* QTP works on object in application by storing information about the object in Object repository
* All objects on which user takes an action while recording are automatically added to object repository
* ”Browser“, ”Google“, ”q“ are three different objects that would be present in OR for the below generated statement

Browser("Browser").Page("Google").WebEdit("q").set ”Test“

* Copying and pasting code from one script to another script does not work in QTP as the OR does not get copied to the new script
* There are two types of Object Repositories in QTP:
1. Shared OR: Can be used by multiple scripts. A central location to store all objects
2. Per-Action OR: Every action has its individual object repository

Per-Action Object Repository

* Default repository
* Specific to actions (Will be used only for a particular action)
* Preferable when application is not dynamic with respect to time
* Cannot be reused

Shared Action repository

* Can be updated by all actions accessing it
* Preferable when application is dynamic with respect to time
* Used in most automation projects
* Needs maintenance and administration

Action

* Provides way of grouping code into business logic
* Are pretty similar to Functions in VBScript
* Have their own Data Table and Object Repository (in case of per-action object repository)
* Supports input and output parameters
* Actions are of two types: normal and re-usable
* Re-usable actions can be called in other Test.
* QTP does not allow calling another test within a test
* TestFlow represent the top level action. Complete test flow can only be viewed in Keyword views

Inserting Actions

* 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…

* Insert Call to New… - Creates a new action and adds a call to the same. Pfrovide the name "Cancel Ticket" in the "Name" field and click on OK button.
* Adds below line to the code

RunAction "Cancel Ticket", oneIteration

Actions - Insert Call to Existing…

* Insert Call to Existing – User to insert call to a re-usable action located within the same test or some other test
* This inserts the call to the existing action. In case the action in present in some other test case then a read only copy of action is inserted

Actions – Insert Call to Copy…

* Insert Call to Copy - Inserts call to an existing re-usable action and creates an editable copy of that action
* Actions cannot be deleted from a Test from Expert view. To delete a action one must go to the keyword view and delete the action
* An action call cannot be inserted directly by writing code in Expert View, it has to be added through the GUI first.

Action Iterations

An action can be run for 1 or more rows from its Local Data Table.

* QTP supports there types of iteration modes:
1. Run one iteration only
2. Run on all rows
3. Run from Row to Row

* Similar to Action, a test can also be run for multiple iterations from Global Data Table

Why Parameterization?

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

Data Table

* Data Table is excel like spreadsheet which can be user 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

* Data table value can be accessed using the below method
a) DataTable("",dtGlobalSheet)
b) DataTable("",dtLocalSheet)
c)DataTable("","")

Run-time Data table

* Any changes made to Data table during run-time is stored in run-time data table.
* Run-time data table is available in the test results summary of a test
* DataTable values can be changed at run-time by using below mentioned code:

DataTable(”OrderConf“, dtGlobalSheet) = ”ABCD1234“

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 types

1. Built-in
2. User-Defined

* Built in environment variables give information about the system and the current test
* User-defined Environment variables added in the Environment tab of Test Settings are Read-only during the test run
* Environment variables can be added during runtime also using code
Environment.Value(”OrderNumber“) = ”ABCDEF“
* Environment variables can be loaded at run-time from a XML file using the below code
Environment.LoadFromFile "C:\TestEnvironment.xml"
* The Environment XML file has to be in below format:



APP_URL
http://test1.appserver.com



Parameters

* Parameters provide another way of parameterizing the test cases
* There are two types of parameters:
1. Test parameters
2. Action parameters

* Test parameters 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(”“)

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")

Resources

* Scripts written in VBScript language can be add as a Resource to the test
* All code written in the script is available across all Actions
* A VBScript can also be loaded in an Action by using ExecuteFile function. Ex –
ExecuteFile ”C:\Init.vbs“
* In case of multiple files QTP combines all the files into a single one and executes the code. The files are combine in bottom to top order

Checkpoints

* Checkpoints are verification points in a test
* Test without checkpoint would never have a pass status
* Checkpoints can be of types
– Built-in checkpoints
– Custom checkpoints
* Types of Built-in checkpoints available are

1. Standard checkpoints: Verify properties of an object
2. Text checkpoints: Verify text presence between two strings
3. Text Area checkpoint
4. Bitmap checkpoint
5. Accessibility checkpoint
6. Database checkpoint
7. XML Checkpoint

* Only Database and XML checkpoints can be inserted in idle mode.
* Rest all checkpoints can only be added during Recording or through Active screens.
* Checkpoint code

Browser("Google").Page("Google").WebEdit("q").Check CheckPoint("Verify TextBox_Standard")

Custom Checkpoints

* Custom checkpoints can be created using Code

loginExist = Browser().Page().Link(”text:=Login“).Exist(0)
If loginExist then
Reporter.ReportEvent micPass, ”Check Login“, ”Login link exists“
Else
Reporter.ReportEvent micFail, ”Check Login“, ”Login link does not exists“
End if

* Custom checkpoint can be made flexible based on implementation and are preferred over Built-in checkpoints

Test Results

Test results provide a execution summary of the complete test case
* There are different types of status in test results summary:
1. Passed
2. Failed
3. Done
4. Warning
5. Information

Descriptive Programming

* 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 DP objects are identified by describing all the identification properties
* String description DP
Browser(”title:=Google“).Page(”title:=Google“).WebButton(”name:=Search“).Click
* Object Based DP
Set btnSearch = Description.Create : btnSearch(”name“).Value = ”Search“
Set brwGoogle = Description.Create : brwGoogle(”title“).value = ”Google“
Set pgGoogle = Description.Create : pgGoogle(”title“).value = ”Google“
Browser(brwGoogle).Page(pgGoogle).WebButton(btnSearch).Click

* Description objects can also be used to get all child objects matching a criterion. Ex –

Set oDesc = Description.Create
oDesc(”name”).Value = ”txt_.*“
oDesc(”name”).RegularExpression = True
Set allMatchingObjects = Browser().Page().ChildObjects(oDesc)
Msgbox allMatchingObjects.Count
Msgbox allMatchingObjects(0).GetROProperty(”name“)

* By default all property values are considered as regular expression patterns
* When using string description all regular expression must be used with escape character for literal meaning. Ex - …Link(”text:=Logout \(Piyush\)“).Click

* DP based Object repository can be created in any file
* Code can be copied from one script to another without copying the object repository
* Custom implementation of object is easier. Ex –

objStrDesc = ”Browser(”“title:=Test““).Page(”“title:=Test““).Link(”“text:=Login““)“
Execute ”Set obj = ” & objStrDesc
obj.Click

QTP Misc information

* QTP and the AUT has to be on the same machine
* QTP can be controlled remotely from another machine
* QTP scripts cannot be run without QTP




Read more...

Basics of Debugging Run Errors in QTP

First of all let us understand the meaning of “General run error” as you are seeing above.

“General run error” occurs in a situation when some source while being accessed by QTP propels an error.

This is the inherent nature of QTP that in such a situation it displays a "General run error" message instead of showing a simple “Error” .

Following line of a simple code will illustrate as to how the "General run error" shall be generated.

Set oGeneralRunError = GetObject("A.B.C")

On running the above code, you will get an error message "Invalid Syntax"

Here we can see that the actual error is in-fact an “Invalid Syntax Error” and not a "General run error". However to view the actual error in this case, click on the “Debug” button and open the Watch Window.

It is simple to fix the “General run error”

- Incase we get this type of error while working on a QTP test object; we can place a Msgbox to check the existence of the object being handled.

- However if we get this type of error while working under the Web environment, the issue can be resolved by using DOM object method.

Keywords: QTP, quicktest professional, HP QTP, debug general run error



Read more...

QTP Script to display System Date and Time

QTP Script to display System Date and Time

msgbox now

Above code will display System Date and Time = 5/20/2008 9:01:05 AM

msgbox date

Above code will display only System Date = 5/20/2008

msgbox time

Above code will display only System Time = 9:01:05 AM


Read more...

Descriptive Programming to count and close all open browsers

Script to get count,names of all open browsers and to close them.

Set b=Description.Create
b("micclass").value="Browser"
Set obj=Desktop.ChildObjects(b)
msgbox obj.count
For i=0 to obj.count-1
c=obj(i).getroproperty("name")
msgbox(c)
obj(i).Close
Next


Read more...

Descriptive programming for Google search page

Descriptive programming for Google search page

SystemUtil.run "iexplore.exe","http://www.google.com"
Browser("name:=Google.*").Page("title:=Google.*").WebEdit("name:=q")
.set"Testing"
Browser("name:=Google.*").Page("title:=Google.*").
WebButton("name:=Google Search").Click


Read more...

Descriptive Programming to check all checkboxes in a webpage

Usage of Description Object is shown below

Creates a new, empty description object in which you can add collection of properties and values in order to specify the description object in place of a test object name in a step.

Set Button=Description.Create()

Button("type").Value="submit"
Button("name").Value="Google Search"
Button("html tag").Value="INPUT"

Browser("Google").Page("Google").WebButton(Button).Click

TO CHECK ALL THE CHECKBOXES ON A PAGE USING CHILDOBJECTS PROPERTY

Dim obj_check

Set obj_check=Description.Create

obj_Check("html tag").value="INPUT"
obj_Check("type").value="checkbox"

Dim allcheckboxes
Set allcheckboxes=Browser("Browser").Page("orkut - home").ChildObjects(obj_check)
a= allcheckboxes.count()
msgbox a

For i=0 to (a-1)
allcheckboxes(i).Set "ON"
Next


Read more...

Scripts for Data Driven Testing using Notepad & Datatables

Data Driven Testing using notepad

Set f=CreateObject("Scripting.FileSystemObject")
Set f1=f.CreateTextFile("c:\text.txt")
f1.writeline "aaa bbb"
f1.writeline "ccc ddd"

The above script creates a notepad in C: drive with following contents:

aaa bbb
ccc ddd

Set f2=f.OpenTextFile("c:\text.txt")
While f2.AtEndOfStream <>true
f3=f2.readline
x=Split(f3, "")
msgbox x(0)
msgbox x(1)
WEnd

The above script is used for data driven using notepad directly. Here we are not importing data to excel sheet. Directly values are retreived from notepad. We are using while loop and reading each line till the end. Split function splits the line where space(" ")occurs. Line is divided to 2 parts.one before space and other after space. For example we have 1st line in notepad as aaa bbb

here aaa is 1st part and bbb is 2nd part

x(0)=aaa
x(1)=bbb

all values are read this way using while loop. One point to note here is if any line is empty in notepad datadriven testing is stopped before that line. It will not proceed further.so we have to give values without any empty lines in notepad. To make things more clear,

Suppose u have

aaa bbb

ccc ddd

Datadriven is stopped at aaa and bbb only because next line is empty. Datadriven is stopped after 1st line.

Datadriven using dataTable

This Script gives result by retrieving values from datatable.

A B
5 5
6 6
7 7
8 8
9 9

In datatable enter test data as shown above.
Fill values below "A" and "B"

script required for DDT(data driven testing)is

val1=datatable("A",1)
val2=datatable("B",1)
res=cint(val1) +cint(val2)
msgbox res

Result will be 10,12,14,16,18.

datatable("column name",sheetname/id)

cint is a function which converts string to integer.

check what will happen if u are not using cint in third step.
just replace this res=val1+val2 in place of res=cint(val1) +cint(val2)


Read more...

Connecting to MS Access through QTP

This code connects your QTP to MS Access. Pretty cool though..

Option Explicit
Dim con, rs

Set con=CreateObject("adodb.connection")
Set rs=CreateObject("adodb.recordset")

con.provider="microsoft.jet.oledb.4.0"
con.open "c:\db1.mdb"

rs.open "select * from emp", con

Do while rs.eof="False"
msgbox rs.fields("v1")
msgbox rs.fields("v2")
rs.movenext
Loop


Read more...

QTP Quiz

Article under maintenance


Read more...

Passing keyboard inputs to AUT through QTP

This site has been brought to you by an HP certified expert of QTP.

It is my continuous endevour to give the best to my readers.

This article is under updation will be available to you shortly.

ExpertQTP
http://quicktesthp.blogspot.com

Ways to send keyboard input to an application using QTP when it does not record using normal recording



Read more...

Amazing power of QTP for Import & Export of Data from datatable using QTP

Import External Data File

The datatable created by QTP can be exported to an external location. Pretty Cool though….

Now lets see how it is done. Create a new script. Now open your DataTable and right click inside any cell using the mouse. Click File-> Import from File. You will see a screen as shown below.

Click on the OK button. Now navigate to an already existing excel file, select and click Open. With this, your excel file will be opened in the datatable completely. Now every column you create in the excel sheet will become a parameter.

This task can also be accomplished programmatically. For this, use the following syntax.

Datatable.Import(FileName)

Here FileName is the full path of the Excel table to import.

Exporting Datatable to an external File

You guys probably be thinking just like we imported an external excel file into our datatable, is the reverse also true. Yes, it is. We can export our created datatable into an external excel file. This we can do if we want to utilize our existing datatable inside a different script rather than creating it from the scratch again.

Lets see how it is being done. Again, open your datatable and right click on any cell. Select File->Export. Provide the file name and click on the Save button. Wow..You are done.

There is one more way to accomplish the above mentioned task. We can programmatically export our datatable. The syntax for doing the same is:

DataTable.Export(FileName)

Here “FileName” is the full path of the location to which the Data Table should be exported. For example:

DataTable.Export(“C:\Expert.xls”)

Note: For detailed information, you can see the inbuilt help file provided by QTP.

Keywords: QTP, Excel, ExcelSheet, datatable, parameterize


Read more...

Usage of Datatable: Parameterization

Usage of DataTable

Datatable is infact an excel sheet which is embedded into the QTP with datatable as name. It is mainly used to parameterize the scripts. We have to make the constant value as parameter, so that in each iteration(cycle) it takes a value that is supplied in run-time datatable. Through parameterization only we can drive a transaction (action) with different sets of data.

There are two types of sheets inside the QTP datatable:
1. Global DataTable
2. Local DataTable

Global dataTable is created by default with every new script and Local Datatable is created everytime when a new Action is created inside the script. You can even view the contents of your DataTable inside the file “Default.xls” which is created on saving the script.

Now, lets see how we can really utilize the datatable in our scripting.

1. Create a new script and open your browser and navigate to http://www.gmail.com.
2. Start recording and provide a dummy username and password say “User1” and “Pass1”.
3. Stop your recording.

You will see a script like this:

Browser("Browser").Page("Gmail: Email from Google").WebEdit("Email").Set "user"
Browser("Browser").Page("Gmail: Email from Google").WebEdit("Passwd").SetSecure “48af0f9632214bc0964877b44a4e"

4. Now create two columns in Global DataTable named “Username” and “Password”.
5. Provide “user1” and “user2” in the first two rows of above created “Username” column.
6. Similarly provide “pass1” and “pass2” in the first two rows of the above-created “Password” column.

Now in order to access the values created in Datatable, we will use DataTable associated methods properties. The most popular is “Value” which is the default datatable property. Now let us see how do we access values stored in dataTable.

UserID1=DataTable.Value(“UserName”,dtGlobalSheet)
Pass1= DataTable.Value(“Password”,dtGlobalSheet)

Here “UserName” is the name of DataTable column and dtGlobalSheet signifies we are working with the datatable. Here, you can also ommit "Value" which is optional.

Now add these two lines into your script and so your script will look like:

UserID1=DataTable(“UserName”,dtGlobalSheet)
Pass1= DataTable(“Password”,dtGlobalSheet)

Browser("Browser").Page("Gmail: Email from Google").WebEdit("Email").Set "user"
Browser("Browser").Page("Gmail: Email from Google").WebEdit("Passwd").SetSecure “48af0f9632214bc0964877b44a4e"

Now modify the above two lines so that they will look like:

Browser("Browser").Page("Gmail: Email from Google").WebEdit("Email").Set UserID1 Browser("Browser").Page("Gmail: Email from Google").WebEdit("Passwd").Set Pass1

What I have done in the above script? Any guesses.. Instead of hard coded values, I infact parameterized my script so that my usernames and passwords come from run time datatable.

In order to move your pointer to next row, I mean if you want to use your second row, just use:

DataTable.SetNextRow

Now the real powerful feature of qtp is it can run my script for all datatable values. For this, click File->Settings. Navigate to Run tab inside Test Settings dialog box. Select “Run on all rows” option and click OK button. Run your script and voila you are done………



Read more...

Checking the status of a process in RAM through QTP

This site has been brought to you by an HP certified expert of QTP.

It is my continuous endevour to give the best to my readers.

This article is under updation will be available to you shortly.

ExpertQTP
http://quicktesthp.blogspot.com


Read more...

Open QTP through VBScript when it is already Closed

Following illustration created in VBScript launches the QTP when it is already closed from the beginning means no process in the RAM.

Set obj = CreateObject("QuickTest.Application") 'Creates an instance of the QTP
obj.Launch
obj.Visible = True
obj.WindowState = "Maximized" 'Maximizes the application window of the QTP
obj.ActivateView "ExpertView" 'Displays the Expert View of the QTP
obj.open "D:\ExpertQTP", False 'Opens the script from C:\ ExpertQTP in an editable mode
obj.Test.Run 'Runs the script
obj.Quit 'Quits the QTP application

Anyways, thereafter we can paste the above script in a Text Editor like “Notepad”, provide the name as "ExpertQTP.vbs" and save this file in the D:\ drive. And lastly, dont forget the double quotes which will go along with the name..

Keywords: QTP, hp quicktest, VbScript


Read more...

AOM : Automation Object Model

Automating QuickTest Operations

Just as you use QuickTest to automate the testing of your applications, you can use the QuickTest Professional automation object model to automate your QuickTest operations. Using the objects, methods, and properties exposed by the QuickTest automation object model, you can write programs that configure QuickTest options and run tests or components instead of performing these operations manually using the QuickTest interface.

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

About Automating QuickTest Operations

You can use the QuickTest Professional automation object model to write programs that automate your QuickTest operations. The QuickTest automation object model provides objects, methods, and properties that enable you to control QuickTest from another application.

What is Automation?

Automation is a Microsoft technology that makes it possible to access software objects inside one application from other applications. These objects can be easily created and manipulated using a scripting or programming language such as VBScript or VC++. Automation enables you to control the functionality of an application programmatically.

An object model is a structural representation of software objects (classes) that comprise the implementation of a system or application. An object model defines a set of classes and interfaces, together with their properties, methods and events, and their relationships.

What is the QuickTest Automation Object Model?

Essentially all configuration and run functionality provided via the QuickTest interface is in some way represented in the QuickTest automation object model via objects, methods, and properties. Although a one-on-one comparison cannot always be made, most dialog boxes in QuickTest have a corresponding automation object, most options in dialog boxes can be set and/or retrieved using the corresponding object property, and most menu commands and other operations have corresponding automation methods.

You can use the objects, methods, and properties exposed by the QuickTest automation object model, along with standard programming elements such as loops and conditional statements to design your program.

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

For example, you can create and run an automation program from Microsoft Visual Basic that loads the required add-ins for a test or component, starts QuickTest in visible mode, opens the test or component, configures settings that correspond to those in the Options, Test or Business Component Settings, and Record and Run Settings dialog boxes, runs the test or component, and saves the test or component.

You can then add a simple loop to your program so that your single program can perform the operations described above for multiple tests or components.

You can also create an initialization program that opens QuickTest with specific configuration settings. You can then instruct all of your testers to open QuickTest using this automation program to ensure that all of your testers are always working with the same configuration.

Deciding When to Use QuickTest Automation Programs

Like the tests or components you design using QuickTest, creating a useful QuickTest automation program requires planning, design time, and testing. You must always weigh the initial investment with the time and human-resource savings you gain from automating potentially long or tedious tasks.

Any QuickTest operation that you must perform many times in a row or must perform on a regular basis is a good candidate for a QuickTest automation program.

The following are just a few examples of useful QuickTest automation programs:

Initialization programs—You can write a program that automatically starts QuickTest and configures the options and the settings required for recording on a specific environment.
Maintaining your tests or components—You can write a program that iterates over your collection of tests and components to accomplish a certain goal. For example:
Updating values—opening each test or component with the proper add-ins, running it in update run mode against an updated application, and saving it in order to update the values in all of your tests and components to match the updated values in your application.
Applying new options to existing tests or components—When you upgrade to a new version of QuickTest, you may find that the new version offers certain options that you want to apply to your existing tests and components. You can write a program that opens each existing test and component, sets values for the new options, then saves and closes it.
Calling QuickTest from other applications—You can design your own applications with options or controls that run QuickTest automation programs. For example, you could create a Web form or simple Windows interface from which a product manager could schedule QuickTest runs, even if the manager is not familiar with QuickTest.

Read more...

Pros & Cons of going in for Automated Testing

When to use the Automation tools:
Great effort is required in firstly automating the test cases and maintaining them thereafter. Hence some sort of cost-benefit analysis is quite helpful before investing money and putting efforts into it.

The test engineer should evaluate whether the likely benefits of automation are fitting within the boundaries of the required improvement criteria and whether the pursuit of automated testing on the project is still logical & falling within the framework of organizational needs.

Automation is suited to following types of testing with specific intentions:
1) Functional Testing – on operations which perform as per the expectations.

2) Regression Testing – on the behavior of the system which has not been changed.

3) Exception Testing – thereby forcing error conditions in the system.

4) Stress Testing – to determine the absolute capacities of the application and operational infrastructure.

5) Performance Testing – to provide assurance that the performance of the system will be adequate for both batch runs and online transactions in relation to business projections and requirements.

6) Load Testing – to determine the points at which the capacity and performance of the system become degraded to the situation that hardware or software upgrades would be required.

Benefits of Automated Testing:

1) Reliable: Tests perform precisely the same operations each time they are run, thereby eliminating human error. Hence it produces a reliable system.

2) Repeatable: You can test how the software reacts under repeated execution of the same operations.

3) Programmable: You can program sophisticated tests that bring out hidden information from the application.

4) Comprehensive: You can build a suite of tests that covers every feature in your application.

5) Reusable: You can reuse tests on different versions of an application, even if the user interface changes.

6) Better Quality Software: It Improves the quality of the testing effort. Because you can run more tests in less time with fewer resources

7) Fast: It reduces the test effort by minimizing the schedule. Automated Tools run tests significantly faster than human users.

8) Economical: As the number of resources for regression test are reduced.

Choosing the right tools for the job and targeting the right areas of the organization to deploy them can only realize these benefits. The right areas where the automation fit must be chosen.

Disadvantages of Automation Testing:
Though the automation testing has many advantages, it has its own disadvantages too. Some of the disadvantages are:

# Proficiency is required to write the automation test scripts.

# Debugging the test script is major issue. If any error is present in the test script, sometimes it may lead to deadly consequences.

# Test maintenance is costly in case of playback methods. Even though a minor change occurs in the GUI, the test script has to be re-recorded or replaced by a new test script.

# Maintenance of test data files is difficult, if the test script tests more screens.

Ultimately how to decide – Whether to go in for Automated Testing or Manual Testing?

1) Based upon the frequency of use of Test Cases:
Automating a test case requires almost 3-4 times the effort as compared to manual execution of it once. To draw benefit out of significant investment in the automation tool, we should be able to execute the automation script the maximum number of times or at least 7-8 times. There is no worthwhile idea of going in for an automation tool for short-term product, which can be easily managed by manual means. For products involving many rounds of testing, the use of an automation tool is understandable.

2) Time comparison:
Automated versus Manual Testing: Generally an automation script runs much faster as compared to manual execution. However post execution activities are considerably time consuming. After running the automation script fully; time consuming activities are the analysis of test results & investigation or identification of actions causing failure at defined checkpoints. Whereas in case of manual execution of the test script, there is no need of any separate time for analysis of the results, since the actions causing failure at checkpoints become already known.

Hence automated testing is viable only if, the combined time spent on running the automation script as well as doing post automation analysis of test results is significantly less in comparison to the time spent on manual execution. However nicely developed automation scripts do not need constant monitoring and can run without any manual intervention. In such a case automation can be greatly productive & can cut down the time of running the scripts.

However when large number of regression issues are there after fixing the bugs, automation is the best alternative. Manual testing can be extremely time consuming in such cases.

3) Reusability of Automation Scripts:
The automated testing is viable in case automation scripts are reusable in future as well. One may be compelled to think again in favor of automation if considerable effort is expected to be made in upgrading the automation scripts. The return on investment made on the automation tool can be maximized by reusability of the automation scripts with small modifications.

4) Stability of the Product under Test:
Automation scripts are not advisable for use on software product, which itself is not adequately stable. Frequent changes in automation script are not desirable, thus unless the product acquires enough stability during its development cycle, there is no point in automation unless we are operating in an agile environment.

5) Adaptability of test cases for automation:
A statement that, "All test cases can easily be automated" – is not true. Many a times we land up with some type of test cases, which are not worth automating. Hence there is no point in wasting automation effort over such test cases. For complicated product with tightly integrated bunch of many applications, running the automation script again & again in the event of stoppage of the test case, can become a pain in the neck. In such cases tester would certainly prefer to run the script manually & save considerable amount of time as compared to running the automated script.

6) Exploitation of automation tool:
If we want to go in for automated testing of a product, we must draw full benefit out of the test tool to draw the maximum return on its investment. The automation tool should be deployed for performing less complicated / time consuming & repetitive tasks. This will help the test engineers in concentrating their time & energy on other significantly important tasks. There is no point in automating highly complex test cases, which can easily be executed manually.

Automation tool should be deployed to test the breadth of the application under test. However manual test engineers can handle the in-depth testing more efficiently.

Manual testing can not be totally eliminated in any way. Automation scripts have both advantage and disadvantages in the sense that they perform actions exactly in the way they are coded to perform without any deviation. For even a slight deviation, the script needs to be changed. Running the same automated script again & again will not detect more bugs. However to detect more & more bugs, we need to move across the side & have little deviation from the flow, & such actions can be better accomplished by manual testing.

When a test case is perfectly designed & made to execute from end to end automatically through the tool without, it automatically verifies all predefined check points without any manual intervention.

7) User simulation over large web application: For simulation of several virtual / dummy users interacting over a large web application, load testing automated tools like LoadRunner etc. can be easily deployed to establish the load bearing functionality of the application. Such load testing by manual means is extremely difficult. Thus in spite of many disadvantages & harms from automated scripts, the automation testing is adapted widely all over the world.

Key Word: Automation Testing, Manual Testing, Pros & Cons


Read more...

Frequently Asked Interview Questions on Test Automation

1. What automating testing tools are you familiar with?

Win Runner , Load runner, QTP , Silk Performer, Test director, Rational robot, QA run.

2. How did you use automating testing tools in your job?

1. For regression testing
2. Criteria to decide the condition of a particular build

3. Describe some problem that you had with automating testing tool.

The problem of winrunner identifying the third party controls like infragistics control.

4. How do you plan test automation?

1. Prepare the automation Test plan
2. Identify the scenario
3. Record the scenario
4. Enhance the scripts by inserting check points and Conditional Loops
5. Incorporated Error Handler
6. Debug the script
7. Fix the issue
8. Rerun the script and report the result.

5. Can test automation improve test effectiveness?

Yes, Automating a test makes the test process:
1.Fast
2.Reliable
3. Repeatable
4.Programmable
5.Reusable
6.Comprehensive

6. What is data - driven automation?

Testing the functionality with more test cases becomes laborious as the functionality grows. For multiple sets of data (test cases), you can execute the test once in which you can figure out for which data it has failed and for which data, the test has passed. This feature is available in the WinRunner with the data driven test where the data can be taken from an excel sheet or notepad.

7. What are the main attributes of test automation?

software test automation attributes :
Maintainability - the effort needed to update the test automation suites for each new release
Reliability - the accuracy and repeatability of the test automation
Flexibility - the ease of working with all the different kinds of automation test ware
Efficiency - the total cost related to the effort needed for the automation
Portability - the ability of the automated test to run on different environments
Robustness - the effectiveness of automation on an unstable or rapidly changing system
Usability - the extent to which automation can be used by different types of users

8. Does automation replace manual testing?

There can be some functionality which cannot be tested in an automated tool so we may have to do it manually. therefore manual testing can never be repleaced. (We can write the scripts for negative testing also but it is hectic task).When we talk about real environment we do negative testing manually.

9. How will you choose a tool for test automation?

choosing of a tool depends on many things ...
1. Application to be tested
2. Test environment
3. Scope and limitation of the tool.
4. Feature of the tool.
5. Cost of the tool.
6. Whether the tool is compatible with your application which means tool should be able to interact with your application
7. Ease of use

10. How you will evaluate the tool for test automation?

We need to concentrate on the features of the tools and how this could be beneficial for our project. The additional new features and the enhancements of the features will also help.

11. What are main benefits of test automation?

FAST ,RELIABLE,COMPREHENSIVE,REUSABLE

12. What could go wrong with test automation?

1. The choice of automation tool for certain technologies
2. Wrong set of test automated

13. How you will describe testing activities?

Testing activities start from the elaboration phase. The various testing activities are preparing the test plan, Preparing test cases, Execute the test case, Log the bug, validate the bug & take appropriate action for the bug, Automate the test cases.

14. What testing activities you may want to automate?

1. Automate all the high priority test cases which needs to be executed as a part of regression testing for each build cycle.

15. Describe common problems of test automation.

The common problems are:
1. Maintenance of the old script when there is a feature change or enhancement
2. The change in technology of the application will affect the old scripts

16. What types of scripting techniques for test automation do you know?

5 types of scripting techniques:
Linear
Structured
Shared
Data Driven
Key Driven

17. What are principles of good testing scripts for automation?

1. Proper code guiding standards
2. Standard format for defining functions, exception handler etc
3. Comments for functions
4. Proper error handling mechanisms
5. The appropriate synchronization techniques

18. What tools are available for support of testing during software development life cycle?

Testing tools for regression and load/stress testing for regression testing like, QTP, load runner, rational robot, winrunner, silk, testcomplete, Astra are available in the market. -For defect tracking BugZilla, Test Runner are available.

19. Can the activities of test case design be automated?

As I know it, test case design is about formulating the steps to be carried out to verify something about the application under test. And this cannot be automated. IHowever, I agree that the process of putting the test results into the excel sheet.

20. What are the limitations of automating software testing?

Hard-to-create environments like “out of memory”, “invalid input/reply”, and “corrupt registry entries” make applications behave poorly and existing automated tools can’t force these condition - they simply test your application in “normal” environment.

21. What skills needed to be a good test automator?

1.Good Logic for programming.
2. Analytical skills.
3.Pessimistic in Nature.

22. How to find that tools work well with your existing system?

1. Discuss with the support officials
2. Download the trial version of the tool and evaluate
3. Get suggestions from people who are working on the tool

23. Describe some problem that you had with automating testing tool.

1. The inability of winrunner to identify the third party control like infragistics controls
2. The change of the location of the table object will cause object not found error.
3. The inability of the winrunner to execute the script against multiple languages.

24. What are the main attributes of test automation?

Maintainability, Reliability, Flexibility, Efficiency, Portability, Robustness, and Usability - these are the main attributes in test automation.

25. What testing activities you may want to automate in a project?

Testing tools can be used for :
* Sanity tests(which is repeated on every build),
* stress/Load tests(U simulate a large no of users,which is manually impossible) &
* Regression tests(which are done after every code change)

26. How to find that tools work well with your existing system?

To find this, select the suite of tests which are most important for your application. First run them with automated tool. Next subject the same tests to careful manual testing. If the results are coinciding you can say your testing tool has been performing.

27. How will you test the field that generates auto numbers of AUT when we click the button 'NEW" in the application?

We can create a textfile in a certain location, and update the auto generated value each time we run the test and compare the currently generated value with the previous one will be one solution.

28. How will you evaluate the fields in the application under test using automation tool?

We can use Verification points(rational Robot) to validate the fields .Ex.Using objectdata,objectdata properties VP we can validate fields.

29. Can we perform the test of single application at the same time using different tools on the same machine?

No. The Testing Tools will be in the ambiguity to determine which browser is opened by which tool.

31. What is 'configuration management'?

Configuration management is a process to control and document any changes made during the life of a project. Revision control, Change Control, and Release Control are important aspects of Configuration Management.

32. How to test the Web applications?

The basic difference in web testing is here we have to test for URL's coverage and links coverage. Using WinRunner we can conduct web testing. But we have to make sure that Webtest option is selected in "Add in Manager". Using WR we cannot test XML objects.

33. what are the problems encountered during the testing the application compatibility on different browsers and on different operating systems

Font issues,alignment issues

34. how exactly the testing the application compatibility on different browsers and on different operating systems is done

Please Send Your Suggestion

35. How testing is proceeded when SRS or any other document is not given?

If SRS is not there we can perform Exploratory testing. In Exploratory testing the basic module is executed and depending on its results, the next plan is executed.

36. How do we test for severe memory leakages ?

By using Endurance Testing .
Endurance Testing means checking for memory leaks or other problems that may occur with prolonged execution.


Read more...

QTP as a Versatile Functional Testing Tool

Introduction:
QTP is an automated functional Graphical User Interface testing tool created by the HP, with which we can do the automation of user actions on a web or client based computer applications. QTP provides an highly interactive & visual environment for the test development.

It is generally used for functional regression test automation. Since WinRunner has become obsolete now, hence QTP takes its place due to many advanced features & updates.

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

# Better functionality compared to WinRunner: QTP is significantly easier & better compared to WinRunner in following aspects.

a) Adaptation and creation of working test cases.
b) Implementation of Test Run Iterations / Data driving of test
c) Parameterization
d) More robust test report

# Other marvelous features of QTP:
a) Key word driven testing
b) Better error handling mechanism
c) Excellent data driven testing features
d) XML support
e) By using ActiveScreen, QTP can enhance existing QuickTest scripts without the "Application Under Test" being available.
f) Easy execution of WinRunner scripts from QTP.
g) Operates stand-alone, or integrated into HP Quality Center.

Key Word: QTP, Quicktest, Functional Testing Tool, Features QTP


Read more...

Crucial Decision – Whether to Automate my Testing or Not

Let us firstly delve upon some of the role of Man versus Tool in a Testing Project.
# Analysis of the Product – Done by Human
# Designing of the Test – Done by Human
# Execution of the Test 1st time – Done by Human
# Evaluation of the Results – Done by Human
# Reporting of the 1st Bug – Done by Human
# Saving of the Code – Done by Human
# Saving of the Results – Done by Human
# Documentation of the Test – Done by Human
# Re-run the Test – Done by Tool
# Evaluation of the Results – Done by Tool as well as human in case of a mismatch
# Maintenance of the Results – Done by Human

Is it not interesting to note that in a software project human intervention plays a major role & can’t be dispensed with? We may be living with a notion that machine or a tool will lighten the burden of humans to great extent, it might be a fair illusion. In practical scenarios, ratio of human effort versus tool effort may be as high as 90:10.

In spite of full knowledge of such odds, test automation eases out the burden of testers to a great extent. That is why many automation tools are getting popularity.

Now Let us see the situations when to automate our Testing Process:
Decision of automating the testing does not remain an intelligent one in all situations. There can be many situations wherein automated testing may not be viable. Thus to decide whether and when to automate or not is a crucial one. A decision in favor of automation requires proper analysis and near drawing of clear-cut boundaries between automated test plan and the manual test plan. Planning needs to be done for the use of programming language like Visual Basic or C# because writing of test scripts itself is a software development activity consuming great amount of time.

There is no hard & fast rule to judge as to what should be tested manually and what should be tested with the help of automated test scripts. It is a matter of experience which itself is a best judge. However there are a few preliminary questions, which a team leader can raise before taking a decision in favor of automated testing of a project. The following considerations shall be of great help to us in ascertaining, as to whether it is worthwhile to automate the testing process of the particular project or not.

1) Consideration of Manpower Skills & Project Complexity:
There are many occasions when Project Managers are found to go in for automated testing projects giving due consideration to the skill levels of the manpower available with them. Availability of personnel of desired skill levels is extremely important for the success of any project.
Few key aspects needing careful consideration are:

a) Understand the scope of the automated testing:
If we are aiming at completely automating all the tests, then the scope of testing is totally unrealistic.

However for introducing automated testing in some of the existing projects or into an absolutely new project – it is better to begin with little but manageable targets. We should not adventure into unrealistic or unmanageable targets. Since the skill levels of all testers & programmers are bound to be different, we should be sure of the capability & experience level of these personnel. To check this aspect, we can ask the team members to write down a few simple utilities which can support our testing project using Visual Basic or C#.

b) Know the automation skill level of the testing team fully well:
If the existing team is quite new to the area of automation, we should not make unnecessary haste. We should allocate sufficient time & resources for imparting proper training to them.

Before starting an automation project for the first time, we would need to reinforce the present team of testers by the induction of experienced automated testing personnel. The level of experience of testing personnel shall be the measure of level of automation the organization shall be able to handle. Thus skill & experience of the testing personnel is of prime importance for the overall success of the automation project.

c) Check the real availability of the experienced testers:
In case experienced & skilled testers are present in the organization, still it is important to ascertain as to whether these people are actually available or not. Many a times it would happen that the projects would take off with strong teams with the participation of experienced members, but over a passage of time such people will migrate to other newer projects.

2) Consideration of Product related aspects:
All applications being tested are not created equal. Generally, when automated test scripts are written, we work behind the GUI, meaning thereby we just create & polish various bits & pieces of the software. We need to do thorough planning to ascertain as to whether these activities are in line with the requirements of our product.
Few key aspects needing careful consideration are:

a) Whether the application is sufficiently stable or not:
We should not attempt creation of automation scripts unless & until the application has acquired a sufficient degree of stability. Otherwise what will happen is that every day you will be engaged in updating your test script to match the changes happening in the unstable application. Hence if we start ambitiously too soon, we might land up wasting the precious time & money. Automated testing is best suited to products which have acquired enough stability of structure and elements.

b) Are we going to test the User Interface:
Some of the automated testing tools are specifically tailored to suit the GUI. Thus for the testing of the GUI of an application under test, we should try to deploy such specifically tailored automated testing tools as compared to others. Some of the cheaper / open source tools may also be helpful.

c) Frequency of repetition of Test Runs:
If we are forced to repeat the test runs on large frequency – say more than ten times, it is worthwhile to go in for automated testing. Computers are best suited to repetitive tasks perfectly without any strain. Regression testing to resolve high-priority bugs needing repetition of the similar test time & again can be called a perfect case for automation. Doing Build Verification Test on a software product to verify its robustness, build after build is also ideal for going into automation due to being of repetitive nature.

d) Compatibility over multiple platforms:
Majority of the software product are expected to be used over different versions of OS. In MS Windows family itself so many versions are available like Vista, XP, Win 2K, WinNT, Win9x etc.. Compatibility aspect of the application needs to be given due consideration & automated testing scripts should be designed to take care of such compatibility aspects.

e) Cost economics justifying the automation:
Automated testing can be time consuming & a bit taxing on the pocket initially, but can lead to addition of a lot of value to the project. Still for smaller projects it may not be economically viable. But for large projects it would certainly prove to be a cost saver.

3) Test-Management Aspects:
Few key test management related aspects needing careful consideration are:

a) Availability of proper Software tools relevant to the project:
Ready availability of adequate number of seats of all relevant software tools is very essential.

b) Introduction of automated testing in between existing testing process:
When automation is to be inserted between the existing testing process, it calls for proper integration of the test scripts with manual tests & ordinary commercial tools. This can become extremely time consuming. Hence important aspect of introduction of test automation in between the other testing process should be given due consideration that it should not have any adverse impact on the budget & overall project time Schedule

c) Time Constraints:
Creation of automation test scripts is nothing but an activity being a part of software development. Adequate consideration needs to be given as to whether we have sufficient time for writing, debugging & maintaining the test scripts, otherwise we can land up in wasteful consumption of time & money.

d) Allocation & Management of Resources:
Testing efforts & their consequent results like test scripts once developed for a particular project must be reusable for future projects as well. Such scripts become valuable assets for the organization for use in future. Proper identification of such assets together with allocation of responsibility (among an individual or to a group) for their maintenance & archiving is very important, otherwise all efforts shall be become a sheer waste.

Based upon the individual experience & vision of the testers many such considerations evolve from project to project.

Key Word: Automation, Testing, QTP, Automated Testing


Read more...