Turnkey Solutions

Quality Center 8.2 Functional Reference Manual Oracle 11.5.10

Prepared for: Date:

November, 2006

TurnKey Solutions Corp. [email protected] 621 17th Street, Suite 1131 Denver, CO 80293

TurnKey Solutions Corporation

Confidential Do Not Distribute Copyright © TurnKey Solutions 2006

Page 1 of 74

Classification: Polaris Internal

Functional Reference Manual

Table of Contents Glossary of Terms.............................................................................................................................................3 Quality Center Functionality............................................................................................................................4 3 Levels of Granularity.....................................................................................................................................5 Test Plan (Case)................................................................................................................................................5 Components for Test Cases.......................................................................................................................10 Adding Components to a Test Case

11

Review Common Components...................................................................................................................14 Review Common Test Cases......................................................................................................................16

Business Components.....................................................................................................................................17 Components................................................................................................................................................17 Go to the Component Requests Window Select the Component Tree Folder and the Component Move the Component to the Component Tree

22 22 23

Test Sets..........................................................................................................................................................24 Debugging Tests.........................................................................................................................................30

Data Sources (4 levels of Data)......................................................................................................................33 TurnKey Data Management Solution.............................................................................................................40 DataLoad Component.................................................................................................................................40 DataLoadManager.xls.................................................................................................................................41 WorkSheet Structure: Input/Output Data: Linking Data Between WorkSheets

41 42 42

LoadData Function......................................................................................................................................43 Auto-Spreadsheet Creation.........................................................................................................................43

Iterations.........................................................................................................................................................46 Method 1A – Iterating Component(s) within a Test Case Method 1B – Iterating a Group of Components within a Test Case Method 2 – Iterating a Test Case with Different Data Scenarios

47 49 51

Complex Flow Control Using Group Iterations.............................................................................................53 SME Automation............................................................................................................................................54 Object Repository........................................................................................................................................54 Building Application Areas..........................................................................................................................57 Steps on Creating an Application Area:......................................................................................................57 Working with Oracle Forms.........................................................................................................................61 Working with Parameters............................................................................................................................63 Working with Oracle Tables........................................................................................................................64

Updating the Oracle Accelerator....................................................................................................................69 Appendix:.......................................................................................................................................................74 Templates........................................................................................................................................................74 Test Case....................................................................................................................................................74 Components................................................................................................................................................74

TurnKey Solutions Corporation Page 2 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Glossary of Terms Business Process Testing (BPT) A Mercury paradigm where components are created and assembled into test cases using QC. QC is required for any implementation of BPT. Business Component Commonly known as Component, a Component is a basic building block for assembling a test case in QC. It can either be scripted or non-scripted. It can either be created in version 8.0 or greater of BPT. Note The definition of a Business Component changed from version 8.0 to 8.2: • v 8.0, a Business Component is always a scripted. • v 8.2, a Business Component can be either scripted or non-scripted. Non-Scripted Component A Business Component that can be edited in QC or QTP. Complex conditional execution can only be added through the use of functions and methods. The Keyword view is the only view available in QTP and QC. A user may select an object, operation and enter any required arguments. Scripted Component A Business Component that was developed using the Expert View in QTP. This component cannot be edited in QC. However, parameters can be changed in QC. Test Plan (Case) Commonly known as a Test Case, a Test Case groups one or more Components in a logical flow. A Test Case typically covers a piece of functionality. Test Lab (Set) Commonly known as a Test Set, a Test Set groups one or more Test Cases to test an end to end flow. A Test Set can cover more than one module. QuickTest Pro (QTP) Mercury’s premier Test Automation Tool and where you’ll do most of your traditional scripting as well as Keyword work. Quality Center (QC) Mercury’s Testing Support Tool and where your tests will be stored and run from during Test Runs. Also comes complete with Requirements and Bug tracking features. Components can be automated with Keywords through Quality Center as well as Quick Test Pro. Subject Matter Expert (SME) Functional experts write the manual test steps. They can also automate, run and maintain test scripts without having to be a programmer.

TurnKey Solutions Corporation Page 3 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Quality Center Functionality

•

Requirements – Not used with Accelerators

TurnKey Solutions Corporation Page 4 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual •

Defects – Not Used with Accelerators.

3 Levels of Granularity •

Business Component (Component) Lowest Level is Business Component (Component). This is where the automation occurs. A component is by definition, “The smallest piece of nondivisable work”. A component may be a form or window. It could be the tabbed region of a form. Depends on a number of factors such as potential reusability, possible iterations etc. See the Component Scoping Rules v1-3 document for more detail on Component scoping rules.

•

Test Plan (Case) A Test Plan (Case) is by Definition is a piece of functionality. It is comprised of 1 or more components, placed in the desired order of execution. This will be referred to as a ‘Test Case’.

•

Test Lab (Set) A Test Lab (Set) is by Definition is more of an end to end flow. It is comprised of 1 or more Test Labs (Sets), placed in the desired order of execution. This will be referred to as ‘Test Set’. Test Sets can use Test Cases that cross modules, invoking an end to end process test.

Test Plan (Case) Test Case Test Case – High level description of what the test is supposed to accomplish. TurnKey Solutions Corporation Page 5 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual In defining a new automation script, it is best to start with the Test Case. This allows you to choose available components for your library and easily determine when a new component needs to be created. 1. Begin by identifying the Test Cases that you want to build. The development process goes smoother by starting at the Test Case level. You can pick components to use in your Test Case from the Component library. If a required component does not currently exist, a new component can be created and added to the Test Case. 2. In the Quality Center (QC), click on the ‘Test Plan’ icon on the left.

3. Go to the appropriate folder. Then drill down to the folder representing the application for which you are creating your new test case. You will notice that the folder structure is organized by Functional Family, such as Financials, Procurement, Manufacturing, etc. Beneath each family, you will see a folder for each Oracle Application. The folders you see will depend on the Accelerators purchased and any additional folders created by your team.

TurnKey Solutions Corporation Page 6 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

4. Click on the ‘New Test’ Icon (second icon from the left, next to New Folder icon)

TurnKey Solutions Corporation Page 7 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 5. The ‘Create New Test’ window appears. Select ‘BUSINESS-PROCESS’ as the ‘Test Type’.

6. Test Case Naming Convention Preface the Test Case name with the 2-3 letter application abbreviation for the application that the Test Case covers. I.e. GL – Enter Manual Journal Entry. GL representing General Ledger. The subsequent name should reflect English terms the process being tested. The name should convey to the reader what overall test plan is being performed. 7. Detail Standards and Template Use the following template in the ‘Details’ tab of the Test Case: (There is a blank template at the end of this manual.) The Test Case description is summary only. Detailed steps will be documented in each Component. Description: Enter a description for Test Case. Be as descriptive as possible, the description should encompass all components of the test. (Ex. Create a new requisition using a defined item, establish line distributions, approve the requisition and query the requisition to verify the approval and requisition details.) Pre-Conditions: Enter any conditions that must exist prior to starting the test. (Ex. Must be logged in to Oracle Applications in the 'Purchasing' responsibility.) Post-Conditions: Enter any conditions that should occur after the test is completed. Data In: ‘Test Case Name’: ‘Variable Name’ or N/A if there no data being pulled in from another Test Case. List each on a separate line Data Out: List each ‘Component Name’; ‘Variable Name’ for each component in the Test case that captures a value for use later. Other wise put N/A TurnKey Solutions Corporation Page 8 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Start Point: Enter starting point for entire test (ex. 'Navigator' window.) Stop Point: Enter stopping point for entire test (ex. 'Navigator' window.) Typically, the starting and ending points are always the Navigator window. This makes it easy to put any Test Case in any order. Test Case Example

8. The ‘Design Steps’ Tab is not used in conjunction with the Accelerators. It is usually grayed out. 9. Click on the ‘Test Script’ tab. 10. Click the ‘Select Comp’ icon. This will open the component library window on the right side. If the ‘Select Comp’ button is grayed out, then the component library window is already open.

