Self-Service Test Data Design

To implement continuous testing for an Agile/DevOps software development lifecycle, test data must be continuously available. Designing test data should be an integral part of test case development during each Agile sprint. With GenRocket, synthetic test data can be designed exactly as needed to maximize test coverage to help achieve quality at speed.

The only way to deliver continuous testing with comprehensive test data is to implement self-service test data automation.

To that end, a self-service module, called G-Self-Service, has been added to the component-based architecture of GenRocket’s Test Data Automation platform. Several modules work together to simplify and streamline the data design process for an Agile testing environment. They allow testers to rapidly configure the precise test data they need, whenever they need it.

Introducing G-Self-Service:

G-Self-Service contains a group of self-service components that provide any tester with complete control over the nature of synthetic data that can be generated quickly and accurately for basic, intermediate or advanced test data challenges. Collectively these self-service components provide testers with an ability to design test data to meet the requirements of any testing objective.

Here is a table to illustrate the G-Self-Service components.

Following is an overview of each component and links to relevant knowledge base articles describing the many capabilities of G-Self-Service. If you are not already familiar with GenRocket’s Component Based Architecture, you may find it useful to better understand the concept of Test Data Scenarios and their key components: Domains, Attributes, Generators, and Receivers. They are the building blocks used by the GenRocket Platform to generate Real-Time Synthetic Test Data.

Designing Test Data With G-Self-Service

Let’s take a closer look at each G-Self-Service component and how testers can use them to design test data. The diagram below illustrates their relationship to one another.

G-Cases

This component allows a tester to rapidly build Test Data Cases by defining the Scenario Domains used to generate data, the sequence of scenario execution, the number of rows of data needed for each domain, and the output receiver(s) needed to format the data. G-Cases enables testers to define test data in almost limitless variations to support their test cases.

Here are some examples:

• Unit testing
• Integration testing
• Positive and negative testing
• Range and boundary testing
• Data permutations and combinations
• Load and performance testing

Test Data Cases gives a tester the ability to provision the volume and variation of test data needed in a matter of minutes.

G-Rules

If your QA teams require data for validating business logic or testing complex workflows, they can apply Test Data Rules to control how data will be generated based on if-then-else logic expressions. With Test Data Rules, testers can easily define a RuleSet 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.

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.

G-Queries

If a tester wants to combine real production data with synthetic data to provision accurate, enumerated data values, Test Data Queries can be configured to retrieve production data in real-time at the same time synthetic data is generated. The ability to combine real production data values with synthetic data is useful for accurately testing the business logic of application workflows.

For example, imagine testing the workflow associated with healthcare insurance claim processing. Test data for a submitted claim must contain synthetic data in place of personal or private data for patients and providers. However, the CPT codes used to represent diagnostic and treatment procedures must be clinically accurate (real production data) in order to test the business logic for processing the claim. That’s because valid CPT codes are the basis for reaching a correct approval or denial of benefits decision based on the insurance policy covering the patient. See the workflow testing diagram below.

With Test Data Queries, a 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 without the use of sensitive information or the risk of violating privacy laws.

G-Stories

With G-Stories, testers can organize many different G-Cases in conjunction with Agile test cases based around the concept of user stories. This allows test data designs to be associated with Agile testing of applications at the feature level. With G-Stories, a collection of Test Data Cases and Categories can be combined into Stories with Chapters.

G-Stories may contain multiple chapters to define a pre-determined sequence of test data generation operations that match the flow of an Agile test case. As more units of code are developed and integrated into the pipeline, G-Stories can be used to integrate the associated test data cases so that data is immediately available for integration testing.

G-Epics

To support the highest levels of integration and system testing, G-Epics brings together the test data designs created by all other self-service components. G-Epics is used to organize a group of Test Data Stories, Chapters and Cases into Epics that that represent multiple product features or a complete end-to-end system. G-Epics provides any QA organization with enterprise scalability for their Test Data Automation deployment.

Putting it All Together

G-Self-Service is used extensively during the DESIGN stage of the GenRocket Methodology, a four-stage process that provides a consistent workflow for self-service test data provisioning. Here are the four stages of the GenRocket Methodology:

Using this methodology, data architects MODEL applications or databases into Test Data Projects. Testers DESIGN test data cases in each Test Data Project to meet the requirements of their test case objectives and they DEPLOY the test data into test automation frameworks or CI/CD pipelines. Test Data Project access control and dashboards allow testers and managers to MANAGE all the Test Data Projects. This model brings consistency to a self-service process that maximizes speed, agility, reusability, security, data quality and test coverage.