A test environment plays a crucial role in software testing. It provides a controlled environment in which tests can be performed to verify the quality and functionality of an application. The following article describes how the increasing CI/CD processes (Continuous Integration / Continuous Development) affect the functions and requirements of a test environment.

Test environment and test case data

We speak of a test environment when it contains the entire technological scope for one or more applications, just as it is in production. In a common enterprise application, a test environment typically looks like this see Fig. 1): We have the persistence layer as a database, one or more service or application layers on top of it and a graphical user interface (GUI) in the front end. The test environment is therefore not a complete mock-up, but an image of the actual situation resp. production.

The same applies to the data. In the production environment, these can be stored in different databases and in different formats, depending on the application. For example, there may be multi-tier applications that access data in different databases. At the same time, there may be small applications whose data resides in a single database.

To get realistic test cases for our test environment, the individual components of the data sets must be extracted from the various storage locations and merged. If we consider an application whose data is located in several tables, it means that these tables are related in some way. The data of a test case can now be thought of as one or more rows in several of these tables (see Fig 2).

Example: A car insurance policy

Fig. 2 shows the different tables and rows where the record of a specific insurance customer is located. For example, the various rows on the left store the details of the car insurance policy. And these are related to the policyholder’s basic data (on the right), which in turn is linked to the policyholder’s detailed personal data. To get a meaningful test data case, all this data must be drawn from the individual rows without resolving their relations. The resulting test case data can then be transported into the test environment.

So, there are always some relations between the data in database 1 and the data in database 2 (see Fig. 1) etc. No matter what the combination is: These relations must be provided consistently across the different databases in the test environment.

This is the only way to perform meaningful and realistic tests. And only in this way does one obtain the correct data from the underlying databases via the user interface. These contexts form the requirements for all test environments.

Static and dynamic test environments

Now let us distinguish the two types of test environments: static vs. dynamic test environments.

The static test environment is typically widespread. It is permanently available, has a static URL on the intranet and a fixed structure. All previous application versions were usually implemented there incrementally. It is used for linear development of applications from version “1” to version “n”. In other words, all release versions in production previously passed through this static test environment.

In addition to the static test environment, there is also a dynamic test environment that better meets the needs of today’s CI/CD. This continuous development and implementation no longer imply the complete revision and linear update of a complete application. Rather, individual components are constantly developed further and continuously go live.

And because of this development, the dynamic test environment is becoming more and more important. It is created ad hoc as needed by a continuous integration and development process.

For example, we want to test a new upgrade of Service 2 (see Fig. 1). To do this, we create an environment in which Service 1 and Service 3 are started in their current production versions – i.e., unchanged. At the same time, we start the new version of Service 2. Thus, we have created a dynamic environment in which we can test the integration of the new Service 2 in the context of the current production status.

This dynamic approach poses completely different requirements for the test environment as well as for the procurement of test data or test case data. To test individual components in such an integration test in a dynamic test environment, fine-grained and highly consistent test case data is required. This stands in contrast to a large-scale release test, which works with mass data.

To sum it up:

In most companies, there are static test environments. Examples include a production environment, some kind of pre-production or release test environment, an integration test environment, some kind of development environment. Due to the increase in CI/CD processes, these static test environments must now be complemented by dynamic test environments. These are created ad hoc and exist for a short time when a server upgrade or a new application object is launched.

This is something that many of our customers are setting up right now. And our test data management software XDM fully supports these applications and requirements.