TurnKey Solutions

Quality Center 8.
2 Functional Reference Manual

Oracle 11.5.10
Prepared for:
Date: November, 2006
TurnKey Solutions Corp.

info@turnkeysolutions.com
621 17th Street, Suite 1131
Denver, CO 80293
TurnKey Solutions Corporation Confidential

Do Not Distribute
Page 1 of 74 Copyright © TurnKey Solutions 2006
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 22
Select the Component Tree Folder and the Component 22
Move the Component to the Component Tree 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: 41
Input/Output Data: 42
Linking Data Between WorkSheets 42
LoadData Function......................................................................................................................................43
Auto-Spreadsheet Creation.........................................................................................................................43
Iterations.........................................................................................................................................................46
Method 1A – Iterating Component(s) within a Test Case 47
Method 1B – Iterating a Group of Components within a Test Case 49
Method 2 – Iterating a Test Case with Different Data Scenarios 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

Classification: Polaris internal
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.

Quality Center Functionality
• Requirements – Not used with Accelerators

• 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 non-
divisable 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.
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.

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

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

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.

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.

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.

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.

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.

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

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.

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)

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.

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.

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.

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.

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:

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.

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.

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.

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.

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.

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.

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.

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 on the upper right hand side of the Test Script
tab.
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.

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.

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

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.

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.

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.

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.

Select ‘<New Runtime Parameter>’ 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’.

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.

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 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: Auto-
Spreadsheet 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.
1. 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.

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.

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.

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<Date/Time>.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.

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.

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.

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.
<Not Iterated Component> <Iterated Component> <Not Iterated Component>
2 Single iterated components. (for iterating one component x times then the next y times)
<Not Iterated Component> <Iterated Component> <Iterated Component>
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.

<Iterated Group>
<Not Iterated Component> <Iterated Component> <Iterated Component>

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.
1
2

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

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’
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

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.

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 Run-
Time Parameter section above for more information.

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.

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.
case. (Open Destination Window)
7. Run DESTINATION and enter “2” in the ‘Quantity’.
8. End Group Iteration 1
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.
17. Run PO LINES and Enter “2” in the ‘Num’ field.
case. (Open Shipments Window)
24. SKIP PO LINES
26. SKIP SHIPMENTS
31. SKIP PO LINES.
32. SKIP Common Button.
38. SKIP PO LINES
40. SKIP SHIPMENTS
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
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 icon on the QuickTest toolbar or
select: Tools->Object Repository from the menu
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.

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 icon or

select: Tools > Object Repository from the menu
2. 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 toolbar or select: Tools->Object Spy
on the menu
2. Select the pointing hand button
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

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:

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

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.)
3. Open the Object Repository by selecting the icon or select: Tools > Object
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.

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 3-
d 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.

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.

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.

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.

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

1. 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.
2. Step 2 selects the tab in the form window where the table is located.
3. 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.
4. 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.
5. 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”.
6. 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
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.

1. 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.
2. 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”.
3. Step 3 will enter the “Credit” input parameter value into the “Credit” column for the
row that was output for Step 2.
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. 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.
2. 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”.
3. Step 3 will enter the “Credit” input parameter value into the “Credit” column for the
row that was output for Step 2.
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
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.
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.

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.

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.

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

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

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TurnKey Solutions

Uploaded by

Copyright:

Available Formats

Quality Center 8.

2 Functional Reference Manual

TurnKey Solutions Corp.

TurnKey Solutions Corporation Confidential

TurnKey Solutions Corporation

Test Plan (Case)

Test Lab (Set)

QuickTest Pro (QTP)

Quality Center (QC)

Subject Matter Expert (SME)

TurnKey Solutions Corporation

Quality Center Functionality

• Requirements – Not used with Accelerators

TurnKey Solutions Corporation

• Defects – Not Used with Accelerators.

Lowest Level is Business Component (Component). This is where the

• Test Plan (Case)

A Test Plan (Case) is by Definition is a piece of functionality. It is comprised of 1

• Test Lab (Set)

A Test Lab (Set) is by Definition is more of an end to end flow. It is comprised of

Test Plan (Case)

TurnKey Solutions Corporation

TurnKey Solutions Corporation

6. Test Case Naming Convention

7. Detail Standards and Template

Description: Enter a description for Test Case. Be as descriptive as possible, the

TurnKey Solutions Corporation

Test Case Example

TurnKey Solutions Corporation

Components for Test Cases

Return to Navigator Forms

TurnKey Solutions Corporation

Adding Components to a Test Case

TurnKey Solutions Corporation

TurnKey Solutions Corporation

7. The Diskette icon will save your work.

10. Click on the ‘Attachments’ tab.

Review Common Components

Button_Label – The name of the button. i.e. ‘New Journal’.

Select Menu Item

Return to Navigator Forms

TurnKey Solutions Corporation

Review Common Test Cases

STD Report Template

TurnKey Solutions Corporation

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)

4. Click on the New Components Icon (green puzzle piece icon)

TurnKey Solutions Corporation

5. Component Naming Convention

Steps: Enter the detailed steps required to accomplish this component.

1) Verify that the 'Journals' window is open.

TurnKey Solutions Corporation

10. Component Status

• Parameter name should represent the Oracle field name

TurnKey Solutions Corporation

Creating a Component from the Test Case

TurnKey Solutions Corporation

Go to the Component Requests Window

Select the Component Tree Folder and the Component

TurnKey Solutions Corporation

Move the Component to the Component Tree