Test data management (TDM) is the process of managing the data that is required to fulfill the test requirements with as little human intervention as possible.
So test data, which is basically a set of documents and their attributes, needs to be created automatically in regards to the test scenario and requirements, but also with a high quality. Poor quality data might turn out to be even worse than no data because the test results will be blurred and cannot be trusted.
For (automated) testing the data must be provided, accessible and up to date whenever it is needed: on demand or on a time-scheduled basis.
In short, test data management means to recreate updated test data with high quality (realistic and representative) when it is needed.
Often data is generated in the test system just once, e. g. so that a developer can start to develop or test an application, but that does not really merit the term TDM.
TDM comes into play when test data needs to be created or updated regularly. In those scenarios, when the requirements call for up-to-date information, the test data needs to be created continually.
Typically, creating test data means to extract/copy a specific scope of content and attributes from the production system into the test system(s). That could be deployment stages like DEV / STAGE / UAT / TEST.
A simple example: Every 3 months 30 % of the content in the product system will be recreated 1:1 in the STAGE system. Every 6 months 5 % of the content will be recreated in the DEV system.
The basic scenario is the basic process. Test data resembles (almost) up-to-date real data. It ensures the availability and quality of the data at the given times.
Depending on the requirements, which are quite different across industries and the usage of the corresponding platforms, it could be necessary to tailor the test data in specific ways.
The content-less scenario may have the same requirements in terms of time and scope of documents but the content files should not be recreated. That means that the test system shows the documents and their attributes but not the actual content file.
Either it is simply not necessary to also have the content file for the tests or it is strictly forbidden e.g. the test or dev system allows access for more or other people than the productive system and confidential content is involved.
In other cases, the document’s attributes must be concealed or blackened for the same reasons (confidential, security) or in general the test data should be created in a tailored scenario. Here the test data contains only the necessary subset of original information and certain values can be disguised.
Some companies are already using migration-center for the test data management. It supports all of the mentioned features: time-based schedule, specifying scope of documents, manipulation of metadata and the delta/update mechanism.
The configuration in migration-center for creating test data is very similar to the configuration for a migration. The only addition is a scheduler to execute the configuration time based, regularly, and a specific rules-set to meet all the requirements for the testing.
Once the configuration is made accordingly it is easy to keep the test data up-to-date automatically in the background.
From my experience not many projects make use of real and automated test data management. In many projects the creation of test data is a manual process and sometimes that is good enough. On the other hand, once you have seen the beauty of automation you will never want to go back to the manual process.
Also, not all of you might know that migration-center can be used for test data management. Therefore, if you use or used migration-center for a content migration – why not give it a try?
Maybe the upcoming holiday season is a good time to start looking into it. You can let migration-center automatically create test data over the Christmas holidays to have it ready for the new year.
Reach out to us if you have any questions, suggestions, need help or want to see a live demo.