1. Tests Creation

2. Using the following QuickTest components  Designing Tests  Keyword View  Test Objects  Active Screen  Checkpoints  Object Property Values  Tables, Text, Bitmaps, Databases  Configuring Values  Actions  Data Tables

3. Designing Tests  You can create a test by recording the operations you perform on your application or using the keyword- driven methodology. After you create your test, you can enhance it using checkpoints and other special testing options.  In some cases, you may want to let QuickTest generate test steps by recording the typical processes that you perform on your application. As you navigate through your application, QuickTest graphically displays each step you perform as a row in the Keyword View.  While creating your test, you can insert checkpoints into your test.  When you test your application or site, you may want to check how it performs the same operations with different data. This is called parameterizing your test.

4. Keyword View The Keyword View enables us to create and view the steps of our test in a modular, table format. Working in the Keyword View does not require any programming knowledge. The programming required to actually perform each test step is done automatically behind the scenes by QuickTest.  Keyword View  QuickTest Recorded Object Hierarchy

5. Keyword View  Actions are the highest level of the test hierarchy. They contain all the steps that are part of that action. In the Keyword View, you can view either the flow of all the action calls in the test, or the content of a specific reusable action, using the options in the Action toolbar.  The Action toolbar is available only if at least one of the actions in your test is reusable.  Each action is comprised of steps. During a recording session, each step is recorded as a row in the Keyword View. For example, the Keyword View could contain these rows.  For every step in the Keyword View, QuickTest displays a corresponding line of script in the Expert View. If you select a specific row in the Keyword View and switch to the Expert View, the cursor is located in the corresponding line of the script. These rows show the following three steps that are all performed on the Welcome: Mercury Tours page of the Mercury Tours sample web site: mercury is entered in the userName edit box. The encrypted string 3ee35 is entered in the password edit box. The Sign-In image is clicked. The Documentation column translates each of the steps into understandable sentences.

6. QTP Recorded Object Hierarchy  The recorded object hierarchy comprises one or more levels of test objects. The top level is the object that represents a window, dialog, or browser type object, depending on the environment. Depending on the actual object on which you performed an operation, that object may be recorded as a top level object or a second level object, for example, Window > WinToolbar or a third level object, for example, Browser > Page > WebButton.  Even though the object on which you record may be embedded in several levels of objects, the recorded hierarchy does not include these objects. For example, even if the WebButton object on which you record is actually contained in several nested WebTable objects, which are all contained within a Browser and Page, the recorded hierarchy is only Browser > Page > WebButton.  An object that can potentially contain a lower-level object is called a container object. All top-level objects in the recorded hierarchy are container objects. If a second-level object contains third-level objects according to the QuickTest recorded object hierarchy, then that object is also considered a container object. For example, in the step Browser > Page > Edit > Set "David", Browser and Page are both container objects. If the selected step is a container object, the new step is inserted as the first sub-step of the container object. If the selected step is at the lowest level of the recorded hierarchy, the new step is inserted as a sibling step immediately after the selected step.

7. Test Objects  Object Repository Types  Object Repository Window  Test Object Properties  Locating Objects

8. Object Repository Types QTP has to learn the interface of an application to be able to work with it. It does by learning the application's objects and their corresponding property values and storing these object descriptions in an object repository.  local object repository - stores objects in a file that is associated with one specific action, so that only that action can access the stored objects.  shared object repository - stores test objects in a file that can be accessed by multiple tests (in read-only mode).  Why we have to modify OR - If one or more of the property values of an object in your application differ from the property values QuickTest uses to identify the object, your test may fail. Therefore, when the property values of objects in your application change, you should modify the corresponding test object property values in the corresponding object repository so that you can continue to use your existing tests.  Object Repository window - To modify test objects stored in a local object repository.  Object Repository Manager - To modify test objects in a shared object repository. Note:-  If an object with the same name is located in both the local object repository and in a shared object repository associated with the same action, the action uses the local object definition.  If an object with the same name is located in more than one shared object repository associated with the same action, the object definition is used from the first occurrence of the object, according to the order in which the shared object repositories are associated with the action.

9. Selection between Local or Shared Object Repositories To choose where to save objects, we need to understand the differences between local and shared object repositories.  In general, the local object repository is easiest to use when you are creating simple record and run tests, especially under the following conditions:  You have only one, or very few, tests that correspond to a given application, interface, or set of objects.  You do not expect to frequently modify test object properties.  You generally create single-action tests.  Conversely, the shared object repository is generally the preferred option when:  You are creating tests using keyword-driven methodologies (not using record).  You have several tests that test elements of the same application, interface, or set of objects.  You expect the object properties in your application to change from time to time and/or you regularly need to update or modify test object properties.  You often work with multi-action tests and regularly use the Insert Copy of Action and Insert Call to Action options.

10. Object Repository Window  Open the Object Repository window for a specific action or component by choosing Resources > Object Repository or clicking the Object Repository button.  The Object Repository window displays a tree of all objects in the current component or in the selected action (including all local objects and all objects in any shared object repositories associated with the selected action or component).  Local objects are editable (black); shared objects are in read- only format (gray).

11. Active Screen  The Active Screen provides a snapshot of your application in a recording session and enables you to insert additional steps on the test objects captured in that screen after the recording session. To view the Active Screen pane, click the Active Screen button or choose View > Active Screen.  We can decide if and how much information you want to capture and save in the Active Screen. The more information you capture, the easier it is to add steps to your test using the many Active Screen options.

12. Checkpoints  A checkpoint is a verification point that compares a current value for a specified property with the expected value for that property. This enables you to identify whether your Web site or application is functioning correctly.  When we add a checkpoint, QuickTest adds a checkpoint to the current row in the Keyword View and adds a Check CheckPoint statement in the Expert View. By default, the checkpoint name receives the name of the test object on which the checkpoint is being performed.

