Panel Winrunner And Testing

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  Technical  Re-use

users prepare the spreadsheets

users design the WinRunner logic

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

Dataloader Advantages

Advantages



Free



Logic can be incorporated



Easy to develop



Avoids babysitting



Works without problems across environments



Predictable



Can read/write files

Disadvantages 

Some functionality is positionbased



Lacks Programming capabilities



Needs babysitting



Unpredictable

Copyright © 2003 Fair Isaac Corporation. All rights reserved.

Disadvantages 

May require programming



Problems can occur across versions (window names change)



$$$

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(“”)



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  If

scope of patch (how many files changed, etc)

broken data, indicate whether includes data fix or just code fix

 Recommends  Works  Pulls 

with one functional Business Analyst (BA) at minimum

in more groups if patch has broader impact

BA’s and Functional users test patch  sign



extent of testing based on patch contents

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 nonforeign 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  Small,

Refresh from Production

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

1,600 bug fixes were applied

Patch 

over 100 patch drivers

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