Wednesday, 27 August 2014

What's your test data strategy??

Through my years as a test manager I've seen many test strategies and plans. Most of them included a section on "test data". Often a short one mentioning the need for test data and the types of data listed in a table - that's it.

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.
These are probably some of the questions that will bring forward a lot of other relevant issues and challenges in a test environment where there are a number of integrated systems included in test. Once there are integrations outside your own physical organisation you must have a strategy - or trial and error will prove to be very expensive.

No comments:

Post a Comment