Self-Service Test Data Provisioning

To fully adopt a continuous testing model for Agile and DevOps software development environments, test data must be continuously available. Test data designed to meet the requirements of any test case must be available on-demand through the process of self-service test data provisioning.

To that end, a self-service layer has been added to the component-based architecture of the GenRocket TDG platform called GSelf-Service. Three new modules have been added to GSelf-Service to simplify and streamline the test data provisioning process, allowing testers to rapidly configure the exact test data they need whenever they need it. Following is a brief description, a solutions video and a link to a knowledgebase article for these new GSelf-Service modules.

Before reading on, you may wish to learn about the GenRocket TDG Component Based Architecture and how Test Data Scenarios contain GenRocket Domain, Attribute, Generator, and Receiver components… the key components used by GenRocket to generate Real-Time Synthetic Test Data.

Test Data Cases

Testers often need data in many variations to support their test cases. Here are some examples:

  • Positive and negative testing
  • Range and boundary testing
  • Data permutations and combinations
  • Workflow testing across multiple API’s

They may also need to vary the volume of test data to perform load and performance testing. The GenRocket’s Test Data Cases self-service module gives testers total control over the volume and variation of test data they wish to provision for a given test case. Test Data Cases provides an intuitive way for testers to combine multiple Test Data Scenarios into logical groupings that map to a test plan for a given application under test.


The diagram above shows the hierarchy. Working from the bottom up, Test Data Scenarios contain the data Domains, Attributes, data Generators and output format Receivers that match the schema for one or more application database data tables.

Test Data Cases is a self service module that allows testers to quickly define test data stories that create test data for all their test cases. Test Data Cases is also able to accomplish this goal without having to change the original Test Data Scenario conditions. And for complex Test Data Cases, testers can also use Test Data Rules and Test Data Queries, (see below) to create very precise conditions for the test data generation process.

Test Data Cases can then be grouped as Test Data Case Categories to map the required test data configuration to a category of testing, such as functional, integration, performance, security or regression testing. And finally, categories of Test Data Cases can be grouped together into Test Data Case Sets to define and specify all test data needed for a suite of tests to be executed for a given application test plan.

This short video provides an overview of the Test Data Cases self-service module:

Test Data Rules

A second self-service module available to testers during the data provisioning process is Test Data Rules. This module allows testers to apply rules that govern the test data generation process to control the nature of the data need for testing and validating application business logic during an application workflow test.

With Test Data Rules, testers can easily define a RuleSet consisting of If-Then relationships to control or modify the conditions and actions for test data generation. Test Data Rules can be applied to any Test Data Scenario that is part of a Test Data Case (as described above).


For example, if a bonus calculator for a shopping cart transaction relied on business logic to calculate a bonus discount based on the customer’s reward level (e.g., gold, silver or bronze) and the item price total (e.g., >=$500, >=$250, >=$100), the tester can use Test Data Rules to generate test data to validate this business logic.

This short video provides an overview of the Test Data Rules self-service module:

Test Data Queries

There are times when synthetic test data must be blended with production data to create highly accurate and realistic testing conditions. This is especially true when testing workflows during integration or end-to-end functional tests. GenRocket’s Test Data Queries is a self-service module that makes blending synthetic and production test data an easy and intuitive part of the provisioning process.

For example, imagine testing the workflow associated with health care insurance claim processing. Test data for a submitted claim must contain synthetic data in place of any personally identifiable information for patients and providers. However, the CPT codes used to represent diagnostic and treatment procedures must be clinically accurate (i.e., real production data) in order to test the business logic for processing the claim. CPT codes are the basis for returning a correct approval or denial of benefits based on the insurance plan covering the patient. See the workflow testing diagram below.


With Test Data Queries, the production database can be queried to retrieve real CPT codes from a patient history file and used to test claim processing logic, while masking private patient and provider information with synthetic data replacement. This allows testers to create the exact test data they need with control of data variety and volume without the use of sensitive information or the risk of violating privacy laws.

This short video provides an overview of the Test Data Queries self-service module: