The need

The problem is that system-level tests (and BDD ones) need to use test reference data* in order to control the SUT and check its output. Such data needs to produced, validated, versioned. And therefore we need mechanisms to store them, to update them, to reference them. We will need also a policy and a process to define such data, revise them, approve changes, and likely somebody who is in charge (a "data curator").

It might make sense to distinguish handling of input data to drive/control the SUT vs data used when checking the output of the SUT.

One aspect that needs to be considered is the size of the data. When we will start using images and ???? then storing them, versioning them and trasnferring them would become an issue.

In general terms we are focusing here on a component of the Test Automation Architecture which could be called Test Data Manager.

* TEST REFERENCE DATA

this is data that is used by tests to exercise & check the SUT; the test script would not change these data. For example, configuration strings, user credentials, etc. These data are different from the data produced by the SUT when working.