Bulk Data Loading with WinRunner

Manual Testing and Patch Control Tips

Lynne Paulus
Oracle Applications DBA
Fair Isaac

October 23, 2008

Fair Isaac and Oracle Apps
 Fair Isaac: Decision Support Software, approx 2,500 emp
 Bay Area = San Rafael
 San Diego, Minnesota and many other locations
 Live since 1992
 Currently on 11.5.8
 Modules = Fincls, Projects, HR, OM, and recently CRM
 Soon to implement OTL and iExpense
 Approx 1100 users have logins to 11i
 About 120 users logged in concurrently

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 2
Bulk Data Loading with WinRunner
 What is WinRunner?
 Automated testing tool from Mercury Interactive for Microsoft
Windows applications.
 With Ad-ons: can use WinRunner with Oracle applications
 How Do We Use It?
 As a Dataloader for bulk data loads
 Used almost weekly
 Future Uses of WinRunner at Fair Isaac
 Build automated testing scripts

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 3
WinRunner and Oracle
 WinRunner uses a Java add-on to work with Oracle
 Use cgi web address with the following parameters…
Application=PMS&record=names

Example cgi web address for test…

http://box1.oracle.com:8000/dev60cgi/f60cgi?Application=PMS&record=names

 Examples of Bulk Loads we’ve done with WinRunner:

Adding 11i Users and assign responsibilities (high volume
when new module implementation)
Fixed Assets
Product re-orgs
Alternative to writing data conversion programs
Copyright © 2003 Fair Isaac Corporation. All rights
reserved. 4
WinRunner as a Bulk loader

 WinRunner takes data from spreadsheet (data table) into Oracle

 Non-Technical users prepare the spreadsheets
 Technical users design the WinRunner logic
 Re-use of prior WinRunner logic is common
 Learning curve of technical was not too difficult

 Speed depends on how many forms and entries the WinRunner

has to make
 Speed also depends on the number of rows in data table
About as fast as ‘Dataloader’ (freeware)

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 5
WinRunner vs. ‘Dataloader’
Dataloader WinRunner
Advantages Advantages
 Free  Logic can be incorporated
 Easy to develop  Avoids babysitting
 Works without problems across  Predictable
environments  Can read/write files
Disadvantages
Disadvantages
 Some functionality is position-  May require programming
based
 Problems can occur across
 Lacks Programming capabilities
versions (window names change)
 Needs babysitting  $$$
 Unpredictable

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 6
WinRunner Tips/Quirks
 Always open WinRunner before opening program being tested
 Always use Oracles cgi address with following parameters…
Application=PMS&record=names
 WinRunner begins recording when press “F2” key,
 While recording, “F11” key can not be used to begin query in
Oracle. Must code, - type(“<kf11>”)
 Data Table file can not be opened anywhere but WinRunner while
running WinRunner
 When hitting record button twice WinRunner records in “Analogue”
mode
 Ctrl + F3 stops a WinRunner script
 Mercury Interactive Support is very helpful
Copyright © 2003 Fair Isaac Corporation. All rights
reserved. 7
Manual Testing and Patch Controls

October 23, 2008

Maintain Manual Patch Tracking Log
 Need high level Patch Tracking Method
 Use of Patch Track Log
 We use Excel spread sheet to track patch applications
 Shows everything you need to know about a patch at a glance
 DBA’s maintain the Patch Tracking Log
 Gives overview of patches still in process, which in same
environment
 Doesn’t include all the patches that were rolled into each patch, just
the patches we took an action to apply
 Use OAM to see all ‘installed’ patches
Shows install date and which machines installed on

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 9
Maintain Manual Patch Tracking Log (cont)

 Patch Characteristics to Track:

 Application Short Name, Patch download date, Install date in
each environments, Description, comments, Time takes to
install, Tech Stack Chg?, Pre-req for other patch, Problems
encountered AND date installed into Production
 Some Tracked data in ad tables but not most
 We track ‘Change Request’ Number, cross-ref to System with
functional or technical reasons why we’re patching, who’s signed
off, etc.
 Column for each 11i environment (except Vision)
Revise environment column, when refresh an environment,
remove patch application date since patch install now lost

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 10
Maintain Manual Patch Application Log (cont)

 Patch Application Log is Key Patch Tracking Tool

 Start new Log when go to new point release
Our 11.5.4 log had 171 patch entries
Our current 11.5.8 Log has 183 patch entries so far
 Include RDBMS and other Tech Stack patches in this log
 We use hardcopy of Patch ‘readme’ file as ‘cookbook’ of details
how and where patch installed
 Make grid to right of each patch driver name with instance name,
date, box, time, plus any extra steps needed (e.g. Compile Apps
Schema) and problems encountered

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 11
Testing Environment

 Best if Test environment recent clone from Production

 We have 5 non-production environments that we refresh from
Production using Rapid Clone
 Two environments also tied to other non-Prod environments
(ADP, Time and Expense System)
 Our Refresh takes about 4 hours and is exact copy of Production
 Best to apply one patch at a time but no always feasible
 Use Patch Tracking Tool to gauge impact of a refresh
How many patch installs in environment will you lose due to
refresh and how much time did they take to apply

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 12
Patch Installation Procedures and Testing

 Tech person applies patch into non-Prod environment.

 Determines scope of patch (how many files changed, etc)
 If broken data, indicate whether includes data fix or just code fix
 Recommends extent of testing based on patch contents
 Works with one functional Business Analyst (BA) at minimum
 Pulls in more groups if patch has broader impact
 BA’s and Functional users test patch
 sign off to allow Production install
 Requires close coordination between Functional and Technical
Staff
 Tech Staff must feel ownership to determine scope

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 13
Patch Testing
 May be minimal if very small change
 Most frequent changes we see are packages and seed data
 Protect against ‘introduced bugs’:
 Always test a little broader than bug, e.g. if testing foreign
currency Oracle Projects invoice generation, also test non-
foreign currency invoice generation.
 Test ‘negative cases’:
 Want email sent each time Service Request changes owner
 Test to confirm email NOT sent when other fields change.

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 14
Patch Testing (cont)

 Good Patch Tracking will aid Problem Analysis

 We had problem in a Test environment where each time a user
closed a screen, they got an error
 Two things had changed:
 Recent Refresh from Production
 Small, one-off patch to make an OM screen view only
 The one-off patch introduced the bug. Affected all users, not just
OM
 Required apply much larger patch, affecting more applications to fix
the introduced bug
 Larger patch should have been pre-req of the one-off

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 15
Patch Magnitude

 Can check ad tables to see magnitude of patches applied

 Before and after large patching effort do count of rows in ad tables
 Good way to translate the scope of change to upper mgmt
 For our recent CRM testing, based on ad tables I could tell:
Applied 55 patches (55 entries in our Patch Tracking Log)
Submitted over 100 patch drivers
Over 1,600 bug fixes were applied
Patch drivers took over 82,000 bug fix actions
 Helps explain why it took so long and why down NN hours.

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 16
Conclusion

 Develop high level doc to track patch application

 Patching requires tight cooperation between technical and
functional
 Functional users have no way of knowing how much changed
due to a patch
 Technical user should take lead on setting testing scope
expectations but not the testing details
 Large Family Pack or Mini-Pack needs broad testing

Copyright © 2003 Fair Isaac Corporation. All rights

reserved. 17