Friday, 10 March 2023
Setting up the right test data is vital to any performance testing project, particularly with student records systems. We work with a range of applications, including Tribal SITS, Ellucian Banner, SAP Student Lifecycle and others. There are some key factors we look at before any test which enable us to be clear on our requirements:
- The amount of data needed.
- The state of record types for each user journey
- Anonymisation / Prerequisite data generation
- Backup and restore arrangements.
Amount of Data
The amount of data needed for each test is calculated by looking at each user journey (for example, Module Registration) within the scope of testing. This is closely linked to the test profile, and the time each user will typically take to complete it (a transaction). This is worked out by asking the University to specify, for each user journey, the following information for a snapshot of an hour in time for both normal and peak load:
- Number of times each user journey is typically completed over the hour
- How many concurrent users would be expected at any one time, normal and peak
- How long should each journey take, providing a minimum and maximum time?
Once these key variables are known, the next step is to map these to the type and duration of tests planned. Each test will have an associated level of concurrent usage, a duration, and a profile, which could include a slow/rapid ramp-up, spikes or a steadily increasing load, depending on the test’s aim. For example, when testing auto-scaling environments, spikes in usage are needed to ensure the system behaves consistently while the environment is being scaled while measuring whether it scales quickly enough.
These numbers are key for the planning performance test but vital when it comes to letting data teams know how many records of each type will be needed.
Another important factor is the state of each set of records, normally categorised by user journey. Using the example of Module Registration above, records need to be in a state where each student is ready to select their options – once this has been done for a record, it often can’t be repeated - so there need to be sufficient records available for the total number of transactions expected within each test. This is cumulative across the complete suite of tests and can quickly add up and cause issues where re-tests are needed, which makes backing up the data worth considering.
Anonymisation / Data Generation and Manipulation / Data (Records) Load
Often the easiest way of obtaining life-like data for tests is to get it from production, which obviously means it cannot be used by any third parties or in tests, so it will need to be anonymised. Prolifics have our own Test Data Management solution for this purpose – TIDIUM, which we can use to quickly remove sensitive data for datasets before they are used in our tests. If using production data is not possible, or there are gaps where new data is needed, data can be generated. Our team can use performance testing or test automation tools to generate this data or modify the status of records prior to tests being run.
Backup / Restore
Once the data has been specified and put in place in the target environment, it should be backed up prior to the start of testing. A significant amount of work has often gone into getting all the records in place, in the correct state, before the commencement of any tests. A restore can then be run as a part of the setup and environment validation for each test or suite of tests – so that the same baseline is used each time.
How can we help you?
At Prolifics Testing, we have a dedicated team of performance testing consultants who can scope out your requirements and work with you to achieve your performance goals. We have been working extensively with various UK universities providing strategic QA consultancy for various student management systems.
Click here to connect with one of our experts to build an effective Performance Testing approach that can address challenges within your student journey transformation.
Jon Binks - Head of Delivery