Details
-
Enabler
-
Could have
-
None
-
None
-
Obs Mgt & Controls
-
-
-
1
-
1
-
1
-
-
-
-
17.5
Description
this is a followup of the work done against SP-1577, which was not completed in PI-10. See comment https://jira.skatelescope.org/browse/SP-1577?focusedCommentId=79940&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-79940 and following ones.
What needs yet to be done are minor things (following points taken from acceptance criteria - repeated here to provide a more complete description):
- the CLI script should be enriched with some way to specify the pathname where to locally store the data resource, when downloading it;
- the CLI script should be enriched with some way to specify the new version of the new uploaded data resource, when uploading it;
- the tool requires a predefined root directory in nexus (something like 'data-manager') and is not allowed to manipulate nexus resources that are stored outside this root.
Original description of SP-1577
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, version it, 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 test vectors then storing them, versioning them and transferring 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.
