In order to request access to the service and accompanying tools, please go to the SALT Registry Application. You will be asked to provide information about yourself. After saving this information you will be able to describe your project and request testing resources.

• Testing Software

  • Empirix e-Tester -- This is a tool which aids in the automated functional and regression testing of applications to ensure functionality of the user interface.
  • Empirix e-Load -- This is a tool which aids in testing the ability of an application to perform under varying levels of simulated-user load.
  • Empirix e-Manager -- This is a tool which aids in the management of test cases, ensuring specific tests are performed, what issues were raised by them, as well as initiating load tests.

• DoIT Testing Knowledgebase

  • This is a University / DoIT specific knowledgebase of procedures, tips and tricks relating to testing University Systems
  • https://wiki.doit.wisc.edu/confluence/display/SALT/Home

• Consultation

  • Regression / Function -- An expert is available to help you plan, build and execute regression/functional tests
  • Load -- An expert is available to help you plan, build and run load tests
  • Test Management -- An expert is available to help you plan for, execute and understand the results of your application testing cycles.

• Educational Opportunities

  • Empirix-led Consultation on Empirix Software
  • SALT-led basic introduction to the use of the Empirix Suite **Under Construction**
  • SALT-led testing management workshop. **Under Construction**

• Responsibilities

  The tools, education and consultation offered by the SALT team exist to facilitate quality application development and implementation. The final functionality and usability of an application rests on the developers and management of a given project.

• Service and Tool Availability

  As SALT services and tools are shared by all of DoIT, a project's use of the tools and services are subject to availability restrictions. Application testing should be a well thought out and carefully planned process. To ensure timely assistance and tool availability, contact between SALT team members and project management needs to occur early and frequently in the project life-cycle.

• Rules for appropriate use of tools

  The Empirx software, including the eTester download, is available to users who are testing for UW-Madison applications and UW-System applications that are hosted and managed at UW-Madison. All other uses are prohibited under the current licensing.

• Tool Reservation

  In development

• Rules for appropriate use of test data

  1. Follow the Guidelines for Appropriate Use of University of Wisconsin-Madison Information Technology Resources.
  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. e-Tester 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 Empirix components

  e-Manager

  1. Restricted data should not be stored in an e-Manager project 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 e-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 e-Manager.

  e-Tester

  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 (e-Manager or e-Load) as those data files can be seen by others.

  e-Load

  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.