TurnKey Solutions Corporation Page 9 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

11. You can choose any combination of components from the list. You can reuse any component any number of times. You can also use different sets of data with the same component in different test cases. When creating a new Test Case with the Accelerator, you must place the following components in this order: ResetDataLoadINI DataLoad Navigator Forms (or HTML depending on the Application) Working Components Return to Navigator Forms (or HTML depending on the Application)

Components for Test Cases DataLoad Always the first Component. Enter the location and name of the datasheet. I.e. C:\DataLoadManager.xls. Each Test Case will have a separate tab. The name must match exactly. Navigation The third Component in Oracle Forms based test cases. Enter the navigational path. For Oracle Forms applications, separate each step by a colon. i.e Enter:Journals Working Components Component(s) that perform the desired functionality. Return to Navigator Forms Return to Navigator component at the end of the test.

TurnKey Solutions Corporation Page 10 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Adding Components to a Test Case 1. Click on the Test Plan icon, then identify the Test Case you want to build in the Test Case directory tree.

2. Click on the Test Script tab. This is where components are added to the Test Case. The ResetDataloadINI component will always be the first in any Test Case, followed by the DataLoader and the Navigator components.

TurnKey Solutions Corporation Page 11 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

3. Next add the Navigation component that takes the script to the first form. Then add additional components in the required order of execution. The up and down arrows can be used to move the highlighted component up or down the list. The final component will be the one that takes the script from the final form back to the Navigation screen.

4. The Data Table spreadsheet (Called from the Dataload component) contains the variable data for each component. The values here must be updated to match your system. You can pull the Data Table spreadsheet from “BPT Resources/ DataLoadManagers” under the Attachments tab.

TurnKey Solutions Corporation Page 12 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

5. Use the up and down arrows to reorder the components. The components must be in a logical order as the Accelerator scripts will follow this order when running against your Oracle environment. If the scripts are out of order, the scripts will be looking to conduct a transaction in the wrong place.

6. The ‘X’ will remove a component from the Test Case, but not from Quality Center. 7. The Diskette icon will save your work. TurnKey Solutions Corporation Page 13 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 8. The Green Circular Arrows will refresh the view on your screen. 9. The remaining icons are for advanced users for debugging Test Cases. 10. Click on the ‘Attachments’ tab.

The Attachments section can be used to upload and store documents of any type. Click on the Paper Clip icon and browse to the file. URL’s, snapshots can also be added. 11. The Reqs Coverage Tab is used when defining Requirements in Quality Center. This functionality is not part of the Accelerators.

Review Common Components There are a number of components that can be used with almost every Test Case, regardless of the module. These include: DataLoad Parameters DataFile – The location and filename of the excel dtasheet. i.e. C:\DataLoadManager.xls DataSheet – The name of the tab in the Excel workbook file that contains the data for this Test Case. i.e. GLCreateManualJournalEntries Navigator Forms Parameters Path - Enter path selections separated by a colon. i.e. Journals:Enter Common Button Parameters TurnKey Solutions Corporation Page 14 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Form_Title – The title of the form that the button is on. i.e. ‘Find Journals’. Button_Label – The name of the button. i.e. ‘New Journal’. Tab_Region_Label – The name of the tab if the button is under a tab shown on the form. Select Menu Item Parameters Menu_Nav_Path – Any menu path can be used from the main menu tool bar. The default for this component is ‘File->Save’ to save a record. Save Verification Parameters ErrorCode – The code listed in the lower left corner of the forms. Verifies if the expected code is received. i.e. ‘FRM-40400’. Close Window Parameters Form_Title – The name of the form you want to have closed. For use when you want to close 1 window only, and not return to the navigator. Return to Navigator Forms Parameters EventStatus – micFail. DO NOT CHANGE THIS VALUE. This component will close all the forms, returning the script to the Navigator window.

These components cover common functionality that is reused in multiple Test Cases.

TurnKey Solutions Corporation Page 15 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Review Common Test Cases There are several common Test Cases that can be reused by just changing the data. The data for these Test Cases comes from the Test Case and not the Datasheet. Data can be mapped to a datasheet if desired. STD Report Template Key Component Submit Request – Enter the report or Concurrent Process Name. Parameter values are to be entered in order in the Parameter fields. Change Organization Key Component Change Organizations – Some Oracle Applications, namely manufacturing applications, will ask for the Organization the first time a user goes into that application. To standardize testing, the Accelerators include the Change Organization Test Case. This will be used EVERY time an applicable Manufacturing application is used. This eliminates the need for programming logic to determine if the applications will automatically bring the Change Organization window up or not.

TurnKey Solutions Corporation Page 16 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Business Components Components Components – Detail level of how to accomplish plan. Components should consist of a logical set of steps that should not be broken up. They should be small enough to be re-usable yet large enough to encompass logical blocks of functionality. Given a choice, choose usability and more components versus fewer components and less usability. If a form has multiple tabs, each tab should be a separate component. 1. Begin by identifying the Components for the associated Test Case. 2. In Quality Center Click on the ‘Business Components’ icon on the left.

3. Go to the appropriate folder (currently the Oracle Applications 11.5.10 folder) Then drill down to the folder representing the application for which you are creating your new test case. You will notice that the folder structure is organized by Functional Family, such as Financials, Procurement, Manufacturing, etc. Beneath each family, you will see a folder for each Oracle Application. The folders you see will depend on the Accelerators purchased and any additional folders created by your team. 4. Click on the New Components Icon (green puzzle piece icon)

TurnKey Solutions Corporation Page 17 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

5. Component Naming Convention a. The name should convey to the reader what test is being performed by the component. b. Use the ‘Navigator’ component for navigating from the Navigation window to the desired form. See the Navigator section for more details about this component. c. Use ‘Return to Navigator’ for navigating to the Navigation window from the desired form. 6. Every Test Case will begin at the navigator window. The second component in any test script will be the Navigator component step to the first form to be used in the Test Case. (The Dataload component will always be the first component in any Test Case) 7. Use the following template in the ‘Details’ window of the Component: (There is a blank template at the end of this manual.) Description: Enter a description for the test component. (Ex. Use the 'Navigator' window to access the 'Requisitions' window). Pre-Conditions: Enter any conditions or tests that must exist prior to this component step being run. (Ex. Must be at the 'Navigator' window for the Purchasing Responsibility). Otherwise put ‘N/A’. Post-Conditions: Enter any conditions that will result in completing this component step. Otherwise put ‘N/A’. Start Point: Enter the starting point for this step. (Ex. 'Navigator' window, 'Purchasing' responsibility). Stop Point: Enter the stopping point for this step (Ex. 'Requisitions' window) or 'Journals’ window. Steps: Enter the detailed steps required to accomplish this component. TurnKey Solutions Corporation Page 18 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Component Example

8. The ‘Details’ window of the Component is critical to the success of the automation of the Business Process. The description must describe in detail how the process works. Documentation Standards and Data Input Parameters to describe exactly how to automate the business process. a. Assume that the reader of your description does not know anything about Oracle, or the functionality you are describing. Describe how to perform each step in detail. Example 1) Verify that the 'Journals' window is open. 2) Enter "Line" in the 'Line' field. 3) Enter "Account" in the 'Account' field. 4) Enter "Debit" in the 'Debit' field. 5) Enter "Credit" in the 'Credit' field. b. It is important that the descriptions and required data be very detailed so that people unfamiliar with the process can execute the steps manually and/or create the appropriate automation. This level of detail is more than you would find in a typical manual test scenario. 9. Description Documentation Standards: These standards should be used through out the creation of Test Cases and Components. a. Put a single quote (‘) mark around proper field names in Oracle, for example ‘Line Type’. b. Put a double quote (“) mark around the parameter where the data will come from.

