Scenario Versioning

The Safety Pool database allows versions of scenarios to be controlled which is crucial for ensuring the reproducibility of test results.

Without version control it would be possible for a scenario to be changed between testing which could lead to inconsistent results. The Safety Pool database does not allow changes to be made to a scenario once it has been made active so that when testing with a scenario is conducted it can be guaranteed that the scenario is the same as it was when originally tested with.

To achieve this, a life-cycle exists for scenarios. When a scenario is first created, it enters a 'Draft' state, which prevents it from being used, i.e. cannot be added to Test Suites or be downloaded. When the scenario is ready for use, it can then be activated which advances it to the 'Active' state which prevents and changes from being made to it and allows it to be added to Test Suites and to be downloaded. If at some point changes need to be made to the scenario, then a revision must be made. Revisions are scenarios with a link to an existing scenario and follow the same life-cycle as scenarios. If it is decided that a scenario should no longer be used then it can be deprecated which sets its status to 'Deprecated' which indicates to users that it should not be used but does not prevent its use.

Scenario life-cycle 

Version Numbering

Every scenario contains a version number with each new revision being assigned a new version number depending on whether it represents a major or minor change:

• A minor change is one which is backwardly compatible with the previous version, an example of this would be where additional tags have been added to the scenario but the scenario definition remains the same.
• A major change is one which is not backwardly compatible with the previous version and is likely to result in it not being able to be executed without toolchain modifications, an example of this would be where the version of the SDL used for the scenario definition has changed.

Version History

To aid traceability, each scenario contains a Unique Reference Number (URN) so that it can be uniquely identified within the database and also outside of the database. The URN is a Universally Unique Identifier (UUID) which is statistically unique which almost guarantees that there will never be more than one scenario with the same URN regardless of the system which assigned the URN.

Scenario unique reference

 

 

When revisions are created in Safety Pool, the revision contains a reference to its parent scenario, using the UUID, from which it was derived, to allow scenarios to be traced back to their origin and a version history maintained.

Scenario Version History