Testing environment

FOLIO: Performance testing environment

Limited to single node of mod-data-export-spring

Environment resources should be equivalent to a production environment

Testing type

Required testing type


Load testing	Load testing measures system performance as the workload increases. That workload could mean concurrent users or transactions. The system is monitored to measure response time and system staying power as workload increases. The workload falls within the parameters of normal working conditions.
Stress testing	Unlike load testing, stress testing — also known as fatigue testing — is meant to measure system performance outside of the parameters of normal working conditions. The software is given more users or transactions that can be handled. The goal of stress testing is to measure the software stability. At what point does software fail, and how does the software recover from failure?
Spike testing	Spike testing is a type of stress testing that evaluates software performance when workloads are substantially increased quickly and repeatedly. The workload is beyond normal expectations for short amounts of time.
Endurance testing	Endurance testing — also known as soak testing — is an evaluation of how software performs with a normal workload over an extended amount of time. The goal of endurance testing is to check for system problems such as memory leaks. (A memory leak occurs when a system fails to release discarded memory. The memory leak can impair system performance or cause it to fail.)
Scalability testing	Scalability testing is used to determine if software is effectively handling increasing workloads. This can be determined by gradually adding to the user load or data volume while monitoring system performance. Also, the workload may stay at the same level while resources such as CPUs and memory are changed.
Volume testing	Volume testing determines how efficiently software performs with large projected amounts of data. It is also known as flood testing because the test floods the system with data.

"Normal" condition parameters:

Number of concurrent export jobs: 10
Number of order lines being exported: 10,000
Number of orders: 8,000
POL limit 50
Export job schedule frequency: Monthly (If hourly export drop a 0 from the amount of orders and order lines)

Real world conditions:

There will be variation in the numb er of Jobs an institution will have. Some institution could have 10 or 15 concurrent exports and some institution could have only 1 or 3. It is not dependent on size it depends when they have scheduled the exports. If they schedule everything on the same day and time or they stagger them.

The number of orders will also vary. Some vendors the library will only order a few things from per month and some they may order most things at specific times each year. Meaning there might be 10 orders per exports and then one day there will be 2000 because they send 2 big orders.

Dataset:

Orders must contain all possible data points for EDI export
Some order lines with multiple locations
Some order lines with format = P/E Mix (Two units prices and two quantities on FOLIO side)
At least 1 organization with 2 export configurations
At least one organization using default export flag rather than an account number
Different exports should export to both FTP and SFTP locations

Test approach:

Create organizations and integrations
Load orders data set
Open FOLIO orders
Observe export activity

Results of testing:

Opportunities for improvement:

Browser not supported