Configure Dynamic Test Data Reservation Service

To comprehensively test any application, testers need the right test data to be available on demand to conduct varied testing scenarios. Typically, in an enterprise, this data is spread across multiple data sources. This further compounds the challenge of creating a test data mart and finding the data that replicates the production environment and is available on demand. Manually creating the test data mart is not an efficient option and can result in data that has insufficient test coverage, leading to defects in production. Additionally, testers need the capability to easily find and reserve the test data, whenever they want, based on their enterprise environment requirements.
tdm46
To comprehensively test any application, testers need the right test data to be available 
on demand
 to conduct varied testing scenarios. Typically, in an enterprise, this data is spread across multiple data sources. This further compounds the challenge of creating a test data mart and finding the data that replicates the production environment and is available on demand. Manually creating the test data mart is not an efficient option and can result in data that has insufficient test coverage, leading to defects in production. Additionally, testers need the capability to easily find and reserve the test data, whenever they want, based on their enterprise environment requirements.
The CA TDM Portal helps organizations address these challenges by managing the full life-cycle of test data reservation. The Portal simplifies the overall data reservation process by encapsulating the automatic creation and management of test data marts. This ability eases the management and maintenance of test data reservation services. The Portal also helps ensure that the data becomes available to testers in minutes, eliminating the time that is otherwise wasted looking for or preparing data, or creating it where none exists. 
Test data engineers (TDEs) use the Portal to create test data models that facilitate the data reservation process for testers. Defined test data models are shared with testers as dynamic forms in the Self-Service Catalog interface. These forms use the business language that testers understand, which helps testers find the right test data for their testing environments without any issue. Testers can access the applicable forms and can perform test data operations—find and reserve. Through these forms, testers get on-demand access to the exact data they need, allowing them to easily find, view, analyze, and reserve the data.
The following topics cover all the information:
Tutorial Video
Watch the following video for a visual walk-through of a use case of using CA TDM Portal to create a test data model:
 

 
High-Level Process
The following illustration shows the complete data reservation process, which involves the TDE and tester personas:
Data Reservation Using the Portal
Data Reservation Using the Portal
Understand the Terminology
Review the following terms:
Environment
An environment is a collection of data sources that are associated with an application. Each data source maps to a connection profile that is related to a specific project version in the CA TDM Portal. An environment is used in defining a test data model. Test data search and reservation are also performed in the context of the selected environment. 
Review the following points:
  • Each environment is specific to a project and version.
  • You can create multiple environments.
  • Do not use the same connection profile in different environments.
  • Reservations performed in an environment are not migrated when the environment is moved to the latest version.
  • Only relational data sources are supported currently.
  • A connection profile is required for any environment's data source to work. For more information about connection profiles, see Create and edit Connection Profiles. Typically, a schema name is optional for the Microsoft SQL Server or DB2/AS400 connection profile that you create. But, if you use the same connection profile in an environment, ensure that you provide a valid schema name for that connection profile.
    • For Microsoft SQL Server, use 
      SQL Server Schema Name
       to provide the schema name in the connection profiles page.
    • For DB2/AS400, use 
      Additional Connection Properties
       to provide the schema name in the connection profiles page.
      Note:
       For model-based test data reservation service, the Portal takes only the first entry in 
      Additional Connection Properties
      ; it does not consider the remaining entries (if added). For example, if you use 
      libraries=Schema1,Schema2,Schema3
      , the Portal considers only the first entry 
      Schema1
       in this case; it ignores the remaining values.
  • TDEs must share the required connection profiles with testers.
  • Mapping between entities and data sources across environments must be the same within a project version.
  • Once you define a data source name for an environment, you cannot change the name across multiple environments available for the same project version. However, you can assign a different connection profile to the data source.
Test Data Model
A test data model lets test data engineers combine related data elements from multiple data sources, which reside on different servers, into a single container. Testers can then perform test data operations (for example, find or reserve) on the defined model. Test data models abstract the technical aspects of the test data and represents those aspects in a domain-specific language to testers. Test data models, therefore, enable testers to easily understand the data model and define their data requirements.
Review the following points:
  • You can use a single test data model (form) against multiple environments for a specific project and version.
  • TDEs can mark the test data models as visible or not visible to testers after they create them. Only those test data models that are marked as visible are accessible to testers in the Self-Service Catalog section of the Portal as forms.
    TDEs, however, can access the test data models irrespective of the visible state.
  • When a TDE deletes a test data model, all the data reservations associated with that test data model are invalidated. The same test data then becomes available to testers, which they can reserve through other test data model forms.
  • The CA TDM Portal supports only one test data model per project version, though it allows you to define multiple test data models for a version. Therefore, do not create more than one test data model for a version.
    The same behavior is applicable for APIs too.