TurnKey Solutions Corporation Page 19 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 10. Component Status Error The component has errors that need to be fixed. Maintenance The component is ready for automation. Ready The component has been automated, tested and verified complete by Automaters and Subject Matter Experts. Request The component is ready for automation. ‘Request’ is used instead of ‘Maintenance’ when the component is based on or copied from a previously automated component. Under Development The Component is currently under development. 11. Under the Snapshot Tab, capture an image of the main screen used for the Component. There is only room for 1 screen shot. So if you have more than 1 screen, capture the main form. 12. Under the Parameters Tab, document each field in the form, whether or not it is being used in the test. NOTE: Input Parameters: All fields that are eligible to enter or change data must be entered as an input parameter whether or not you will be using them within your Test Case. • • •

The parameter name should represent the Oracle field name. Put an underscore (_) between words. The system will not accept spaces between words. Select the value data type of the field If appropriate, enter the default value. Either derived from Oracle or entered by you. Follow the naming conventions described above.

Output Parameters Enter any data that should be captured either to validate the test plan results or to be used as an input parameter to another component or test case. • • •

Parameter name should represent the Oracle field name Value Type is the data type of the parameter Description is what the purpose of capturing this output data would be.

TurnKey Solutions Corporation Page 20 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Parameters Example

Creating a Component from the Test Case

1. You may create a component directly from the Test Case. The advantage is that the component is placed where you want it. The downside is that there is an extra step to move the component into the component library.

TurnKey Solutions Corporation Page 21 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 2. The same information as previously discussed is required. However, the screens may appear different. The new component wizard will guide you through the steps. 3. Once a component is created, it is placed into a status of “Not Implemented” and is not placed into the Component Tree. Instead, the component is placed into a special queue awaiting automation by an engineer. This prevents the component from being immediately re-utilized in other test cases prior to it being automated. To solve this problem, the component can be manually placed into the Component tree and made available for use right away. To perform this, follow the steps below: Go to the Component Requests Window After the test case is complete and all of the associated components are created and fully defined, record the names of the components so that you will be able look them up later. Next, click on the ‘Components’ icon on the left of the Quality Center window to switch to the Component Tree view. Next, click on the ‘Components Requests’ link at the bottom of the Components Tree window pane:

Select the Component Tree Folder and the Component After selecting the ‘Component Requests’ link, the window containing the components waiting to be moved to the Component Tree will be displayed. The first step is to select the folder to move the component to. Use the Components Tree frame and icons to create the appropriate folder structure to match the Test Plan Tree exactly, if needed (instructions not included here). Make sure that the highlight is on this folder, then Click once on the component to be moved in the ‘Component Requests’ window which takes up the bottom part of the Quality Center browser window:

TurnKey Solutions Corporation Page 22 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Move the Component to the Component Tree Click on the ‘Move’ Icon in the ‘Component Requests’ toolbar to move the component into the Component Tree. The status of the component will be changed automatically to ‘Under Development’, and now appears in the Component Tree. This means that it can be selected and added to new test cases immediately from the ‘Test Script’ tab of an individual test case.

TurnKey Solutions Corporation Page 23 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Test Sets Test Set Test Set – A collection of Test Cases that will test an entire process. 1. Begin by identifying the Process you want to test. 2. Click on the ‘Test Lab’ icon on the left.

3. Highlight the folder where you want the test set to reside.

TurnKey Solutions Corporation Page 24 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 4. Click on the yellow icon to create a new Test Set. (Next to the green folder icon)

5. Enter your Test Set name when prompted. Then click OK.

6. Note that the Execution Grid area opens as well as a new directory structure to the right. The Execution Grid area is where you coordinate the chosen Test Cases. Under the Test Plan tab, you can choose the Test Cases you want by either double clicking or using the Green left arrow.

TurnKey Solutions Corporation Page 25 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 7. Launch Oracle Applications has been Chosen as the first Test Case. It now appears in the Execution Grid.

8. Repeat this process until all desired Test Cases appear in the Execution Grid for this Test Set. 9. Click on the Execution Flow tab.

TurnKey Solutions Corporation Page 26 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 10. You can use this window to place the Test Cases in the order in which they should be run. 11. Draw an arrow between the Test Cases, indicating the desired flow. Start by holding the left click on the Test Case that is first. Then drag the arrow to the next Test case.

TurnKey Solutions Corporation Page 27 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 12. To make these in a nice order, click on the ‘Perform Layout’ button.

13. To run the Test Set, you must be in the Execution Grid tab. You can either click the Run button, which gives you the ability to run selected Test Cases. Or you may click the Run Test Set button which will run all the Test Cases in the Test Set. Some people have found it helpful to launch QTP prior to running the Test Set. In some cases the scripts run better this way. 14. After the script has run, you can read the report to verify the results. 15. In the ‘Last Run Result’ section at the bottom of the Execution Grid section, click the ‘Open Report’ link.

TurnKey Solutions Corporation Page 28 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

16. Here you can see exactly what happened. If a script does not complete successfully, this report will help determine the reason.

17. Document any issues in the Delta Analysis Tracking Sheet and work with the Automation team to resolve.

TurnKey Solutions Corporation Page 29 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Debugging Tests Because of the heavy dependence on data stored outside of the tests, we need to run the test from within Quality Center during the Debug process. That way, the DataLoad component, found at the beginning of test cases, has a chance to run and pull all the data from the DataLoadManager’s DataSheet for that test case. To run a test case in Debug Mode, select the test case in Quality Center that you wish to debug. Then select the Play button tab.

on the upper right hand side of the Test Script

This will open the Debug Components dialog. From there, you select the checkboxes for the components you wish to run in Debug Mode. When execution begins QuickTest will insert a breakpoint at the beginning of the checked components. A Breakpoint is a debug tool that stops execution of a component at the line where the Breakpoint is set. When test run reaches the checked component, QuickTest will maximize and user is able to manually walk through the business component while viewing how the application responds.

TurnKey Solutions Corporation Page 30 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Select the OK button to start the test running in Debug Mode. When you find an issue in a component, you will need to stop the test in Quality Center first. You do that by selecting the Stop Run button.

After the test has terminated a dialog box will open with the test results from the test run. The failed components will need to be re-opened in QuickTest to correct the problem.

TurnKey Solutions Corporation Page 31 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Once issues have been addressed, run the test case again to ensure the issues were resolved.

TurnKey Solutions Corporation Page 32 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Data Sources (4 levels of Data) Data Sources – The 4 locations of data that can be used in a test case and/or a component. Data can be supplied to a component in 4 basic ways. Each of these will be described and the differences between them discussed. Default Data (Level 1) in the Business component Each component can be given default data. This data will allow running a component via QTP with a specific set of data. This data can be assigned via QTP or QC. In QTP, set the default data in the ‘Business Component Settings’ window by going to the ‘Parameters’ tab and enter data in the Default Value column.

TurnKey Solutions Corporation Page 33 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual In QC, set the default data in the ‘Business Component’ section by going to the ‘Parameters’ tab and enter data in the Default Value column.

The purpose of setting default data is two-fold. The first is to allow the component to be run in QTP during development. The default data will be used for that run. This can also be achieved by setting the input parameters on the Input Parameters tab after pressing run in QTP.

TurnKey Solutions Corporation Page 34 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual The second is so static data will be placed in the test case when a component is added. This is useful when data is rarely changed and when the data will not be pulled from a more dynamic place such as the data spreadsheet. When the component is complete it is important to delete the default data that will be changed for most test cases. The data that remains the same should be left. If this is not done then it is more likely that inaccurate data will be placed in the test case and debugging the test case becomes more problematic as each piece of data needs to be analyzed to find the cause of the error. Test Case Data (Level 2) in the Test Plan Data for a test case can be set in the Test Plan. Static data for a test case will be used when the test case is run. This can be used for data that will not change from test run to test run. Prime examples of this is the data used for the Navigator Forms and the Common button components.

