Fiscal year rollover testing
Testing environment
FOLIO: Performance testing environment (speak to Martin and the PTF team)
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 users: 2
- 2 Fiscal year
- 2 ledgers
- Number of Budgets being rolled over 200
- 50 expense classes, 5 inactive
- Number of order lines being rolled over 50,000
- Number of orders being renewed 30,000
- Number of transactions 100,000 (Average of 2 Fund distributions per order line)
- POL limit 50
- Number of invoices related to orders 20,000
- Number of invoice lines 30,000
Dataset:
- Create a test data set of 50,000 open order line: 20,000 One-time, 15,000 Ongoing, 15,000 Ongoing-subscription
- Create 40,000 closed orders in system
- Majority of orders should have encumbrance transactions. At least 1000 orders should not have Fund codes or encumbrance transactions
- Single Fiscal year series
- 2 ledgers
- 2 Groups
- 200 Funds, 20 inactive with no budgets
- 50 Expense classes
- 100,000 encumbrances
- 40,000 payments
- 100 orders must have one fund from each ledger
Test approach:
- Load orders into FOLIO environment
- Open orders
- Load invoices
- Approve and pay invoices
- Close some orders
- Rollover ledger 1
- Rollover ledger 2 (Run both rollovers at the same time)
Processed and updated NFR:
This is a data set for 2 parallell rollovers, so each number should be devided by 2 to get number for 1 FY rollover.
Item | Quantity | Additional | Comments |
Fiscal year | 4 | 1 base year, 1 rollover year | |
Ledger | 2 | ||
Fund | 200 | reuse each fund for multiple orders | |
Budget | 200 | ||
Expense class | 200 | active + 10% inactive | Are added to the budget and the order. Inactive can’t be used in orders. |
Order | 100 000 | 50 000 - open 50 000 - closed
| Closed - only One-time. |
Order line | 200 000 | 2 order lines per each order + 1-2 order with 200 lines | |
Transaction (encumbrances) | 400 000 | 2 for each order line | |
POL limit | 200 | ||
Invoice | - | No influence on performance | |
Invoice line | - | No influence on performance |