Model Key
A model key is a data element (or set of data elements) that uniquely identifies the resource that needs to be reserved. For example, in an Order Management System, 
orderid
 uniquely identifies orders in the system. Similarly, 
policyid
 in an insurance system can act as a model key. A model key drives the reservation of records across the test data model. The entity that contains the model key is called the root entity of the test data model.
Review the following points:
  • A model key can be composed of one or more data elements of an entity (for example, table), but both data elements must belong to the same entity.
  • You cannot modify a model key after you define it for a test data model.
Data Element
A data element provides the ability to filter the test data.
Data Reservation
Data Reservation is the process of finding relevant test data and reserving the model keys to exclusively use in the execution of specific test cases. In the CA TDM Portal, when a data reservation request is submitted, the request is processed through various states. The following diagram illustrates the various states that a data reservation request passes through:
Data Reservation State Diagram
Data Reservation State Diagram
The reservations are permanently deleted after 30 days from the time it reaches the "Purged" or "Failed" state. By default, the delete process runs once in every 12 hours to identify whether any purged reservations are older than 30 days. You can configure the default values. For more information, see Configure CA TDM Portal for Deleting the Purged Reservations.
 
Note:
 If any model key value is NULL in a reservation, the reservation is not allowed.
Tasks Based on Personas (TDE and Tester)
As illustrated in the diagram, the complete process involves two personas: TDE and tester.
Test Data Engineer Tasks
A TDE performs the following tasks:
 
Note:
 A tester cannot perform these tasks.
  1.  Create an environment.
    1. Specify name, description, and connection profile.
  2.  Create a test?data model.
    1. Specify the test data model name and description.
    2. Select an environment.
    3. Build a test data model using the data explorer.
      1. Create a model key.
      2. Add data elements to build the test data model.
Tester Tasks
A tester performs the following tasks:
 
Note:
 A TDE can also perform these tasks, but the primary audience for these tasks is a tester. For more information about how to perform these tasks, see Tester Self-Service.
  1. Find test data.
    1. Select the appropriate form from the Self-Service Catalog.
    2. Select the environment.
    3. Define data filters.
    4. Find the data.
    5. Review the data.
  2. Reserve test data.
    1. Select the reviewed data.
    2. Submit the reservation request.
    3. Review the reservation.
Considerations
Review the following considerations:
  • In the current version of the Find and Reserve capability, there is a limitation with the usage of the connection profiles with the Oracle database. The Oracle connection profiles created in the CA TDM Portal need users to have schema ownership. If a user does not have permissions on all the schemas used for the Find and Reserve, then the functionality will not work.
  • The current version of Find and Reserve capability supports the following data sources:
    • Microsoft SQL Server
    • Oracle
    • DB2/AS400
  • TDEs must have knowledge of the commonly used application objects that testers use, relationships between those objects, and the way they map in the underlying database.
  • TDEs must ensure that the required entities are already registered in the Portal.
  • TDEs must define relationships between entities in a test data model.
  • The following data types are not supported in a test data model:
    • CHAR
    • NCHAR
    • BFILE
    • BINARY
    • BLOB
    • CLOB
    • GEOGRAPHY
    • GEOMETRY
    • HIERARCHYID
    • IMAGE
    • INTERVAL DAY TO SECOND
    • INTERVAL YEAR TO MONTH
    • LONG
    • LONG RAW
    • LONGVARBINARY
    • NCLOB
    • NTEXT
    • RAW
    • ROWID
    • SQL_VARIANT
    • TEXT
    • TIMESTAMP WITH LOCAL TIME ZONE
    • TIMESTAMP WITH TIME ZONE
    • UROWID
    • VARBINARY
    • XML
Example Scenarios
The Example: Order Management System article includes an example scenario that explains the complete end-to-end process of designing and consuming dynamic test data services, covering all the TDE and tester tasks.
APIs for Designing and Consuming Automated Test Data Services
You can use the exposed APIs to design and consume automated test data services.