Not every release is a critical release!
There are releases which are critical from technical and business interests. In such critical releases, most of my time is spent on understanding the technicalities of the system and the test data identification on identifying what are the priority tests. Identify and building the test data takes major chunk of the testing time. This effort has helped me, testing, stakeholders, projects and products immensely.
Test Data != Test
Looks like the word "Test Data Management" has become a buzz and marketing word. In how the word "Test Data Management" is pushed, to me it looks like the intent is missing for -- how to identify the tests and its test data?
- If I cannot think of tests, how can I think of Test Data?
- How can I think of tests, the right tests in the context, and the priority tests out of it?
- If I cannot get this, how can I get the Test Data for all these tests?
Before talking of Test Data Management, we need to talk about the intent and goal of the test. If I have a clarity here, by being aware of the product's technical internals, architecture and its eco system, I can think of test data in a better sense. For first, the PaaS which provides Test Data Management solution has to push and enforce for learning and mentioning -- What is the intent of the test?
When I know, for what to evaluate and how should I be evaluating it, those test intent will lead me to the Test Data and its dimensions which should be vectoring the tests.
Test Data is not [equal to] a Test. Test Data is one of the variance, in fact, it is a multi-dimensioned variance that a test will [need to] have. While a test has one deterministic objective, the test data will have multi-dimensioned vectors that instruments a test.
Test Data has its role in a test, and, it is a critical role. Hence, we practicing Test Engineers talk and spend our time on Test Data in equal importance as we give our time to identifying, designing and execution of tests.
Test Data is not a test; but the test data is an expression of the test's intent. Test Data is one of the byproducts of a test. Having this clarity is important.
Note this, the test data is not the only expression of the test's intent. A test will have multiple touch points; these touch points express, advocate and can show the intent of a test. A test data is also a heuristic as a test is.
Test Data Management
The word "management" is underrated and not attempted to understand from context where it is being spoken. How do this word sound -- "Test Data Leadership"?
In engineering, especially in the software engineering, the word "management" inherently talks primarily about design. On day-to-day operation, the management designs its strategy and approach to solve the problem and challenges.
When said "Test Data Management" in software engineering, it is about strategizing and approaching the problem of identifying and categorizing (subsets) the data to test. A kind of leadership at one layer. It has its role and critical to the deterministic outcome for a test.
In machine learning, we can see this categorization -- training data and test data. Then, is training data not a test data? It is! The training data is designed [managed] to train and this data as well identifies the problem as the training progresses.
The data which are identified, designed, categorized and collected as Test Data, are well sampled data in the context, for the intent of a test.
To conclude, Test Data Management is one of the correlation in software engineering to solve a problem; it is contextual in how and what tests and testing is executed. The different teams and organizations has their own way of managing the test data. How they do it, it is their way of doing it. We have to look Test Data Management from point of Test Engineering and not as an another buzz word to sell just as a product and business's service.
