How to Launch an Application in QTP

There are four ways to launch an application. They are as follows -

1) SystemUtil.Run – SystemUtil.Run ( FileName, Parameters, Path, Operation )

FileName – The name of the file you want to run.

Parameters – If the specified FileName is an executable file, use the Parameters argument to
specify any parameters to be passed to the application.

Path – The default directory of the application or file.

Operation – The action to be performed. If this argument is blank (”"), the open operation is
performed.

Example –

systemUtil.Run “D:\My Music\Breathe.mp3″,”",”D:\My Music\Details”,”open”

2) InvokeApplication – This command is now mainly used for the backward compatability ie to use
with the lower versions(below QTP 6.0) of QTP.

Syntax -
InvokeApplication(”Full URL as Parameter”)

Example -

InvokeApplication “C:\Program Files\Internet Explorer\IEXPLORE.EXE http://www.yahoo.com”

3) VBscript to invoke application

Dim oShellSet oShell = CreateObject (”Wscript.shell”)
oShell.run “F:\jdk1.3.1\demo\jfc\SwingSet2.bat”‘
oShell.run “java -jar F:\jdk1.3.1\demo\jfc\SwingSet2\SwingSet2.jar”‘
oShell.Run Chr(34) & “C:\Program Files\Internet Explorer\IEXPLORE.EXE” & Chr(34)Set oShell = Nothing

4) Trivial but useful method

You can use the Start -> Run dialog of Windows.
1. Add the Windows Start button to the Object Repository using the “Add Objects” button in
Object Repository dialog.
2. Open the Run dialog (Start -> Run), and learn the “Open” edit field and the “OK” button into the
Object Repository.
3. Switch to the Expert View, and manually add the lines to open the Run dialog.

Example:Window(”Window”).WinButton(”Button”).ClickWindow(”Window”).Type(”R”)

4. Manually enter the lines to enter the information to launch the application, and click the “OK” button of the Run dialog.

Example:
Dialog(”Run”).WinEdit(”Open:”).Type “c:\WINNT\system32\notepad.exe”
Dialog(”Run”).WinButton(”OK”).Click

A JavaScript Program That Generate Factorials..

