1. Bulk Data Loading with WinRunner Manual Testing and Patch Control Tips
Lynne Paulus
Oracle Applications DBA
Fair Isaac
November 16, 2018

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

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

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

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

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

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

8. Manual Testing and Patch Controls
November 16, 2018

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

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

11. Maintain Manual Patch Application Log (cont)
Patch Application Log is Key Patch Tracking Tool
Start new Log when go to new point release
Our log had 171 patch entries
Our current 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

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

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

14. 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 sent each time Service Request changes owner
Test to confirm NOT sent when other fields change.

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

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

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