The important details to remember is that this is static data and will remain the same for all runs of the test case. Dynamic data, such as an invoice number or supplier name, should come from the Data spreadsheet and not be placed as static data in the test case. Spreadsheet Data (Level 3) in the Test Plan Dynamic data is pulled from the spreadsheet as demonstrated in section ‘TurnKey Data Management Solution’ below. The advantages of this method is that the data is dynamic, supports data transfer between test cases and can be easily changed from one test run to the next. Multiple spreadsheets can be utilized to support multiple test scenarios using the same test case. If static data was used then many changes would be necessary prior to the next run of a test case. Run-Time Data (Level 4) in the test set. TurnKey Solutions Corporation Page 35 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Occasionally there is the need to change data at the test set level. This can occur if the data needs to change only for this test set and/or is based on the placement of a test case within a test set. One example of this is the ‘Switch Responsibility’ test case. This test, as the name indicates, will change the responsibility for the user. During a run of a test set it may be necessary to change the responsibility of a user several times. This could be done using a spreadsheet but the issue of identifying which iteration to run (e.g. GL or AP responsibility) will arise. The other methods only allow you to enter static data and this data would need to change over the course of the test set. To change this data there are two steps that need to be accomplished. The first is to set the test case to use a Run-Time Parameter. This is done at the test case level. Click on the input parameters in the test case.

TurnKey Solutions Corporation Page 36 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Select ‘’ from the drop down.

Replace ‘Enter param name’ with the name of the run time parameter keeping the braces “{}” in the field and then click ‘OK’.

TurnKey Solutions Corporation Page 37 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

The second step is to set the value of the Run-Time Parameter in the test set. Go to the appropriate test set and right-click on the test case and select ‘Iterations…’.

Enter the value to use for this test case in the parameter box. In this case ‘Accounts Payable’ has been entered.

TurnKey Solutions Corporation Page 38 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Notice that there are two ‘Switch Responsibility’ test cases in this test set.

Set the responsibility for the second test case as was shown above. This allows separate values to be used for each instance of the test case within this test set. Side Note: You may have noticed that in the Iterations window there was a button called ‘Add Iteration’. By clicking this button and thus adding iterations, the test case will run in its entirety the same number of iterations that you add. For this test case it does not make sense to use this functionality but it can be used to cause a test case to run a specific number of times using the same data for the test case. This will work regardless if the data is static or dynamically retrieved from the data spreadsheet.

TurnKey Solutions Corporation Page 39 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

TurnKey Data Management Solution The TurnKey Data Management Solution (TDMS) improves upon the standard Quality Center functionality. Using this solution allows for easy data maintenance, iteration control and increased flexibility. The solution is based on a standard Microsoft Excel workbook. Data and flow control is determined via a worksheet in cooperation with the DataLoad component. There are three main parts to the TDMS: DataLoad Component, Data Spreadsheet, LoadData Function. There is a utility that will assist in creating the worksheet for each test case: AutoSpreadsheet Creation. Each will be discussed in turn.

DataLoad Component The DataLoad Component (DLC) configures settings at the beginning of each test case. The specific workbook, worksheet, and data scenario (DataIndex) along with some iteration data is initialized. This data is thereafter available for use by the components in the test case. The DataLoad Manager workbook must be in the File path identified by the “DataFile” input parameter. The path and file name is normally “C:\DataLoadManager.xls”. By updating this parameter, you can place the spreadsheet in any directory, but it should be consistent across all test cases. 2. The “Datasheet” is the tab or worksheet name in the DataLoad Manager workbook. These must match exactly. 3. The “DataIndex” may either be a number referring to the Data Index scenario in the spreadsheet or a RunTime parameter as shown below. A Run-Time parameter will allow the user to change the data scenario in the Test Set. This is used to choose among many Data Scenarios setup for a specific test case or to run a series of Data Scenarios. 1.

TurnKey Solutions Corporation Page 40 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual DataLoadManager.xls An Excel file that should be located on the local computer, the DataLoadManager.xls is where the Oracle Accelerator houses all of its data for use in its test cases. Each test loads values from this file and uses them to navigate the various forms used within the test case. The values found within the worksheets are generally used as inputs needed for form fields to run the test. Generally the DataLoadManager.xls is placed at the root of the C:\ drive. The headers in the DataLoad Spreadsheet must match the component names, parameter names and inputs exactly. There is a specific structure for the worksheet and it must be followed exactly for it to be used. All components except for the DataLoad component is included on the worksheet. All inputs and outputs from a test case are stored on the same worksheet.

Data Spreadsheet Tips and Guidelines • Datasheets are located in the Subject/BPT Resources/DataLoadManager folder in Quality Center. • Do not use QuickTestPro’s DataTable Method for any input or output data. WorkSheet Structure: The first four rows of the worksheet are used to identify the Groups, Components, Input Parameters and Output Parameters for a test case. Looking at the screenshot above you can see that the first row is for Groups, the second for Component Names, the third for Parameter types (Input, Output) and the fourth is the name of the parameters. The first column is used to identify the separate data scenarios for a test case. In a simple test case all of the data for a test case could be stored on one row. For more complex test cases that require iterations the data for a single test case run may be greater than 10 rows. How this works will be explained later.

TurnKey Solutions Corporation Page 41 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Input/Output Data: Data for input and output is stored on the same worksheet. This makes it easy to see all of the data that was used in or generated by a test case. The third row in the worksheet is used to identify if a parameter is used for input or output. The values placed in this column matches the parameter types that were defined for that component in QC. The fourth row is the name of parameters that were created in QC. The fifth row is used for data that is entered into the application. A simple example is shown below.

Since the DataLoad Component will not be in the worksheet, the first component is the ‘Navigator Forms’. This component will generally use static data at the test case level. Due to this, the Parameter Type and the Parameter values in rows three and four are left blank. The next component is the Requisition Header. The input parameter ‘Number’ is left blank so the system under test will generate the number for us. The Type is set to “Purchase Requisition” and will be entered into the form. The same goes for the ‘Description’ parameter. The ‘DFF’ will be left blank. The next column is for the Output parameter ‘Requisition Number’ row 5 would normally be left blank, however in this case there is a value there indicating that this worksheet has been used to run a test case the output that was generated is “5831”.

The remaining components would be entered just like for the ‘Requisition Header’ component. NOTE: When using the Excel function =Now() in a data field in the worksheet, be sure to enter the function as =Text(Now(),dd-mmm-yyyy). Linking Data Between WorkSheets In Order to use data that was output from one test case for another test case, a standard cell link must be created in the workbook between worksheets. First select the cell you wish the value to appear in your current test. Then, press the “=” (equals) key from your keyboard. With the mouse, navigate to where the output value is stored, select the output cell and then press the “Enter” key from your keyboard. This will link your test’s input value to the output value of another sheet. TurnKey Solutions Corporation Page 42 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

In the above example the Supplier will be pulled from the ‘PO – Create Supplier’ worksheet and used as an input value.

LoadData Function The LoadData function is placed at the beginning of every component that will use data from the Data workbook. This function will use the workbook, worksheet and data scenario that was determined by the DLC to retrieve data for the component currently being run. This function will also track how many times each component has run and in what order. This data is used to allow this function to pull data for the correct iteration of a component. Once this function has performed the tasks listed above it will pull the correct data from the worksheet and place it into the input parameters of the component currently being run. If there is no data to populate then execution will continue.

Auto-Spreadsheet Creation The utility “Auto-Spreadsheet Creation” is a traditional automated QuickTest Professional test. Making this a QTP test allows for easy use and flexibility. This utility creates a workbook with a unique name (AutoSpreadsheet.xls). A worksheet is added to the workbook for each test case. Either a single test case, all test cases in a module or all test cases in a test set can be automatically added to a new workbook.

