Description

GenRocket is licensed based on the number of "Test Data Projects" ("Project") a customer needs for their test data requirements. The GenRocket platform is built on a very flexible architecture, and the definition of a Test Data Project often depends on the application ecosystem that is being tested and the testing purpose. Test Data Projects contain the data model for each application or database for which you want to generate test data within the application.


Projects contain no customer data. Projects contain aspects of your data model as reflected in the GenRocket 5 key components: the Domains, Attributes, Generators, Receivers, and Scenarios that generate data for your testing use cases. 


In This Article


Guidance for Mapping Projects to Your Needs

Below, we provide some guidance as to how to map your test data needs to a Test DataProject:

  1. Start with identifying what is being tested.
    • You may be testing an entire application, specific modules, databases, screen functions, specific messages, etc.

    • Determine what type of application or database is involved. For example, in certain "closed" systems like SAP or Salesforce, testing is different than an internal application where you have access to the underlying database. You often will be designing specific sets of test data (e.g. customer, invoice, purchase order) and then sending that test data into the system via a REST API (or other methods) rather than sending it directly into the database.

  2. Determine how your applications and underlying databases are related.
    • An application will have 1 or more underlying databases. Each database will have Domains ("Tables") which have some relationship. A test data project contains a group of "Domains" (Tables) that are related. For example, in a CRM application, you can have "Account," "Contact," "Quote," and "Product" tables that are all related.

    • A closed application like an ERP will have modules. For example, an accounting system may have AP, AR, and Invoicing modules. These modules may or may not be related. 

  3. Count the applications, related databases, etc. This will give you an estimate of the number of minimum test data projects you will need for specific testing needs.


Factors for Breaking Down a Single Project into Multiple Projects

These factors are:

  • Size of the databases involved in testing
  • Complexity of related tables
  • Whether functions within the same modules being tested are related
  • Specialty output messages like SWIFT, EDI, etc.


Project vs. Project Versions

  • Each project will have one or more project versions. 
  • Project Versions are used when you need to test different versions of the application or database.

Setup Example 1

An application with one database (simple). Typically, this will be equal to 1 Test Data Project. For example, you are updating your CRM to collect additional customer information that will be fed into another system, which will be a change to the "Customer" database.


Setup Example 2

An application with multiple unrelated modules, each with its own database. Because the modules are not related, they will require 1 test data project each. For example, an ERP application with AP and AR modules are typically not related.



Setup Example 3

Certain databases, such as Oracle, often have multiple schemas in a single database. If the tables in those schemas are related, you will likely need 1 test data project for all schemas (depending on the complexity). If the tables in those schemas are not related, you will likely need a test data project for each schema.

 

Setup Example 4

For example, if you need to test an application or database in subsequent releases, you can create a project version of the existing project. Similarly, if you have two teams working on the same application but need different versions of test data, you can use project versions. In this scenario, you need 1 Test Data project with two project versions.



Setup Example 5

For example, more than one project will be needed if you are testing an application or business process workflow. Each application, database, or complex file type within the workflow requires at least one project. This allows referential integrity to be maintained between applications. Let's look at a simple insurance workflow where 5 business processes will be completed in the following sequence: 

  1. Create Customer
  2. Create Agent
  3. Create Quote
  4. Make Payment
  5. Create Policy


At a minimum, each of the steps in this example workflow will require a project. This means that a minimum of 5 projects will be required to complete testing for the workflow. In certain instances, a process in the workflow may require additional projects, such as.

  • A database with multiple schemas (see Example 4 above).
  • A step that also requires a complex file type.



GenRocket can be used for testing where there are specific output test data required or where the underlying database/ecosystem is not known. The table below provides guidance about Test Data Projects in these types of specific cases:

ScenarioMinimum # of ProjectsGuidance
Closed or COTS systems like SAP, Salesforce, etc.1 Project per Module or related functionsTo test an ERP with different modules, in an AP module, the invoicing function would be one project.

Testing Salesforce through the front end (a group of screens/fields to test a function) would be a project.
Blackbox or front-end testing1 Project per related function or group of related front-end fields Web front end testing for an enrollment form would be one project.
Subset or masking a SQL database1 Project per related group of domains/databaseSubset and mask a customer database to subset and synthetically replace customer names.
Specialty test data files used with SWIFT or EDI1 Project per SWIFT message (MT or MX)

1 Project per EDI message (document)
Tags in each SWIFT message are considered related domains. SWIFT MT940 is a separate project from SWIFT MT103.

Segments in each EDI document are considered related domains. EDI837P is a separate project from EDI 837I.
Complex, nested fixed file formats (example: Avro, Parquet)1 Project per group of nested segmentsThe segments in the nested output are considered a group of related domains.
Applications with NoSQL databases
A large number of variables are involved in NoSQL databases. It will depend on what is being tested.
Application or Business Process WorkflowMinimum 1 Project per application, database, or complex file type in the workflow.
At least one project will be required for each process in the workflow. More may be needed depending on what the step entails (i.e., multi-schema database, complex file types, etc.).


Guidance on Project Setup for NoSQL Databases

NoSQL databases, like MongoDB, are schema-less, which means that XTS cannot be used to grab the schema and import it to create Domains within a Project.


Simple, Flat Files

For end-to-end setup (import through test data generation), you will need to create a Project. Then extract the JSON Record (called document) from the NoSql collection and save that JSON Record in a file. Once finished, use the Import from JSON option to import the created JSON file and set up the Project.  


Nested Data

When it is complex, nested data with relations, multiple Projects are needed for one table. (Note: GenRocket has some flexibility about how licensing and Project counts are tracked for NoSQL database use cases. Please reach out to your GenRocket representative to schedule a discussion)


How to View Test Data Projects

Projects are created and managed from the Projects Pane within the Project Dashboard


How to Setup Test Data Projects 

  1. Log into the GenRocket web platform.
  2. From the Project Dashboard, create a new Project
  3. Import or create your Data Model (i.e., Domains, Attributes, Generators)
  4. Establish Referential Integrity through Parent-Child-Sibling Relationships
  5. Use the Self Service Platform to set up cases, rules, queries, and more. 


Note: Data in one project can be related to data in another project through Organization Variables, Organization AttributesMaster Projects, or G-Map Server


Test Data Project "How To" Articles

The following articles can be used to learn more about setting up Projects:

Topic
Description
How do I create a Test Data Project?Learn how to create a new Project. 
How do I create and update a Project Preset?Learn how to create and update a Project Preset
Deletion Permission Policy for Projects and Project VersionsLearn about the Deletion Permission Policy (Projects/Project Versions) and how it works. 
Project Categorization Overview (Beta)Learn more about categorizing Projects for your organization.
Project Versions OverviewLearn more about Project Versions and how to manage them.