Operational Protocols for Using Oracle ATS Software at UW-Madison

Rules for responsible use of test data

1. Follow the UW-Madison Responsible Use of Information Technology Policy.
2. Protect the privacy and confidentiality of student, patient, employee and other institutional information, as required for example by FERPA (privacy of student information), and HIPAA (privacy of patient information).
3. Comply with all other applicable University policies, State and Federal laws, including for example: Copyright Law and the Student Code of Conduct Policies & Procedures.
4. Test data should never reside in PRODUCTION databases.
5. Production data should never reside in TEST databases.
6. The SALT team should be notified if either rules 4 or 5 cannot be accommodated. We will assist you with crafting test data.
7. Oracle ATS Functional Testing scripts contain the passwords used in creating the script . This can be hidden from the application, but if a person opens the actual script, passwords can be viewed. It is your responsibility to use unique passwords between production and test in order to assure that your production password isn’t exposed. If you have an application that uses WEB-ISO you can change your WEB-ISO password at Integrated Testing - NetID Account Modification.

Data Security considerations for Oracle ATS components

Oracle ATS Test Manager

1. Restricted data should not be stored in a Test Manager project unless it has undergone data sanitization or unless the following provisions are set:
   • Restrict the access to only those folks approved to see this data
   • Do not configure email notification for this project. If you need to do this, contact the SALT Team.
2. Restricted Data is defined by Security Restricted Data Security Standards.
3. If you have test cases with restricted data and others without, put those with restricted data into one project (XXX_restricted) and the rest of the test cases into another (XXX). Then you can control the access and emailing for these test cases separately. Contact the SALT team if using production data.
4. Anytime you want to upload a script into Test Manager, you need to make sure it will not overwrite someone else’s script. To accomplish this:
   • Open up the script and select save-as
   • Pre-pend the name of your project onto the original name of the script. So if the script was logon, it would become XXX_logon. Save it as an EME package. It is that package that you upload to Test Manager.

Oracle ATS Functional Testing and OpenScript

1. Passwords should be hidden. {Can’t encrypt them right now – but hide them for now}
2. Databank files that have restricted data should not be uploaded to shared systems (Test Manager or Load Testing) as those data files can be seen by others.

Oracle ATS Load Testing

1. Do not run load tests in a production environment. Run load tests on the environment designated for this activity. TEST or QA are the most common environments for running load tests.
2. Your TEST or QA environment should be as close as possible in computing power, memory, and configuration to your production environment. If your test bed is significantly different from your production site, load testing will have less than accurate results making decision-making difficult.
3. You need to understand the impact your load test might have on shared systems. Some questions to ask are:
   • Does your application use WEB-ISO, IAA_AuthHub or LDAP?
   • Does your application use a shared database (such as ISTST)?
   • Will your application be run over a long period of time and therefore provide a sustained load on the network?
   • Will your application monopolize the CPU cycles on a shared server?
4. For those systems where you might have an impact you need to know the contact people to notify. (This may be individuals – but preferably it is a group email address)
5. If you will be impacting shared systems with your load test, then create a Service Desk Record, using the type “Load Test”. Be sure to add affected system administrators to the notification email. If you need assistance creating this record, contact the SALT Team.
6. If you will be running a scheduled load test after hours, then you must do the following:
   • Record your scheduled load test and time in WiscCal Resource, DOIT eLoad.
   • Create a service desk record and on that record include a phone number of someone who can be called to kill a load test if needed.
7. If you will be running a soak test (test that provides a moderate load over a long period of time – used to find memory leaks) and your application uses WEB-ISO then you should notify help@login.wisc.edu and notify them of the planned load test, and give them the IP address from which you are running the load test. They are monitoring for suspicious activity, so you don’t want your IP address flagged as suspicious. For more information see Suspicious Activity Monitoring for UW WebISO.