TurnKey Solutions Corporation Page 43 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual NOTE: In order to run this utility and retrieve data from QC the user id used to connect QTP to QC must have “Admin” privileges for the QC project.

In order to create a workbook for a test set the changes are made in QC. 1. Add the “Auto-Spreadsheet Creation” test case to the test set for which you want to generate the workbook and worksheets. 2. Run the “Auto-Spreadsheet Creation” test case from the test set.

TurnKey Solutions Corporation Page 44 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual In order to create a workbook for a single test case or a module this needs to be done in QTP. 1. Open the “Auto-Spreadsheet Creation” in QTP. 2. Edit the “TestCaseName” variable in the script to match either the test case name or module prefix. The example shows creating a workbook for all of the AR test cases. The module specific workbook is determined by the test case name so following the standard of a module-specific prefix in every test case name is critical. To only create a workbook for a single test case the value could be TestCaseName = “AR – Apply Manual Receipts to Invoices”. 3. Run the test case in QTP.

TurnKey Solutions Corporation Page 45 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Iterations Iterations are used in two basic scenarios. The first is used to enter multiple lines in a table or to conduct a specific sub-process multiple times. The second is used to run a test case with multiple sets of data. These two scenarios are not exclusive. For example: a test case could be run to create a sales order and that sales order could have multiple lines. This test case would be setup using the first Iteration scenario. This same test case could then be run with multiple sets of data to create multiple sales orders each with a varying number of lines. The second scenario would be used to run the multiple sets of data and can be helpful when generating data for other test cases to use or when specific application functionality is tested through varying data scenarios. The data worksheet is setup in specific ways for the two basic scenarios. The three examples shown below are for the first scenario. For a single iterated component which could be used to populate multiple rows in a table the first example shows that there is a blank colored column to the left of that component. In the first row the cells are merged spanning the blank colored column and the parameter columns for that component. The color is helpful to identify at a glance what is occurring in that component. The second example is similar but displays the spreadsheet when two components are next to each other and each will be iterated a certain number of times independently of the other. Single iterated component.





2 Single iterated components. (for iterating one component x times then the next y times)





The third example below shows a different setup where a group has been created in QC. This will cause the first component to be run once and then the second component to be run once. Those two components will iterate in a loop one after the other for the number of iterations that were set in the grouping. This can be used to allow a sub-process to be iterated multiple times. The difference in this example is that the first row is merged across all of the components which are in the grouping and the blank colored column. The color is used the same way as above to indicate what is occurring in the test case. 2 Components iterated in a group.



TurnKey Solutions Corporation Page 46 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Method 1A – Iterating Component(s) within a Test Case This method is used when one or more components are to be run multiple times with different sets of data independent of each other. The components must be designed where the start and end points of the component are the same in the application. After the setup is complete the test set or test case may be run normally. The component iterations will occur automatically as defined in the setup of the test case and the data in the worksheet. QC Setup Business Components 1. Go to the ‘Business Components’ section in QC 2. Select the component that will be iterated 3. Click on the ‘Details’ tab 4. Set the ‘Is Iteratable’ flag to ‘Y’ (The flag name may vary). Verify that the component starts and ends at the same point prior to updating the flag.

3

4

1 2

TurnKey Solutions Corporation Page 47 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Test Plan 1. Go to the ‘Test Plan’ section in QC 2. Select the test case that contains the component to be iterated 3. Click on the ‘Test Script’ tab 4. Click on the Input Parameters for the component that is to be iterated

3

2 1 4

5.

Click on ‘Add Iteration’ for each iteration of the component. NOTE: It is necessary to add at least 1 more iteration in this window than there is data in the data worksheet.

5

TurnKey Solutions Corporation Page 48 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

6. Data can be updated in the table if data will not be retrieved from the Data worksheet. If data is to be retrieved from the worksheet then these values will be overwritten and may be left blank. 7. Close the Component’s Iterations window by Clicking on ‘OK’

7

Method 1B – Iterating a Group of Components within a Test Case This method is used when two or more components are to be run multiple times in succession. All of the components in the group will run once in order prior to running the second iteration. Each iteration may use different sets of data. After the setup is complete the test set or test case may be run normally. The group iterations will occur automatically as set in QC and the data worksheet. To create an iteration group go to QC. 1. Select the test case in the Test Plan section of QC. 2. Select the components that are to be in the group

TurnKey Solutions Corporation Page 49 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 3. Right-Click on the selection and select Grouping->Group Components

4.

Click on the “Yes” button in the ‘Confirm’ pop-up to indicate that you want to allow iterations for the grouped components.

To set the number of iterations of the group 1. Click on the “1 Group Iteration” link at the top of the grouped components.

TurnKey Solutions Corporation Page 50 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

2. Click on the “Add Iteration” button until the number of iterations listed is one greater than the number of iterations of data in the worksheet. Then click “OK” in the Group Iterations window.

Method 2 – Iterating a Test Case with Different Data Scenarios This method is used when a test case is to be run multiple times using different data scenarios. The test case will run as many times and with the data scenarios identified in the Run-Time parameters. To iterate a test case in this manner, the DataLoad component in the test case must be using a Run-Time Parameter for the DataIndex. See the DataLoad Component section and/or the RunTime Parameter section above for more information. TurnKey Solutions Corporation Page 51 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

The number of iterations and which Data Scenarios to run is determined by the iterations in the test set. 1. Go to the Iterations window for the test case. 2. Click the Add Iteration button for the number of times that you want to iterate the test case. 3. Modify the value in the DataIndex column to match the data scenario in the worksheet. NOTE: If after setting up multiple data scenarios, a single data scenario can still be run by clicking on the “Select Iterations” button and limiting the iterations to a range or to a single iteration. The data will be retrieved appropriately from the worksheet.

The worksheet for this Iteration setup would look like the following:

Notice that the Same Data Scenarios’ ‘DataIndex’s that were entered into QC are also entered into the worksheet. This is the link that tells TDMS to use specific rows of data from the worksheet.

TurnKey Solutions Corporation Page 52 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Complex Flow Control Using Group Iterations The examples given up to now for the TDMS and iterations have used basic scenarios to illustrate conducting iterations. The TDMS supports multiple levels of sub-iterations and branching. Through the use of TDMS and the worksheet a test case can create a purchase order, zero or more lines, each of those lines can have zero or more shipments and each of those shipments can have zero or more distributions. This nested iteration functionality can continue to an unlimited number of sub-iterations. The Group Iteration for this complex scenario is setup exactly as described above. The setup of the worksheet is the key to implementing the complex flow control. On several examples shown above there has been additional shading of cells in a data scenario. Below is an abbreviated example of a worksheet.

• • • •

Column ‘A’, Rows ‘5-10’ have been merged to indicate that all data in those rows refer to one data scenario. That data scenario will be executed for one test run of the test case. The PO HEADER component will run once. The group iteration has 5 components each of which will run 6 times (once for each row ‘5-10’). The last component APPROVE will run once. Columns ‘E’ and ‘G’ have been edited so the ‘Parameter Type’ (row 3) is set to “Note” and the ‘Parameter’ (row 4) is set to a short description of what the component is doing. The data is still being retrieved from the static data in the test case in QC. The shading indicates to the viewer what will not be run and also tells TDMS that a particular component should not be executed for the current iteration.

