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
• Factors for Breaking Down a Single Project into Multiple Projects
• Project vs. Project Versions
• Setup Example 1
• Setup Example 2
• Setup Example 3
• Setup Example 4
• Guidance related to Specific Testing Needs
• Guidance on Project Setup for NoSQL Databases
• How to View Test Data Projects
• How to Setup Test Data Projects 
• Test Data Project "How To" Articles

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.
     
     
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.

Guidance related to Specific Testing Needs

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:

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 setup the Project.  

Nested Data

When it is complex, nested data with relations, multiple Projects are needed for one table. 

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 Attributes, Master Projects, or G-Map Server.