Quick Test Professional 9.2

1. Quick Test Professional 9.2

2. Testing Process • Preparing to Record • Recording • Enhancing a Test • Debugging • Running the Test and Analyzing the Results • Reporting Defects

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

4. Quick Test Professional - Record & Run Modes • Recording Modes • Normal • Analog • Low level • Run Modes • Normal • Fast

5. QTP Window

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

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

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.

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.

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.

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)

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

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

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

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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

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.

34. Recovery Scenario Wizard

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”

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

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

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

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