Step-by-step, this test case will do the following: 1. Run PO Header and Enter “Standard PO” into the ‘Type’ field. 2. Start Group Iteration 1 3. Run PO LINES and Enter “1” in the ‘Num’ field. 4. Run Common Button and click on the button as identified in the static data of the test case. (Open Shipments Window) 5. Run SHIPMENTS and enter “1” in the ‘Ship_Num’ field. 6. Run Common Button and click on the button as identified in the static data of the test case. (Open Destination Window) 7. Run DESTINATION and enter “2” in the ‘Quantity’. 8. End Group Iteration 1 9. Start Group Iteration 2 10. SKIP PO LINES 11. SKIP Common Button 12. SKIP SHIPMENTS 13. SKIP Common button 14. Run DESTINATION and enter “3” in the ‘Quantity’ field. 15. End Group Iteration 2 16. Start Group Iteration 3 17. Run PO LINES and Enter “2” in the ‘Num’ field. TurnKey Solutions Corporation Page 53 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 18. Run Common Button and click on the button as identified in the static data of the test case. (Open Shipments Window) 19. Run SHIPMENTS and enter “1” in the ‘Ship_Num’ field. 20. Run Common Button and click on the button as identified in the static data of the test case. (Open Destination Window) 21. Run DESTINATION and enter “2” in the ‘Quantity’. 22. End Group Iteration 3 23. Start Group Iteration 4 24. SKIP PO LINES 25. SKIP Common Button 26. SKIP SHIPMENTS 27. SKIP Common button 28. Run DESTINATION and enter “3” in the ‘Quantity’ field. 29. End Group Iteration 4 30. Start Group Iteration 5 31. SKIP PO LINES. 32. SKIP Common Button. 33. Run SHIPMENTS and enter “2” in the ‘Ship_Num’ field. 34. Run Common Button and click on the button as identified in the static data of the test case. (Open Destination Window) 35. Run DESTINATION and enter “2” in the ‘Quantity’. 36. End Group Iteration 5 37. Start Group Iteration 6 38. SKIP PO LINES 39. SKIP Common Button 40. SKIP SHIPMENTS 41. SKIP Common button 42. Run DESTINATION and enter “3” in the ‘Quantity’ field. 43. End Group Iteration 6 44. Run APPROVE and enter “01-JAN-2006” in the ‘Date’ field. Stepping through each step and comparing it to the setup in the worksheet will make it clear what is happening in that test case. It is key to note that if the cells in a component are shaded then that component will be skipped. If the cells are not shaded then the component will be executed with data from either the worksheet or static data from the test case in QC. Based on the functionality and behavior described above it now may become clear that a group of components can execute or not execute based on data. Therefore the flow of your components can be controlled via the worksheet and allow you to add branching or complicated nested iterations. Branching is when you will need to open different forms to complete different types of line items all within the same test case. To branch you will need to add the input parameters to some if not all of the common components. By providing different parameter values to components like Common Button you can steer the test flow down a different path for any given iteration. That path can then be tested by activating only the component used in that path while skipping any components used in alternate paths.

SME Automation Object Repository The Object Repository contains all object definitions for use with the Accelerator and its business components. QuickTest uses test object properties to uniquely identify each TurnKey Solutions Corporation Page 54 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual object or field on an Oracle form. It stores these definitions inside the Object Repository. It is very important that the Object Repository be administered responsibly. Failure to do so may result in inconsistent behavior during test development and/or cause test runs to fail erroneously. To open the Object Repository you may select the select: Tools->Object Repository from the menu

icon on the QuickTest toolbar or

The Object Repository is organized in a tree structure, like that of your file system. But, rather than folders and subfolders, each set of objects belongs to a parent object. Thus, the Due Today Checkbox (in this example) belongs to the Date Ranges tab, the tab in turn belongs to the Find Expected Receipts form, and the form belongs to the Oracle window. The Object Repository uses this structure to keep track of where objects belong in the Oracle Object Hierarchy. Individual objects are then further defined by their Properties (see Section on Object Identification for more information). Thus, (in this example) the Checkbox is being identified by its Developer Name property. If you change the values attached to the property, you change the object QuickTest looks for when you use its name in your components. You may change the object name in the Shared Object Repository section without changing the object’s properties. The name change will be reflected thereafter in the Keyword View or in any new code you develop. Be careful however, because though you don’t change the actual properties of the object by changing its name, any components that came before the change might rely upon the old name and fail because of your changes. For that reason we recommend that you record all objects into the Object Repository and make any name changes you might find necessary before building your components. It is a good idea to name objects to reflect what is shown on the form. TurnKey Solutions Corporation Page 55 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual One serious limitation of the Object Repository is that only one person at a time can edit it. Note that editing a Business Component in Quality Center does not lock out others from editing the Object Repository. However, if you are the first person to open a Business Component in QuickTest, you will lock the Object Repository, and all others who open Business Components that use that Object Repository thereafter will have a read-only version of the Object Repository while editing. Highlighting Objects stored in Object Repository If you would like to view the object in the application that is listed in the object repository, the highlight button can be used. To highlight an object: 1. In QuickTest, open the Object Repository by selecting the select: Tools > Object Repository from the menu 2.

icon or

Select an object listed in the Shared Object Repository list

3. Make sure that QTP is tiled on top of the open application (Do not minimize application) 4.

Select the Highlight button

5.

Associated object will appear highlighted in the application

NOTE: if the object you selected to highlight does not appear on the page that is currently open then nothing will happen and no objects will get highlighted Object Spy There may be instances where you want to view the properties of an object without having to drill down and locate the object in the object repository. To view the properties of an object and it’s associated methods: 1.

In QuickTest, select the object spy icon on the menu

2.

Select the pointing hand button

on the toolbar or select: Tools->Object Spy

3. Your icon turns into a pointing finger, using the icon click on the object in the application for which you’d like to view the properties/methods

TurnKey Solutions Corporation Page 56 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

The first example shows the properties of the selected object and the second example shows the available methods that can be performed on that object. NOTE: by spying on the object you have NOT added it to the repository.

Application Areas The Application Area is a resource that configures the test environment. When you create an application area, you create a resource that contains all of the application area settings and resources needed for your business component. The Application Area is meant to configure all the settings found within QuickTest’s Business Component Settings under the Components/Settings menu. Building Application Areas When you create an application area, you specify the Application Area properties, associations to any QuickTest Professional add-ins, function library files and the location of the shared object repository to be used. You can create as many application areas as needed. For example, you may decide to create an Application Area for each Web page, module, window, or dialog box in your application. Alternatively, for a small application, one Application Area may be all that is needed. For the Oracle Accelerator, one Application Area is created per Oracle Form which may contain several windows that fall under the same Oracle form name. Steps on Creating an Application Area: TurnKey Solutions Corporation Page 57 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 1. In QTP, select file>New>Application Area 2. Find Oracle Technical name (Help>About Oracle Applications) For example: Post Journals (Oracle Form GLXJEPST) 3. Enter Oracle Technical name and a brief description in Description field under Properties Tab.

4. Under Associated Addins, make sure Oracle and Web are included. If they are not, click the ‘Modify’ button and add them. If they are not in the list, close QTP, Restart and make sure the correct addins are selected when starting QTP. You will not need to reload oracle apps. 5. Click Resources Tab

TurnKey Solutions Corporation Page 58 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

6. In the associated Library files, make sure the following 5 files are attached. If any are missing, add them. If more are there that are not part of the 5, take them out:  Common.txt  Web.txt  Oracle.txt  CommonFunctions.vbs  OracleCustomFunctions.vbs 7. Under the same tab, for Object Repository Location, select the Search icon 8. Under Subject/BPT Resources>Object Repositories – enter a new OR name in the Attachment Name field. (i.e. GL_PostJournals_ GLXJEPST) 9. Click ‘OK’ 10. Click ‘OK’ 11. Click ‘Yes’ to create new OR. Adding objects to the Application Area: 1. Capture the Objects associated with the form(s). 2. Make sure that application is open and QTP is tiled. (QTP on top of apps, but not the entire window. Apps can be entire window.) Open the Object Repository by selecting the Repository from the menu 4. Select ‘Add Objects” button. 5. Point at the form/click on form title bar. 6. Select ‘OK’ in QTP window. 3.

icon or select: Tools > Object

