Test data management is the new big challenge we face in software development and quality. It is important that test data is highly available and easy to refresh to improve the time to market of your software. Another reason why test data is a challenge is are the new legislations like the GDPR. So how do you want to manage test data? How do you want test data to be managed?
There are multiple reasons why you want to start with test data management. There are two mostly heard reasons:
With the right way of managing test data you are able derive these data related test cases, mask these and thus create a better go-to-market strategy for you projects.
The second reason why test data is getting more important is going to market faster. Nowadays is sometimes takes up to almost 5-7 working days before a test database is refreshed! In the fast software delivery development of today that should be unacceptable. And to make things even worse, it takes more than 3 persons for the same refreshment. So there is a lot of time wasted during your fast software delivery pipeline.
So getting in control of your test data reducing the time for the refreshment, getting test data aligned with project is critical for success.
It is important that it is becomes easy to deploy test data to different environments. In the current state of your ‘test data management’ you probably go to a database administrator and ask if a refreshment of the database can be arranged. But the database administrator is bust and don’t really have the time or want to make the time to refresh your test environment. So already the first time is wasted.
So as a software development team you want to manage your refreshment, your test cases directly or via a test data management team. You want a self-service portal for refreshing the test environments.
What’s also troublesome is that there aren’t enough database available for the number of teams. So what happens is that multiple teams or people are working in the same database.
Software quality engineers are all searching for the same test cases and executing tests to the system. And during the execution of the tests the problems occur, a colleague already used the same
test case and the test data is already manipulated. The test case became useless and you the searching starts all over again. Again time is wasted to finding right test cases and test data.
So in this case you want test data to be easily refreshed so you are able to use your selected test case and if you had your own test database? This last part can be achieved when you start test data subsetting. Creating smaller sized test databases gives you the ability to have multiple environments. Teams don’t need a 100% full copy of a production database, they need only the important testcases, the need at least the 15% data related issues as test data. In that case you are able to create really small test database. These are easily deployable, have a high availalibity and are easy to refresh.
So test data management is a lot, it is masking, deploying, synthetic test data and subsetting! And all in all it should be able to be automated.