ACCELQ Data Pool: overview and concepts

When your tests need real data to run against, such as a SIM to activate or an account to log into, a Data Pool keeps that data in one place and gives each test a suitable record. ACCELQ tracks which records are in use, so parallel runs never receive the same one. Automated tests get records from a pool when they run, and manual testers allocate a record before they test. This article explains the ideas the rest of the Data Pools documentation builds on; for the hands-on tasks, follow the related articles at the end.

Why use a Data Pool

In a real test suite the same accounts, SIMs, cards or orders are reused across many tests and test runs. Records go stale, two runs grab the same record at the same moment, a record that can only be used once gets consumed and the next run fails, and data that is valid in one environment is meaningless in another. A Data Pool centralizes this data, tracks what has been used, keeps parallel runs from colliding over the same record, and can refill itself on a schedule. This removes the common data-related causes of test failures, and test accounts no longer have to be tracked by hand.

A large part of the value shows up around environment refreshes. Much of your test data is reference data that a lower environment is seeded with: the valid accounts, SIMs or IDs that exist in QA or staging. When that environment is refreshed from a baseline, those values change, and any test that hard-codes them breaks until someone updates it. If a replenishment job refreshes the pool along with the environment, tests get valid data on the next run and do not need to be changed.

The data model

Three terms describe what a pool holds and how a test asks for it.

Data Pool, record, and column

A Data Pool is a managed, named set of test-data records of one kind, for example a pool of prepaid SIMs or a pool of subscriber accounts. You define its columns once, fill it with data, and any Scenario in the project can then draw from it.

A record is one entry in the pool, such as one SIM or one account. When you create a pool, you also choose what a single record is called (a SIM, an Account), and that word is used throughout the screens, so the pool reads naturally. A column is a named field that every record carries, such as MSISDN or ICCID.

Related ACCELQ concept 

A Scenario is a test flow in ACCELQ, and its steps take parameters (their inputs). Binding a parameter to a Data Pool is the main way a test consumes pool data. See Use Data Pool data in your tests.

Data Class

Every record carries a Data Class, a short label describing what kind of record it is, such as 5G, Business Account or Past-Due Bill. Data Class is how a test asks for a 5G SIM without naming a specific record, and it is required on every record. It is not an ordinary data column; it is kept separate, because its job is to let tests pick records. Each record also has a system-assigned ID that the platform manages for you.

How a pool behaves

A few pool-level choices decide how records are handed out and protected.

Single-use and reusable pools

Every pool is one of two types, and the type determines how its records are handed out. A single-use pool holds records that are consumed as tests run, such as a SIM you activate once or a one-time coupon code; these pools deplete and are usually kept stocked by a replenishment job. A reusable pool holds records that tests only read and never use up; any number of tests can read the same record, and the pool never depletes.

Examples:

Record statuses

Records in a single-use pool move through a lifecycle. These are the statuses you will see, and the other articles refer back to them:

A record allocated by a user stays allocated until someone changes its status, and any user can do so, including users in a project the pool is shared with. ACCELQ releases automatically only the records it allocated to an automation run.

Reusable pools do not use the consumption part of this lifecycle; Allocated and Used do not apply to them. You can still mark any record, in either type of pool, as Inactive when you want to keep it from being selected.

Record Scope and Variability

Record Scope & Variability is a pool-level setting. You turn it on when the pool’s records are not all valid everywhere, making the pool sensitive to Application Environment, to Application Variant, or to both. In a scoped pool, each record indicates which environments or variants it is valid for, and you can select several. A record left applicable to any value is the exception, used when a particular record genuinely works everywhere. At run time matching is contains-or-Any: a test in a given environment receives records that include that environment, plus any records marked valid for all.

Related ACCELQ concept

Application Environments and Application Variants are platform concepts ACCELQ uses to run the same tests against different deployments and product configurations. Record Scope & Variability lines pool data up with them.

Encrypted columns

A column can be marked encrypted when it holds a secret that a test enters into the application under test, such as a password or a PIN. You supply the plain value when adding or importing, and ACCELQ stores it encrypted. The value stays encrypted all the way to the test: an encrypted column can supply only Action parameters that are marked encrypted, the same rule that applies to encrypted Global Properties. The value is never shown in readable form to anyone, including manual testers, so encryption is for secrets your automated tests use, not for keeping ordinary data out of view.

Ways to use pool data

There are two parallel ways to use pool data in a test, both covered in Use Data Pool data in your tests. You can bind a parameter to a pool: the parameter's value comes from a pool and column, and ACCELQ fills it at run time. Or Action logic can fetch and work with records using the Data Pool commands. Manual testers can also allocate a record in the pool before they test.

Choosing between a reusable pool and a Global Property

Because both a reusable pool and a Global Property hold data you reference rather than type into each test case, it helps to know which one fits. They are not interchangeable.

A Global Property is a single value shared across the project, for example a base URL. There is exactly one value (per App Environment, App Variant combination), and every test that references it gets that same value. A reusable pool, by contrast, is a set of records, each with several columns, that a test selects among: the test picks which record (by Data Class or scope) and reads several fields from it. For example, a pool of reference accounts where each record has a username, role and region lets a test pick an account by role and use its username, its region and more.

The decision comes down to two questions. If you need one fixed value, use a Global Property. If you need to choose a record and read a few related fields from it, use a reusable pool. A sign that the data belongs in a reusable pool is having several Global Properties that vary together, such as an account’s id, name and region as three separate properties; those belong together as a record, which a reusable pool gives you.

Permissions

Working with the data in a pool is open to everyone in the (owner) project: using pools in tests, viewing and exporting records, adding, importing, editing and deleting records, changing record status, and running Data Pool commands in test logic and replenishment jobs. But two permissions are controlled by permission flags set in the User Role :

1. Manage Data Pools: create pools and change their structure and settings, which covers columns, encryption, Record Scope & Variability, sharing, Move Ownership and replenishment. In a project a pool is shared with, it is also needed to remove the pool from that project.
2. Delete Data Pools: delete a pool and all its records.

In a project a pool is shared with, anyone can use the pool in tests, view its records and change record status; its data and settings are changed only in the owning project, whatever the role. If a management action is unavailable to you, check your role with your ACCELQ administrator. For how roles are defined, see User Roles and Access Control (RBAC).