Create and Manage Data Pools in ACCELQ

Set up a Data Pool once and your team has a managed supply of test data that any Scenario in the project can draw from, kept healthy and, for single-use pools, refilled on its own. This article walks through creating a pool, defining its columns, setting scope where it is needed, keeping records healthy, sharing, and deleting. If the terms used here are new, read Data Pools: overview and concepts first. 

Creating a pool and changing its structure or settings require the Manage Data Pools permission, and deleting a pool requires Delete Data Pools. Working with records is open to everyone in the project.

Set up a pool

Setting up a pool takes a few decisions, made once, that shape how its data is organized and used.

Create the pool

Open the Data Pools area and choose New Data Pool. Creating a pool is a short form, but a few of the choices shape how the pool behaves for the rest of its life.

Give the pool a clear name that test authors will recognize in a list, such as Prepaid SIMs. You also choose what a single record is called, in the field A record in this pool is called a..., for example a SIM or an Account. That word then appears throughout the screens, so the pool reads naturally wherever its records are shown.

Next, choose the type. Pick Single-use if its records are consumed as tests run, such as a SIM you activate once; these pools deplete and are normally kept stocked by a replenishment job. Pick Reusable if its records are reference data that tests only read, such as a set of reference accounts many tests look up; these never deplete. The type governs whether records have a consumption lifecycle at all, so match it to how the data is really used. 

Finally, you define the pool’s columns, covered next.

Define the columns

Columns are the named fields on every record, such as MSISDN or ICCID. There are two ways to define them, and you can combine them: start from a spreadsheet, then adjust by hand.

Add columns by hand. Add each column and give it a name. Use the names your test authors and your source data already use, because these are what appear when a parameter is bound to the pool. If a column holds a sensitive value such as a PIN, mark it encrypted as you add it (see Encrypted columns).

Create columns from a spreadsheet. If you already have the data in an .xlsx file, import it and let the columns come from the file’s first row instead of typing them: the header row becomes your columns and each later row becomes a record. The full import process, including how rows are validated and how problems are reported, is covered in Import and export Data Pool data.

Reserved column names

A few names carry special meaning and must not be used as ordinary data columns: 

Data Class, Environment, and Variant (and the system-managed ID). In an import file these set a record’s class and scope rather than being stored as fields. In particular, when adding columns manually, do not create a column called Data Class to hold a class value; every record already carries a Data Class separately, as described next.

Data Class

Every record carries a Data Class, a short label for what kind of record it is, such as 5G or Business Account. This is not an ordinary column; it is the field tests use to pick a record, so it is kept separate from the data columns. Data Class is required on every record, so make sure each record you add or import has one. Choose labels that read naturally to a test author, since these are exactly what they choose from when selecting records for a test.

Set Record Scope and Variability

If the data in a pool differs across application environments or variants, turn on Application Environment, Application Variant, or both in the pool’s Record Scope & Variability setting. For example, the same kind of account may have different account numbers in QA and in UAT. 

Once a dimension is on, each record lists the environments or variants it is valid for. A record that is the same everywhere can use Any instead. At run time, ACCELQ picks only records that match where the test is running. For how matching works at run time, see Data Pools: overview and concepts.

Encrypted columns

Mark a column encrypted when it holds a sensitive value such as a PIN or password. You supply the plain value when you add or import data, and ACCELQ encrypts it as it is stored; it is never shown back in readable form, and exports leave encrypted columns as a header only, so an export can be shared without leaking secrets. Encrypting a column is permanent: there is no decrypt action, and to hold plain values again you would delete the column and create a new one, losing its mappings. See Change Impact in Data Pools.

Maintain records

Once a pool is in use, keep its records healthy so tests keep finding what they need.

Work with record statuses

In a single-use pool, each record moves through a lifecycle as it is used and refilled, from Ready through Allocated, Used, and Inactive (Data Pools: overview and concepts explains what each status means). In the records view you see each record’s current status and an availability signal that warns you when Ready records are running low, which is your cue to replenish. Reusable pools do not use this lifecycle.

Change several records at once

To act on many records together, select them in the records view. The toolbar shows what you have selected, broken down by status, so you always know what you are about to affect. From there you can Change status to any target or Delete.

When records are in use 

If your selection includes records that are Allocated, held by a running test or by a user, changing their status asks you to confirm first, because forcing a status could collide with live work. For each Allocated record the grid shows who holds it and since when, so you can tell a run in progress from a record someone set aside.

Keep single-use pools stocked

Because single-use pools deplete, they are normally refilled automatically. You set a replenishment job and a schedule on the pool, and ACCELQ tops it up on its own. Building these jobs is covered in Build Data Pool replenishment jobs.

Share and remove pools

Pools can serve more than one project, and can be removed when they are no longer needed.

Share a pool across projects

By default a pool is usable only in the project that owns it. To let other projects consume it, open the pool actions menu, choose Sharing..., and set This project, Specific projects, or All projects. Sharing is live and read-only: consuming projects read current values at run time and cannot edit the pool. For the options, the rules about who keeps access, and what happens when a project is cloned or ownership moves, see Sharing a Data Pool.

Delete records and pools

You can delete individual records, a selection of records, or an entire pool. Deleting a pool requires the Delete Data Pools permission in the User Role assigned to the user, while deleting records is open to everyone in the owing project. 

Deletion of Pool is guarded so you do not break active work: a pool that another project is actively using is protected from deletion, and records currently Allocated are skipped rather than force-removed. Because some changes ripple outward to the Scenarios that use a pool, see Changing Data Pools: impact and governance before removing columns, changing scope, or deleting a pool that is in use.