Test Data Management¶

Overview¶

Note

The Test Data Management feature is only available for the Build Places that are in 23R2 and beyond.

Test data management provides the capability of persisting the test data entered by customers, even though the environment gets deleted or expired. Further, data will be persisted throughout the entire life cycle of the Build Place.

The introduction of Test Data Management brings several benefits to customers and partners as mentioned below.

Build Place Environments are designed to be short-lived environments that support an agile development, testing, and delivery process.
As a result, the current design means that Test Data used in such environments is also short-lived. This led to inefficiencies in the test process and caused unnecessary activities for customers to re-create data, either manually or through scripts.
The introduction of Test Data Management Functionality in Build Place will enable the user to persist with the test data throughout the customer lifecycle, invest in improved test data, with the knowledge that the data won't be destroyed with the creation of a new environment, and be more consistent with their testing over several agile cycles.
With the introduction of this feature, customers and partners will enjoy the benefit of a reduction in cost and effort during test data preparation.

Test Data Management feature consists of four main processes as mentioned below.

Enabling Test Data Management
Setting up initial test data
Sanity-QA flow
Development (Dev) Flow

This document will provide a detailed discussion of the main flows mentioned above.

Kindly be informed that the purpose of the Test Data Management solution is to maintain data only for development and quality assurance purposes. Therefore we highly recommend to add test data in QA environment and avoid adding production data in order to mitigate data related security vulnerabilities.

Please exercise caution when populating the QA environments with data, as an excessive amount of test data may lead to complications during the Quality Assurance Environment approval process. This is primarily because it can result in insufficient space in tablespace. To mitigate these issues, it is recommended to incorporate data into Quality Assurance environments in a gradual and organic manner.

In the event that the approval process encounters difficulties, refer to the troubleshooting section for steps to be followed.

Note

Added and approved Test Data are only availabe in the Quality Assurance(QA) Environments and Development(Dev) Environments. And these envrionments will not get provisioned with the default R&D basic data.

Note

Both Topic Environments and Delivery Environments will get provisioned with the default R&D basic data. And these environments will not consist the added and approved Test Data.

List of Abbreviations¶

Abbreviation	Meaning
TDM	Test Data Management
QA	Quality Assurance
Dev	Development
PDB	Pluggable Data Base
san-OK	Sanity Ok tag is added to a commit once the sanity check is successfully completed. This indicates that the code is buildable and deployable.
qa-OK	When the Build Place user, provisioned a QA environment from a selected commit, add test data, and approve it, a "qa-OK" tag is automatically applied to the selected commit. In subsequent QA environment, the presence of the 'qa-OK' tag signifies that the data aligns with the modifications introduced in the corresponding commit that is used to provision the subsequent QA environment. Within the Sanity QA environment, the 'qa-OK' tag serves as an indicator that the code alterations have been validated as acceptable and that the data is in conformity with the changes executed in the pertinent commit.
qa-OK-pending	This tag indicates that the commit has not been QA approved yet.
DR	Disaster Recovery

Test Data Management Enabling Process¶

If a customer wishes to acquire the Test Data Management Feature, they can contact a sales team representative for assistance. The sales team representative will then compile and forward all pertinent information to the Fulfillment and Provisioning Team to enable Test Data Management for the specified Build Place.

Below mentioned pre-requisites need to be met, in order to enable Test Data Management for your Build Place.

Build Place must be in the 23R2 version or a later version.
Build Place should be activated, implementation mode should be set, and initial delivery should be created.
Any existing environments in the relevant Build Place need to be removed.
All the ongoing build operations should be completed.
Daily shutdown time should be set in the Build Place.


Figure 1.1 - Test Data Management Enabling Process

Once the Test Data Management feature is activated for your Build Place, you will see this reflected in the Build Place settings panel, as illustrated below.


Figure 1.2 - Build Place Setting Table

Note once the Test Data Management is enabled, it will be persisted until the Test Data Management feature is disabled.

Setting Up Initial Test Data¶

Initially the basic test data need to be set up in the Build Place to continue with the rest of the operations.

For the configuration of test data, users are advised to place an order for an Initial Quality Assurance (QA) environment. Reason being that the QA environments are primarily designated for Quality Assurance (QA) purposes, allowing QA teams to verify the modifications introduced by developers on the master branch. To facilitate this verification, QA personnel need to introduce specific data. This procedure aids in validating the changes. That is the reason behind allowing only the QA environments to set up the data.


Figure 1.3 - Setting Up Initial Test Data Diagram

Sanity-QA Flow¶

Once a code change is completed, a Sanity Build can be requested to validate its basic functionality and stability. With the Test Data Management implementation, a QA environment also can be provisioned concurrently with the Sanity Build.


Figure 1.4 - Sanity-QA Flow Diagram

Development Flow¶

The purpose of ordering a Dev environment is to provide a dedicated and controlled space for software development and testing activities. It allows developers to work on code changes, test new features, and conduct quality assurance without affecting the production environment. This separation ensures that any potential issues or bugs are identified and resolved before changes are deployed to the live or production environment, helping to maintain the stability and reliability of the software.

Development Environment will be provisioned with the initially entered test data and from the latest successful sanity checked commit.


Figure 1.5 - Development Flow Diagram