document.write(”Table of Factorials”);
for(i = 1, fact = 1; i < 10; i++, fact *= i) {
document.write(i + "! = " + fact);
document.write("”);
}

Bug Life Cycle & Guidelines

This tutorial describes about Bug Life Cycle & Guidelines, Introduction, Bug Life Cycle, The different states of a bug, Description of Various Stages, Guidelines on deciding the Severity of Bug, A sample guideline for assignment of Priority Levels during the product test phase and Guidelines on writing Bug Description.

Introduction: Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software. A bug is a specific concern about the quality of the Application under Test (AUT).

Bug Life Cycle: In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. The life cycle of the bug can be shown diagrammatically as follows:

The different states of a bug can be summarized as follows:
1. New
2. Open
3. Assign
4. Test
5. Verified
6. Deferred
7. Reopened
8. Duplicate
9. Rejected and
10. Closed

Description of Various Stages:
1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the
bug is not yet approved.

2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine
and he changes the state as “OPEN”.

3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding
developer or developer team. The state of the bug now is changed to “ASSIGN”.

4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next
round of testing. Before he releases the software with bug fixed, he changes the state of bug
to “TEST”. It specifies that the bug has been fixed and is released to testing team.

5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next
releases. The reasons for changing the bug to this state have many factors. Some of them are
priority of the bug may be low, lack of time for the release or the bug may not have major
effect on the software.

6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state
of the bug is changed to “REJECTED”.
7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug,
then one bug status is changed to “DUPLICATE”.

8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If
the bug is not present in the software, he approves that the bug is fixed and changes the
status to “VERIFIED”.

9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester
changes the status to “REOPENED”. The bug traverses the life cycle once again.

10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no
longer exists in the software, he changes the status of the bug to “CLOSED”. This state
means that the bug is fixed, tested and approved.

While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal. Discovering and removing defects is an expensive and inefficient process. It is much more efficient for an organization to conduct activities that prevent defects.

Guidelines on deciding the Severity of Bug: Indicate the impact each defect has on testing efforts or users and administrators of the application under test. This information is used by developers and management as the basis for assigning priority of work on defects.

A sample guideline for assignment of Priority Levels during the product test phase includes:

1. Critical / Show Stopper — An item that prevents further testing of the product or function under test can be classified as Critical Bug. No workaround is possible for such bugs. Examples of this include a missing menu option or security permission required to access a function under test.

2. Major / High — A defect that does not function as expected/designed or cause other functionality to fail to meet requirements can be classified as Major Bug. The workaround can be provided for such bugs. Examples of this include inaccurate calculations; the wrong field being updated, etc.

3.Average / Medium — The defects which do not conform to standards and conventions can be classified as Medium Bugs. Easy workarounds exists to achieve functionality objectives. Examples include matching visual and text links which lead to different end points.

4.Minor / Low — Cosmetic defects which does not affect the functionality of the system can be classified as Minor Bugs.

Guidelines on writing Bug Description:

Bug can be expressed as “Result followed by the action”. That means, the unexpected behavior occurring when a particular action takes place can be given as bug description.

1.Be specific. State the expected behavior which did not occur – such as after pop-up did not
appear and the behavior which occurred instead.

2. Use present tense.
3. Don’t use unnecessary words.
4. Don’t add exclamation points. End sentences with a period.
5. DON’T USE ALL CAPS. Format words in upper and lower case (mixed case).
6. Mention steps to reproduce the bug compulsorily.

Uninstalling and Reinstalling Procedures for LoadRunner

Notes:
• Uninstall and reinstall procedures should be done while logging in with full administrator
privileges.

• Extraneous background applications on the system should be closed. Most “normal”
programs will not interfere with the installation, but things like Virus Scanners and other
system level tools may interfere with the installation program without issuing any sort of
warning or error messages. The problems may only present themselves as erratic behavior
after the tool is installed.

• Any patches applied on top of the Default installation will need to be reapplied after the reinstall.

Uninstall Procedure:

1. Make sure that all running LoadRunner processes (including the Controller, VuGen, Analysis
and the Remote Command Launcher (for 6.x) or the LoadRunner Agent Process/Service (for
7.x & 8.x)) are closed.

2. Back up any existing scripts that may have been saved in the LoadRunner installation folder.
(The scripts are sometimes saved in a “scripts” subdirectory under the LoadRunner installation
folder.)

3. Run the uninstall program from the LoadRunner program group (or) use the Windows
Add/Remove Programs from the Control Panel. If any prompt is given about removing shared
files, remove all the shared DLLs that are reported as no longer being in use. In the very rare
instance this causes a problem for some other application it may be necessary to reinstall that
other application. This is not generally a problem because every application should have
registered which DLLs it needs to run.

4. Reboot the machine after the Uninstall wizard is complete. This will complete the basic
uninstall procedure.

5. Delete all LoadRunner folders (including the ones in the Startup menu for the Remote
Command Launcher (LoadRunner 6.x) or Agent Process (LoadRunner 7.x & 8.x)).

6. If the installation is LoadRunner 6.x, delete the Borland folder (usually under C:\Borland or
C:\BDE).

7. Do a search for the following files and remove them from all locations — they will be replaced
during the reinstall.
a. wlrun.*
b. vugen.*

8. Open the registry editor (Start  Run  regedit).

9. Delete the following keys:

a. For LoadRunner 6.x only:
HKEY_LOCAL_MACHINE\SOFTWARE\BORLAND
b. Go to
HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive
HKEY_CURRENT_USER\SOFTWARE\Mercury Interactive
Delete all the folders under Loadrunner or anything related to LoadRunner
except “License2” and/or “License” under LoadRunner..

10. Empty the Recycle Bin.

Installation Procedure:

1. After the uninstall procedure is completed as above, reinstall the product (or a different version of the product). You do not need to reboot at the end of the prior steps to run the installation program.

2. Insert the LoadRunner CD you received into the CD-ROM drive and follow the installation instructions on the screen.

3. Reboot the machine after the installation is completed (it is important to complete the installation.). Make sure that you have full administrator privileges on the machine while logging back in after the reboot. This is necessary as systems tries to write few registry entries.

Note:
If your old license key does not work, please refer to LoadRunner Knowledge Base Problem ID 11876 – Common License issues for LoadRunner 6.x and 7.x. You may need a new license key for your installation.

Guidelines for Working with Actions in QTP (QuickTest Professional)

Few guidelines to follow when working with actions in QTP:

1. If your action runs more than one iteration, the action must end at the same point in your application as it started, so that it can run another iteration without interruption. For example, suppose you are testing a sample flight reservation site. If the action starts with a blank flight reservation form, it should conclude with a blank flight reservation form.

2. A single test may include both global Data Table parameters and action (local) Data Table parameters. For example, you can create a test in which a travel agent logs into the flight reservation system, books three flights, and logs out; the next travel agent logs into the flight reservation system, books three flights, logs out, and so forth.

To parameterize the `book a flight’ action, you choose Current action sheet (local) in the parameterization dialog box and enter the three flights into the relevant Action tab in the Data Table. To parameterize the entire test, you choose Global in the parameterization dialog box and enter the login names and passwords for the different agents into the Global tab in the Data Table.

Your entire test will run one time for each row in the Global data sheet. Within each test, each parameterized action will be repeated depending on the number of rows in its data sheet and according to the run settings selected in the Run tab of the Action Properties dialog box.

3. You may want to rename the actions in your test with descriptive names to help you identify them. It is also a good idea to add detailed action descriptions. This facilitates inserting actions from one test to another. You can rename an action by choosing Edit > Action > Rename Action. (Make sure you follow the naming conventions for actions.)

4. If you plan to use an identical or virtually identical procedure in more than one test, you should consider inserting a call to an action from another test.

- If you want to make slight modifications to the action in only one test, you should use the Insert Call to Copy of Action option to create a copy of the action.
- If you want modifications to affect all tests containing the action, you should use the Insert Call to Existing Action option to insert a link to the action from the original test.
- If you want modifications to the action to affect all tests containing the action, but you want to edit data in a specific test’s Data Table, use the Insert Call to Existing Action option and, in the External tab of the Action Properties dialog box, select Use a local, editable copy.

5. When you insert a call to an external action, the action is inserted in read-only format, so the Record button is disabled. If you want to continue recording, you first need to insert a call to a local action into your test, or select a step from a local action that already exists in your test.

6. Reusable actions help you to maintain your tests, but it is important to consider the effects of making an action reusable. Once you make an action reusable, be sure to consider how changes to that action could potentially affect other tests that call that action.

7. If you expect other users to open your tests and all actions in your tests are stored in the same drive, you should use relative paths for your reusable actions so that other users will be able to open your tests even if they have mapped their network drives differently.

8. If you expect certain elements of your application to change regularly, it is a good idea to divide the steps related to changeable elements into a separate action so that it will be easy to change the required steps, if necessary, after the application is modified.

9. If you decide to remove an action, consider how that might affect your test or another test that contains a call to that action. For example, will it prevent a later action in the same test from running correctly? Will it cause the test containing a call to that action to fail?

(Source: HP QTP MAIN USER GUIDE)