13. Types of Checkpoints  Standard Checkpoint checks the property value of an object in your application or Web page. The standard checkpoint checks a variety of objects such as buttons, radio buttons, combo boxes, lists, and so forth.  Image Checkpoint checks the value of an image in your application or Web page. For example, you can check that a selected image's source file is correct.  Bitmap Checkpoint checks an area of your Web page or application as a bitmap. For example, suppose you have a Web site that can display a map of a city the user specifies.  Table Checkpoint checks information within a table. For example, suppose your application or Web site contains a table listing all available flights from New York to San Francisco. You can add a table checkpoint to check that the time of the first flight in the table is correct.

14. Continued…  Text Checkpoint checks that a text string is displayed in the appropriate place on a Web page or application.  Text Area Checkpoint checks that a text string is displayed within a defined area in a Windows application, according to specified criteria.  Accessibility Checkpoint identifies areas of your Web site that may not conform to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines. For example, guideline 1.1 of the W3C Web Content Accessibility Guidelines requires you to provide a text equivalent for every non-text element.  Page Checkpoint checks the characteristics of a Web page. For example, you can check how long a Web page takes to load or whether a Web page contains broken links.  Database Checkpoint checks the contents of a database accessed by your application.  XML Checkpoint checks the data content of XML documents in XML files or XML documents in Web pages and frames.

15. Supported Checkpoints The table shows the types of checkpoints supported for each add-in environment that is supported by default with the QuickTest Professional

16. Image Checkpoint Properties Dialog Box

17. Modifying Checkpoints  You can modify the settings of existing checkpoints. For example, you can choose to use parameters, or you can use filters to specify which image sources and links to check. To modify a checkpoint:  In the Keyword View or Expert View, right-click the checkpoint that you want to modify and select Checkpoint Properties. Alternatively, select the step containing the checkpoint and choose Edit > Step Properties > Checkpoint Properties. The relevant checkpoint dialog box opens.  Modify the properties and click OK.

18. Planning and Preparing to Create a Test Before you start creating your test, you should plan it and prepare the required infrastructure.  Determine the functionality you want to test.  Decide which information you want to check during the test.  Consider changing the way that QuickTest identifies specific objects.  Decide how you want to organize your object repositories.  Find out whether an object repository containing the objects you are testing already exists.  Determine whether you need to create any new user-defined functions or whether you should associate any existing function libraries with your test.  If you are recording steps, evaluate the types of events you need to record.  Consider increasing the power and flexibility of your test by replacing fixed values with parameters.  Consider using actions to streamline the testing process.

19. Configuring Values QuickTest enables you to configure the values for properties and other items by defining a value as a constant or a parameter.  Constant. A value that is defined directly in the step and remains unchanged for the duration of the test.  Parameter. A value that is defined or generated separately from the step and is retrieved when the specific step runs. For example, a parameter value may be defined in an external file or generated by QuickTest.

20. Setting Values in the Configure Value Area  select an item in a dialog box containing a Configure value area, such as the Checkpoint Properties dialog box, you can select Constant or Parameter to set the value. The default is Constant.  select Parameter for a value that is already parameterized, the Parameter box displays the current parameter definition for the value.

21. Actions  You can divide your test into actions to streamline the process of testing your application or Web site.  A test comprises calls to actions. When you create a new test, it contains a call to a single action.  An action consists of its own test script, including all of the steps recorded in that action, and any objects in its local object repository.  Each action is stored together with the test in which you created it. You can insert a call to an action that is stored with the test and, depending on the properties of the action, you may also be able to call an action stored with another test.

22. Using Multiple Actions in a Test  When you create a test, it includes one action. All the steps you record and all the modifications you make while editing your test are part of a single action.  You can divide your test into multiple actions by creating new actions and inserting calls to them, or by inserting calls to existing actions. There are three kinds of actions:  non-reusable action. an action that can be called only in the test with which it is stored.  reusable action. an action that can be called multiple times by the test with which it is stored (the local test), as well as by other tests.  external action. a reusable action stored with another test. External actions are read-only in the calling test, but you can choose to use a local, editable copy of the Data Table information for the external action.

23. Creating New Actions We can create new actions and add calls to them during a recording session or while designing or editing your test. To create a new action in your test:  If you want to insert a call to the new action from an existing action in your test, click the step after which you want to insert the new action. To insert a call to the new action from the test flow as a top- level action, click any step.  Choose Insert > Call to New Action or click the Insert Call to New Action button. The Insert Call to New Action dialog box opens.

24. Nesting Actions To call an action from within an action. This is called nesting. By nesting actions, you can:  Maintain the modularity of your test.  Run one or more actions based on the results of a conditional statement.

25. Continued… In the Expert View, the test might look something like this: Browser("Membership Preference").Page("Membership Preference").WebRadioGroup("MemType").Select DataTable("memtype", dtGlobalSheet) Mem_Type=Browser("Membership Preference").Page("Membership Preference").WebRadioGroup("MemType").GetROProperty ("value") If Mem_Type="paid" Then RunAction "Paid_Mem", oneIteration ElseIf Mem_Type = "free" Then RunAction "Free_Mem", oneIteration Else RunAction "Preferred", oneIteration End If

26. Data Tables  QuickTest enables you to insert and run steps that are driven by data stored in the Data Table.  The Data Table has the characteristics of a Microsoft Excel spreadsheet, meaning that you can store and use data in its cells and you can also perform mathematical formulas within the cells.  During the run session, QuickTest creates a run- time Data Table—a live version of the Data Table associated with your test.  During the run session, QuickTest displays the run-time data in the Data Table pane so that you can see any changes to the Data Table as they occur.

27. Thank You!