Throughout the testing and development phase of a software product, a lot of test data is created and consumed. With the widespread adoption of Agile methodologies in Software development comes multiple and frequent releases. This, in turn, also increases the creation and consumption of more test data during QA and testing services. Developers like to keep databases and stored procedures of test environments in sync with Production. Sync has the threat of exposing end-user data to the test environments thereby increasing the chances of violation of information security.
Following are some of the practices that may be implemented to maintain the integrity of data:
1. Recognize your Sensitive Data
The term ‘sensitive’ may have a different meaning in different domains and geo-locations. However, it is good practice to consider any data from end users as sensitive. As a tester, we should best not use any production data collected from the end-user. For such testing purposes, it is imperative that we create mock or dummy test data.
2. Append or Mask your Data
All data earmarked as sensitive or confidential must be masked or appended or obfuscated in a way such that it abides by Information security standards of its geolocation. However, this process should be done in such a way that the validity of the test data is not hampered. For example, obfuscation of say Zip code should not lead to invalid data being used. Else, the purpose of testing would fail. On top of that, it is a good practice to use appended test data while creation of data.
3. Use Test Management Tools to Record Usage of Data in Test
Test management tools not only help to organize and manage your Test Suites, but also help record and control the usage of test data. Cucumber is one of the most popular BDD (Behaviour Driven Development) tools for test management and it supports test data recording.
4. Regularly Purge Data created for Test
It is a security risk to keep test data and test accounts active after being used. This is most notable in the Production environment. Anyone getting illicit access of these test accounts can exploit the system and worse can expose its vulnerabilities. Test accounts are also more vulnerable to cyber-attacks such as brute-force attack. Therefore, it is always a good practice to regularly purge all test accounts and test data once they are used for testing and are no longer required.
5. Automate Flows of Creation of Test Data
This is in follow-up with the above practice of regularly purging data. Creation of test data should not take up a bulk of a test engineer’s time and creating test data manually definitely does so. This becomes even more acute when you are regularly deleting your test data. Therefore, to save time, extraction and creation of test data should be automated. For running Automated Software Testing scripts, test data should be dynamic and created at run-time. For manual scripts, test data should be extracted or created through API scripts or through SQL stored procedures. This would greatly enhance the efficacy of testing.
It is important to note that above are suggested practices only and it’s not a one-size-fits-all scenario. Some projects may have workflows which would prohibit usage of these practices. In that case, it is necessary to learn the reasoning behind those workflows and what is being done to secure the integrity of test data. At the end of the day, data privacy is the responsibility of the whole team and it should be considered seriously.