Software quality assurance is more dependent on test data than we all would like. You can’t escape it anymore: you need to do something with test data management. Why? Because without proper test data management you lose valuable time that is already scarce.
Author: Nynke Hogeveen, DATPROF, https://www.datprof.com/
Waiting times for a test data refresh are long; on average QA teams have to wait 6 days before they have their refreshed test set. Another problem that arises in the absence of test data management is that in many organizations multiple teams are working on the same test database. One team makes adjustments to the data which often results in corrupted test data for the other team. And let’s not forget about privacy sensitive data, which is still used (unprotected) far too often. Although it is clear that it is not allowed to use personally identifiable information for testing purposes, many organizations fail to do anything about data protection. It is time to turn things around. Let’s tackle the test data issues so it can work to our advantage, instead of against us.
Data protection
The first step is to make sure there’s no personally identifiable information in your test environments. There are different ways to do this. You can copy and mask your production data with the help of a data masking tool like DATPROF Privacy. With the help of built-in masking rules and synthetic data generators you create a test dataset with reliable and recognizable data that doesn’t lead to a natural person. Having production-like test data is essential in software quality assurance. When your application works with test data that’s very similar to production, you may assume that it will work flawlessly in production too. Testing a new system that has no data in it yet? Then you can generate data from scratch to fill this new database. Of course, this data is compliant by default since it’s fake data.
Every team their own test dataset
One of the biggest bottlenecks in quality assurance is the size of a test database. In general we see that a copy of production is made for testing, just to be sure every edge case is covered. But giving every test team a copy of their own causes storage capacity problems quickly. So in many cases multiple teams are obliged to working with the same test database. It is no exception that data is adjusted by one team as a result of which the data is not usable anymore for the other teams. The solution here is make functional and technical intact subsets, one for every team. Containing just those cases that you need for testing, nothing more, nothing less.
Automate the provision of test data
A request for a (masked or subsetted) test data refresh can take up to days or even weeks in the old fashioned way. A team needs a test data set, they make their request at the database administrator (DBA). He/she sometimes needs approval from the IT manager. For the DBA and the IT manager it’s not a part of their normal job duties so it is often not a priority. This results in long waiting times and lots of frustration. By automating the provision of test data, DBA’s are left alone and testers can get to work quickly and happily.
Conclusion
It is essential to have a grip on your test data. Know what’s in there and be sure privacy sensitive information is protected. Subsets enable you to give every test team their own dataset. And when teams can refresh their own dataset, test data won’t hold back your software quality processes anymore – it will accelerate them instead!
About the Author
Nynke Hogeveen works for DATPROF, a leading Test Data Management solutions provider. By sharing knowledge and offering the right tools she wants to make Test Data Management more accessible to every organization. The main goal is to simplify getting the right test data in the right place at the right time.