For some projects it's enough but more often I've come to realise that data is the test - or data is driving the test. So there is a need to dig deeper and to be a little more focused on what counts as "test data".
ISTQB defines test data as: Data that exists (for example, in a database) before a test is executed, and that
affects or is affected by the component or system under test.
So far so good. There is also a definition of test data management:
The process of analyzing test data requirements, designing test data structures, creating and maintaining test data.
That is a lot more interesting because it touches upon a whole set of prerequisites for handling data - and ensuring that data is available in a controlled way. Even the most elaborate test cases, test analysis documents, test environments and skilled test team is worthless without data. And ever so often you see panicking people frantically trying to create data on the fly to pass that last important test.
So starting thinking about a structured approach to test data asking questions like:
- Test data landscape - what's the total set of test data
- Ownership of test data - system or organisation that "owns" data
- Re-useability of test data - can data be handled in a smart wat
- "Consumeable" test data - test data that can only be used once
- Manipulation of test data - how to create data that can be used in a certain test context.
- Primary types of test data - identify test data dependencies where one type of data is directly related to others.