Best-Practice: Test data procurement
in the context of continuous software development (PART 1/3)

Due to the massive increase in data-driven business models (from data-enhanced to pure data-driven business models), IT, and, in particular, software development play a central role in the provisioning of products and thus in business success. The relevant software must be regularly adapted to the changing requirements of the market and kept up to date with the latest technology. Therefore, continuous development has become a permanent task.

If a lot of software is developed, a lot must be tested, because no software should be used without being tested first. UBS Hainer is focused on this area of software testing, specializing in tools for the procurement of test data. The following is an overview of best practice with regard to obtaining optimized test data for software testing.

PART 1 – Pre-Production as the basis for test data procurement

Baseline: Release management determines the schedule and guidelines by which productive applications are further developed, improved or adapted to new requirements. Today, this is a continuous development process. 

Of course, every change to an application must be tested. And this is not done in the live production, but in a test environment instead. Developers need suitable test data for these tests. In practice, when several developers share a test environment and use the same test data, this can quickly lead to problems.

The mutual influence of tests and the corruption and falsification of test data can lead to ineffective and unsuccessful testing. This scenario still exists today in an astonishing number of companies. 

Requirements: The integrity of the test data should not be damaged by parallel use. Otherwise, the quality of the tests suffers. Software testing also needs to ensure that newly added or modified functions do not interfere with or even eliminate existing features.

Therefore, quality assurance requires:

• Realistic data that is as close as possible to production.
• Specific test case data that is suitable for testing the new functions.

How can this challenge be met? Which approach is best practice today?

Pre-production as the basis: The landscape of a production system usually consists of various applications and databases that are often distributed across different platforms and architectures. To ensure that the new release is subsequently able to handle the production data, it is recommended to use a consistent copy of the production system as the basis for the data.

This copy of the real production is usually called pre-production. The critical process of producing a time consistent and technical consistent database can be accomplished by using this pre-production. Pre-production can also represent the separation between anonymized and non-anonymized data in the test data provisioning process. Centralized and consistent masking can be performed at this point before using the data in the test process. 

Fig – The production system (PROD) is copied 1:1. The resulting pre-production (PRE-PROD) provides a realistic data basis for the development environment (DEV) and the tests (TEST).

However, a precondition for realistic data is that this database is replaced frequently with current production data. For example, if it is automatically updated weekly, daily or nightly, it can serve as a data source for all testing and development tasks. All processes associated with this regular updating can be configured and automated.

Conclusion: 

The realistic test data required for continuous testing is obtained by copying the current production and making it available as a database. If this so-called pre-production is regularly updated, applications can be realistically tested at any time without affecting live operation.