Quick Test Professional

Slide 1: Quick Test Professional 9.2

Slide 2: Testing Process  Preparing to Record  Recording  Enhancing a Test  Debugging  Running the Test and Analyzing the Results  Reporting Defects

Slide 3: Add-in Manager  Default Add-ins – ActiveX – Visual basic – Web  Other Add-Ins – Siebel – Java – SAP – Oracle – .Net and many more

Slide 4: Quick Test Professional - Record & Run Modes  Recording Modes – Normal – Analog – Low level  Run Modes – Normal – Fast

Slide 5: QTP Window

Slide 6: Create a Test Objectives  Create a basic test from a manual test case.  Run a test and check for errors.

Slide 7: The Object Repository • Object repository dialog box displays a test tree of all objects in the current action or the entire application. •Using Object repository we can a) Identify the Object b) View the Object Properties

Slide 8: Object Spy  Using the Object Spy, we can view the properties of any Object in the open application.  We can also view Object Methods.

Slide 9: How Quick Test Recognizes Objects  For each object class, QTP has a default set of properties that it always learns. 1.Mandatory Properties. 2.Assistive properties. 3.Ordinal Identifier.  Usually, only a few properties are needed to uniquely identify an object.

Slide 10: Synchronization  Synchronization point enables the anticipated time problems between the application and QTP.  A progress bar reaches 100% completion.  A status message appears.  A button becomes enabled.  A window opens and is ready for data entry.  A pop-up message appears in response to an operation.

Slide 11: How to synchronize the Test  We can synchronize the test by 1.Inserting a synchronization point Insert  Step  Synchronization point Window(“Flights”).WinButton(“Update order”).WaitProperty”enabled”,1,1000 2.Adding Exist and Wait statements status=Window(“Flights”).Dialog(“Flights Table”).Exist Wait(10)

Slide 12: Checkpoints  A checkpoint is a verification point that compares a current value for a specified property with the expected value for that property.  We can Insert checkpoint 1.From Menu Insert  Checkpoint  Standard Checkpoint 2.From Keyword view 3.From the Active Screen

Slide 13: Checkpoint Types 1.Standard Checkpoint 2.Image Checkpoint 3.Table Checkpoint 4.Page Checkpoint 5.Text Checkpoint 6.Text Area Checkpoint 7.Bitmap Checkpoint 8.Database Checkpoint

Slide 14: Insert A Checkpoint From The Active Screen  A checkpoint can be added after a test is created.  Use the Active Screen to select the field on which the checkpoint will be added.  Right-click on the appropriate field and choose “Insert Standard Checkpoint”.

Slide 15: Regular Expressions  Regular expressions enable Quick Test to Identify Objects and text strings with varying values.

Slide 16: Use a Regular Expression  A regular expression is a string that specifies a complex search phrase. By using  special characters you define the conditions of the search.  Note: There are 4 steps to ensure that a regular expression is inserted correctly.  From the Checkpoint Properties window, ensure Constant is enabled and click on the note paper icon.  Check Regular Expression checkbox.  If QTP sees there are characters that can be misconstrued as a regular expression, it will ask you to treat it as a literal character. Generally, you will answer No.  Add the regular expression. For example, Figure 6-6 will use [A-Z a-z]+.

Slide 17: Parameters  Objectives  Describe and use multiple parameter types.  Drive data in multiple iterations.  Analyze errors during iterations.  Parameterize a checkpoint.

Slide 18: Input Parameters For Data driven Tests  Input Parameters For Data Driven Tests  A data-driven test is one that runs a set of user actions with multiple input values. Data driving allows one script to test application functionality with many sets of data.  Automated data driven testing frees you to perform more tests, thus increasing test coverage. Speed, repeatability, free resources to do other kinds of quality control.

Slide 19: Input Parameter  Input Parameters allow you to replace a static, recorded value in a step with a dynamic placeholder (parameter), which represents an expandable range of values.  Input parameter names and their values are located in QuickTest’s Data Table.  Input parameter values are input into the application from some outside data source.

Slide 20: Steps to Create An Input Parameter  To create an input data table parameter:  Select the step in the Keyword View that contains the recorded input value.  From the Value column, click on the current value.  Click on the parameterize button.  The Constant value appears in the Value Configuration Options dialog box.

Slide 21: Set the Parameter Value  In the VALUE CONFIGURATION OPTIONS dialog, select the Parameter radio button and ensure that Data Table is selected from the drop-down list.  From the Name drop down list, enter a unique column name to create a new column in your data table or choose an existing column name from the data table.  Use the default Global data sheet to store values.  Enter the values that QTP will input after the test executes.

Slide 22: Supply Data to the Parameter  The design-time table is the central location for storing input parameter values.  The number of rows in the data table will cause the same number of test execution iterations to be run.  As a default, the design-time data table is displayed at the bottom of the QuickTest screen.  If you want to show or hide the data sheet, click on the icon in the toolbar.

