Agile Test data administration - let's crack the code
In my last post (http://www.infosysblogs.com/testing-services/2010/05/emerging_areas_of_testing.html) I summarized a few of the emerging trends within the testing arena. Now, I wanted to take a specific thread from those trends and elaborate a little more on "Agile Test Data Administration".
If there is one thing that is resonating again and again within the Testing space, it is that of QA teams and administrators wanting to get their arms around "Test Data". More so to gain confidence around the Preparation and Usage of Test data within the Testing lifecycle as well as to maximize efficiency gains by moving towards an agile way of administering and using Test data.
Let's consider a typical workflow that Test data goes thru within the Testing lifecycle, for ease of understanding I have split this into 2 chunks of activities,
Test data preparation
Test data usage
Test data preparation would include manufacturing the data either "Copy" or "Create", then de-sensitize, mask and then more than often will have to provision the data in multiple testing environments so would include data sub-setting and multi-environment provisioning. The core skills that relates to this chunk of activities are more aligned to a DBA role. Also consider that once the Test data is manufactured it has to be maintained as well, again this points at a DBA role considering managing integrity, Data quality and relationships.
Test Data usage, now the focus suddenly shifts to a "Tester" who might (or) might not be Database savvy....however the tester has to use data for the testing to go thru and complete. So, the tester would look at "Test conditions" converting into "Data conditions" then map those data conditions to accurate physically available data in a Test data set/Environment and in most occasions would need "Data reservation' & "Traceability" to ensure safe passage of the combo unit (Test case + Data).
The key, missing link that almost all QA teams are struggling to bridge are the efficiencies that are lost in translation between the DBA and the tester. Essentially both the DBA and the Tester in their individual capacities are able to function and get to a logical, tangible end point, however converting a DBA's output to a tester's input and vice versa has been begging for resolution.
Consider an example: Tester A needs all John does living in the state of CA, who are going to reach retirement age and have filed a claim in the last 2 weeks. The Tester's output is in plain English and can be documented, Now it is up to the DBA to search Client Table A, relate client age from Table B using Table A's index, use the common index to search Table C for Claims in the last 2 weeks.
Assuming the DBA search returns 6 unique candidates; the DBA will furnish this in the tester's environment and allow the tester to pick and choose for usage. Let us consider a couple of things
Question: Is this the only request for such data from the entire testing team? Re-use? If so, How?
Question: Will Tester A consume all 6 candidates? Again if testers are re-using, how do we ensure that there is no conflict?
Question: Let us assume Tester A does consume all 6 candidates in Test iteration 1? What will the tester do for the second iteration when the tester needs the same data? Copy from PROD?
Question: How does Tester A associate the 6 chosen data candidates to each of his/her test cases? How do we achieve traceability? How do we ensure reverse traceability to the data if indeed we are able to re-engineer efficient Auto creation of data?
The answers to most (or) all of these questions, contains the synergies that can be gained to introduce agility in the 'Test Administration" process. While, we collectively ponder on some of these questions? I would like to set a pre-text for my next post...were I will dwell on some of the possible answers the testing industry can consider.
1. Federated Test Data relationship management
2. Collaborative Test data provisioning
3. Auto creation of Test data by the Tester
4. Test case - Data, traceability and reverse engineering.
Signing off for now and will post soon and hoping to interact with you in this space.