TurnKey Solutions Corporation Page 59 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 7. Select Radio button for recognize window and all its direct decedents. (does just the 1 window.) 8. Select ‘OK’ 9. Review objects in QTP window. Rename if necessary or delete inappropriate objects (objects that would never be used for automation under any circumstances) 10. Repeat these steps for each window that goes in this AA/OR (has the same Oracle form technical name). 11. When complete, select ‘OK’. 12. Select File->Save 13. Enter Application Area name i.e. GL_PostJournals_GLXJEPST 14. Enter Description i.e. AA for Post Journals (Oracle form GLXJEPST). 15. Select ‘OK’ Assign Application Area to a Component: In order for the resource settings to apply it must first be assigned to a business component. 1. Go to the Component in Quality Center. 2. Select the ‘Steps’ tab. 3. Select the following icon to select the Application Area. 4. Select the appropriate Application Area. 5. Select ‘OK’ 6.

Select the diskette icon

to save.

How to update new objects within an existing AA/OR. Open the existing Application Area or a Business Component that uses that Object Repository in QTP. • In QTP, select file>Open>Application Area > XXX. Click ‘OK’ on the Application Area Settings window. • Click ‘OK’  Capture the Objects associated with the form(s). o Make sure that Oracle Apps is open and QTP is tiled. (QTP on top of apps, but not the entire window. Apps can be entire window.) o Open the OR. Click on “Tools> Object Repository (or click the 3d cube icon). o Click the ‘Add Objects” button. o Point at the form/click on form title bar. o Click ‘OK’ in QTP window. o Select Radio button for recognize window and all its direct decendents. (does just the 1 window.) o Click ‘OK’. o Review objects in QTP window. Rename if necessary or delete inappropriate (objects that would never ever be used for automation under any circumstance) objects. o Repeat these steps for each window that goes in this OR. o When complete, click ‘OK’. o File>Save o This completes the AA/OR update process. TurnKey Solutions Corporation Page 60 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual Working with Oracle Forms Keywords allow test creation based on business terms, rather than complicated code languages. In this section we will describe some of the technical features revolving around Keywords and the Oracle Accelerator. The Keyword View uses the Object Repository to populate its Item lists. So, before you may use Keywords you must have an Object Repository associated with the components you are working in (see Section on Building Application Areas for more information). The Item column is populated with all the objects found in the associated Object Repository. It works hieratically, in other words, you see the top-most or parent objects first and as you drill down the Keyword View exposes the next level of objects. When adding an item the dropdown list will contain all the objects that are child objects of the object selected in the previous step. In the example below, you see how the Oracle Find Expected Receipts window is on top line, followed by the Item tab (line 2) followed by the Description field (line 3). So, the Oracle Find Expected Receipts window is the parent object and the Item tab is its child object, and then in turn, the Item tab is the parent object to the Description field.

To select an object that is not the child object of the object selected for previous step you would select “Select another object”. This would bring up the object repository associated to that component. Any object can be selected from this list.

TurnKey Solutions Corporation Page 61 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

The Operation column is populated by functions and methods used by the object selected for that line. When you select the Item from the object repository the operation dropdown will populate with a list of both the custom functions registered to this object type and the standard VBScript methods that can be performed on this object type.

You can access VBScript help at anytime in QuickTest Professional by selecting the Help Menu. By searching on a specific object type you can view the associated operations for this object type and get an explanation of the usage and required arguments associated to this operation. The Value column is populated by the arguments required to perform this operation. You may type directly into this field or select the button in this column to parameterize this value (see Working with Parameters). In the below example the ‘Text’ value is required to specify what is typed into the Descriptions text field.

TurnKey Solutions Corporation Page 62 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Working with Parameters Parameters provide the test data to the fields in an Oracle form during a Test Run. A Parameter might hold the First Name of a customer, or a Requisition Number that is needed to fill out a form. Using Parameters is a multi-step process from both the Functional and Technical side.

Using the example above, we will assign a parameter to the “Description” field. This is done by selecting the button.

TurnKey Solutions Corporation Page 63 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

To Parameterize the value (see example above): 1) Select radio button for Parameter 2) Select Component parameter from the list 3) The Name dropdown will populate with the list of parameters that were added by the functional expert when component was created 4) Select applicable parameter name and select OK In the Example below, notice that in the Value field for the Description object, there is now text inserted. This, Parameter (“Description”) is how QuickTest associates a Component Parameter to a specific Value in Keyword View.

Working with Oracle Tables An Oracle table does not refer to a table in the database. This refers to a table structure in Oracle Apps where there are multiple rows and columns of data. From a user point of view it is very easy to identify what row that you will work with. It is not as clear from an automation perspective whether the row is a new empty row, a new row with default data or a previously saved row that TurnKey Solutions Corporation Page 64 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual needs to be edited. The information that is passed in the steps has to be exact so QTP will process the data correctly. When a Business Component is newly created and works with an Oracle table, the input parameters and the detail steps should only deal with one row of the table. If the component needs to create a new row or edit a row, the steps need to describe the specific actions to be taken. It must be very clear in the steps what row and/or cell in the table should be processed by QTP. An Oracle Table can be presented in a variety of different formats. Each of these formats need to be understood as the automation will differ depending upon the format. Various examples of steps are shown below with respect to the different table formats. Format 1 – Table contains a Num/Number sequence column or a unique data column (item, invoice number, etc.) The presence of a unique id such as the number sequence or an invoice number allows a specific search for a row. If the row does not exist then a row can be created. This is the main method for dealing with tables. This supports editing a pre-existing saved row, editing a new row with defaulted values or creating a new row. An example of steps is shown below: 1. Verify that the ‘sample’ form exists. 2. Set Focus into the first row of the table 3. Find the row where the “Number_Seq” equals the ‘Num’ in the table, if there is not a match then create a new row. 4. Use the row found or created in step 3 for the following steps 5. Enter “Number_Seq” in the ‘Num’ column 6. Enter “Item” in the ‘Item’ column. 7. Enter “Quantity” in the ‘Qty’ column • •

•

When editing a pre-existing saved row, step 3 will find the desired row that matches the unique id. When editing a new row with default values, step 3 may or may not find the desired row. If a number sequence is used then the row is likely to be found. If an item number is used then it is not likely to find the row as that item has not yet been entered. If the row is not found then it will attempt to create a new row. Since the row is not complete that creation will not succeed and the current row will be used to enter data. ASSUMPTION: At least one Required Field is NOT populated. See Format X for instructions when there are no required fields or the required fields are defaulted. When creating a new row, step 3 will NOT find the desired row. A new row will be created.

The output of step 3 is the row number to use for entry of data. Technical Note: if no row is found then ‘0’ will be output. ‘0’ input as the row number will cause a new row to be created by going to File->New.

TurnKey Solutions Corporation Page 65 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

1. 2. 3. 4. 5.

6.

Step 1 verifies that the ‘Bills of Material’ form currently exists. This is the standard first step in most of the components in the Accelerator to verify that the application is at the correct starting point. Step 2 selects the tab in the form window where the table is located. Step 3 sets focus to the first row of the table. It is important to set focus into the table so QTP will process the data in the correct location of the table. Additionally Oracle will sometimes default data into the first row only when focus is set to that row. Step 4 searches the ‘Item Seq’ column for a value that is in the “Item_Seq” input parameter. The number of the row that contains that value is placed into the Local Parameter “Row_Number”. If a row is not found then the number ‘0’ is returned. Step 5 will enter the “Item_Seq” input parameter value into the “Item Seq” column for the row that was identified in Step 4. If the row number is ‘0’, meaning that a row was not found, then a new row will be automatically created and then the input value will be put into the correct column. The current row number is output into the Local Parameter “Row_Number”. Step 6 -> Step 9 are repeated for additional columns and data values. Notice that each of these steps output the row number into the Local Parameter and each step uses that Local Parameter as the row number. This links everything together to make sure that all data is input into the same row.