Slide 23: Verify The Test Run  View the Test Results window to verify that each of the rows from the Design Time Data Table was used during the test run.  Expand the tree for each iteration (Row#) to view specific information about the execution of the specific row.

Slide 24: Parameterize a Checkpoint  You can use parameterized expected values to make your checkpoints dynamic. They Can be set on:  An object property in the Object Repository.  A checkpoint on a parameterized field.

Slide 25: A Test with Multiple Actions  Actions can be divided into logical sections, like the main sections of a transaction, or by specific business processes.  When you create a new test, it contains one action. By dividing your tests into multiple actions, you can design more modular and efficient tests.

Slide 26: Types of Actions  There are two kinds of actions: Regular (Non-reusable) Reusable  Tests that contain reusable actions can be used: Locally Externally

Slide 27: Insert Call to a New Action  You can add a new action during or after recording.  Select Insert ? New Action from the QuickTest main menu. The Insert New Action window appears.  Or use the “lego” icon on the toolbar to insert new action.

Slide 28: Using Parameterized Data  Test data can be passed from one test to another test using the value of an input parameter.  This creates a data flow between business processes.  The value passed from one business process to another will come from the Data Table.  Be aware of any data dependencies that occur within the business process.

Slide 29: Copied, Existing or New Action  After reusable actions are created, they can be called into a “Main Calling” test in three ways:  Call to New Action  Call to Copy of Action  Call to Existing Action

Slide 30: Set Actions as Reusable  Create a reusable action from the Action properties dialog.  Check the checkbox and click OK. A message will appear stating a description of a reusable  action.

Slide 31: Call An Action  You can do number of things with a reusable action, such as:  Call it multiple times within a test.  Call it from other tests.  View the components of the action tree (you cannot modify them except in the original script)  Insert a call to an external action (the action is inserted in read-only format)  as local editable copy  use the (read only) data from the original  action  Insert copies of non-reusable actions into your test, but you cannot insert calls to non-reusable actions.

Slide 32: Recovery Scenarios  To instruct Quick test to recover from unexpected events and errors that occur in the testing environment during the run session.  A Recovery scenario consists of a) Trigger Event b) Recovery Operation c) Post Recovery Run Option

Slide 33: Recovery Scenario Wizard  We can create the recovery scenario using recovery scenario wizard.  Recovery scenario wizard consists of a) Define the trigger event that interrupts the run session b) Specifying the recovery operations required to continue c) Choosing a post recovery test run operation d) Specifying a name and description for the recovery scenario e) Specifying whether to associate the recovery scenario to the current test and / or to all new tests.

Slide 34: Recovery Scenario Wizard

Slide 35: Creating Tests without Object Repository  We can use programmatic descriptions to perform an operation on an object that is not stored in the Object Repository.  Types of Programmatic descriptions a) We can list the set of properties and values that describe the object directly in a test statement. e.g: Dialog(“name:=Login”).WinEdit(“attachedtext:=agentname”).Set”impetus” b) We can add a collection of properties and values to a description object and then enter the description object in the statement. Set myobject=Description.Create() myobject(“attachedtext”).value:=“agentname” myobject(“html tag”).value:=“a” Dialog(“name:=Login”).WinEdit (myobject).Set”impetus”

Slide 36: Enhance TestCases With Descriptive Programming  Interact with Test Objects not stored in the Object Repository – You can also instruct QT to perform methods on objects without referring to the object repository without referring to the object’s logical name. To do this you provide QT with a list of properties and values that QT can use to identify the object or objects on which you want to perform a method

Slide 37: Enter Programmatic Descriptions Directly into Test Statements  You can describe an object directly in a test statement by specifying property : = value pairs describing the object instead of specifying an object’s logical name.  Syntax:-  TestObject(“PropertyName1:=PropertyValue”, “…”, “PropertyNameX:=PropertyValueX”)  Where “Test Object” is test object class

Slide 38: Contd….  PropertyName is PropertyValue  i.e. the test object property and its value . Each property:= value pair should be separated by commas and quotation marks.  For Example: Window(“Text:=Myfile.txt-Notepad”).Move 50,50  If you want to use the same programmatic description several times in one test, you may want to assign the object you create to a variable.  For Ex:- Set MyWin := Window(“Text:=Myfile.txt-Notepad”)  MyWin.Move 50,50

Slide 39: Contd….  Once we have filled the Properties collection with a set of Property objects (properties and values), you Can specify the Properties object in place of a logical name in a test statement. For Ex:- (Instead of Entering) Window(“Error”).WInbutton(“text:=OK”, “width:=50”).click IF Entered… Set MyDescription= Description.Create() MyDescription(“text”).Value=“OK” MyDescription(“width”).Value=50 Window(“Error”).WinButton(MyDescription).Click