The operation that is being used “OptionalEnterField” is a custom coded function that contains a lot of functionality. It will create a new row, populate values, create a value with a unique id or skip entry into that field. Due to the operation being optional it is possible that the row would not be created in the fifth step but in a subsequent step. The row would only be created when there is data to be entered. If no data was present to be entered then a row would not be created. This is why it is critical to always output the row number to a local parameter and then use it in all of the steps. If this was not done then an error could occur if a row had not been created. Format 2 – Each new row either does not have any required fields or the required fields have default values. In Format 1 above, a new row would be created if the unique id was not found. If there was already a new un-saved row with empty required fields then a new row could not be created. However, if the required fields had data or if there were not any required fields then a second new row could be created when it was not intended. This can lead to multiple unintended rows in a table. The solution is to deal with each situation via a different component. One component would add new rows and enter data in each new row. A second component would edit a specific row. On TurnKey Solutions Corporation Page 66 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual cursory review it may not seem to be a problem and that this could be solved using the exact same method as Format 1. The issue is most clearly seen when focus is set to the first row of an empty table. By setting focus to that row a new row is automatically created. Since the row has all required fields entered the act of selecting File->New will create a second row of data in the table. The component to add a new row would look identical to the component in Format 4. Setting focus to the first row would not occur as this would insert a new row via that act. The component to edit an existing row would be similar to the component in Format 1. There would be one difference in that component. The step to search for the Unique ID would accept the value “micFail” instead of “micPass” for the eventStatus argument. This difference would tell QTP to report an error if the value being searched for was not found.

Format 3 – No Unique ID is available for finding a specific row, Editing a row When there is no Unique ID for which to search then editing a row cannot be done based on data in the oracle table. This means that editing and adding a row must be dealt with through separate components. To edit a row it will have to be defined in relation to the location in the table. The first row in a table will be identified by row number ‘1’, the second by row number ‘2’, etc. The row number will be an input parameter to the component. The source of the data will be the data spreadsheet. This method is not as reliable as finding a specific row that matches a unique id. Execution is dependent upon Oracle to always display rows in the same order. While this is generally done there maybe instances where this does not occur and unusual results may occur.

TurnKey Solutions Corporation Page 67 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual 1. 2. 3. 4.

Step 1 verifies that the ‘Journals’ form currently exists. This is the standard first step in most of the components in the Accelerator to verify that the application is at the correct starting point. Step 2 will enter the “Account” input parameter value into the “Account” column for the row that is identified by the component parameter “RowNumber”. The current row number is output into the Local Parameter “Row_Number”. Step 3 will enter the “Credit” input parameter value into the “Credit” column for the row that was output for Step 2. Step 4 -> Step 5 are repeated for additional columns and data values. Notice that each of these steps output the row number into the Local Parameter and each step uses that Local Parameter as the row number. This links everything together to make sure that all data is input into the same row.

Format 4 – No Unique ID is available for finding a specific row, Adding a row When there is no Unique ID for which to search then editing a row cannot be done based on data in the oracle table. This means that editing and adding a row must be dealt with through separate components. To add a row, the step is to pass into the OptionalEnterfield method the data value “New” for the RecordNumber. This will cause the File->New menu selection to occur.

1. 2. 3. 4.

Step 1 verifies that the ‘Journals’ form currently exists. This is the standard first step in most of the components in the Accelerator to verify that the application is at the correct starting point. Step 2 will create a new row by selecting File->New from the menu and enter the “Account” input parameter value into the “Account” column for the row. The current row number is output into the Local Parameter “Row_Number”. Step 3 will enter the “Credit” input parameter value into the “Credit” column for the row that was output for Step 2. Step 4 -> Step 5 are repeated for additional columns and data values. Notice that each of these steps output the row number into the Local Parameter and each step uses that Local Parameter as the row number. This links everything together to make sure that all data is input into the same row.

Format 5 – Rows of a table that cross Tabs When rows of a table cross over to 1 or more tabs then keeping track of the row to work with becomes very important. There are two general scenarios that occur. a. If on each tab there is a way to uniquely identify each row using the number sequence or an item number then each tab can be a separate component. Each TurnKey Solutions Corporation Page 68 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual component would be developed to find the correct row and then enter data in that row. This is discussed in full under Format 1. b. If on each tab there is not a way to uniquely identify each row then all tabs should be contained within the same component. The component would be developed according to the requirements of Formats 1-4, but instead of stopping at the one tab all data would be entered across all of the tabs for that one row. This method will track the individual row across all of the tabs so it is not necessary to find the row on each tab.

In all formats the output of the OptionalEnterField method is used as the input to the next occurrence of the OptionalEnterField method. This method will output the row that is being worked on. If no row is being worked on due to the data value being blank then the row number will be passed through. If the row number being passed into the method is ‘0’ or ‘New’ then if there is data to enter a new row will be created and the new row number will be output from the method. This functionality allows for linking all of the actions on that row together so a full solution is provided that allows for optional entering of data into any cell of a table.

Updating the Oracle Accelerator •

Patching – Identify Forms affected by Oracle form name and version.

•

Forms-to-Components Map Forms-To-Component Map documents the components and Test Cases to Oracle Forms that are impacted. When a patch is applied, the readme can provide information regarding forms affected. Users can proactively review affected components for potential impact.

•

Run the Document Generator

In the Quality Center, Click on the ‘Tools’ drop down list. Then click on ‘Document Generator’. This will generate a word document that can provide information about the Test Cases and components. TurnKey Solutions Corporation Page 69 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Check the following boxes: Document Subject Tree Subject Tests (Under Subject Tree) Click on ‘Subject Tree’ link Under ‘Folders’, choose ‘Selected’ Then choose the modules you want the report generated for by checking the appropriate box.

TurnKey Solutions Corporation Page 70 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Click on ‘Subject Tests’ link Under ‘Tests’, select ‘Selected’. (No need to worry about Filter and Sort) ‘Include Design Steps’ should be checked. ‘Design Steps Layout’ should be checked. ‘Include Test Scripts’ should be checked. All other boxes should be unchecked.

TurnKey Solutions Corporation Page 71 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Click on ‘Full Document’ button. (Note: Word and all Word documents must be closed before the generator will run.)

You can print , Save the newly created Word Document.

TurnKey Solutions Corporation Page 72 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual •

Delta Analysis

The Delta Analysis process provides the opportunity to determine differences between standard test cases and client requirements. It also highlights areas in the clients system that will require modifications to the scripts for the automation to be successful. 1. Run the Document Generator – See Above 2. Perform Manual Testing based on automation testing of base test scripts This step entails running through the scripts manually to verify that the scripts match the requirements of the applications. If a form on the client system has been updated, there may be differences requiring modification to the automation scripts. • • •

Identify each issue in the Delta Analysis Tracking Spreadsheet. During testing, verify that the values being pulled in DataLoadManager sheet. Document changes on the word document you created from the Quality Center. After completing the testing, work with the Automater to resolve script issues.

3. Confirm that scripts meet client process The client has the opportunity to verify that the standard process matches their internal process. Any differences discovered, will be documented in the Delta Analysis Tracking Spreadsheet. • • • •

Discuss overall process and automation objectives with client. Gather information on clients non standard process (i.e. how they use either customizations or anything funky in the system). Provide documentation from the Document Generator for client to review processes. Jointly review and gather feedback. Complete Delta Analysis Tracking Document. Review with client.

4. Collaborate with the Automaters to resolve issues 5. Verify Updates Verify jointly with client to test and approve resolutions that the updates work and match the client processes.

TurnKey Solutions Corporation Page 73 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal

Functional Reference Manual

Appendix: Templates Use these blank templates for the description for Test Cases and Components: Test Case Description: Pre-Conditions: Post-Conditions: Data In: Data Out: Start Point: Stop Point: Components Description: Pre-Conditions: Post-Conditions: Start Point: Stop Point: Steps: 1)

TurnKey Solutions Corporation Page 74 of 74

Copyright © TurnKey Solutions 2006

Classification: Polaris internal