Data Pools: when to use them and how to design them

A Data Pool holds data that exists outside the test and that a test must obtain before it can run: an account to log into, a policy to renew, a SIM to activate. Not every value a test uses is this kind of data, and putting the wrong values in a pool makes tests harder to read and pools harder to maintain. This article gives you a test for deciding whether data belongs in a pool, explains what stays in the test case, and sets out the design and operating practices that keep pools working well. It is guidance, not a set of product rules; the mechanics are in the other Data Pools articles.

Do you need a Data Pool

Ask what the test does with the data and where the data comes from, not how often the data is used. These are the signals that data belongs in a pool:

One signal is enough. A SIM pool used by a single activation Scenario is still a pool, because the SIMs are consumed. On the other hand, being used in many Scenarios is not a signal on its own: a value that every test case shares belongs in a Global Property, and a value that each test case sets for itself belongs in the test case. Nor is differing by environment a signal on its own: a single value with a different value per environment, such as an application URL, is still a Global Property, which can hold a value per Application Environment and Variant. Scope matters for a pool only once the data has earned a pool for another reason (see Data Pools: overview and concepts for choosing between a reusable pool and a Global Property).

What stays in the test case

A test case states what the test is checking: the input it tries, the choice it makes, the result it expects. A pool supplies the material the test needs to do that. Keeping the two apart is what makes a test case readable on its own and a pool reusable by many tests.

Keep a value in the test case when it is any of these:

• an expected result, such as a message, a status or a calculated amount;
• an input that defines the test case, such as the transfer amount in a limits test or the invalid PIN in a negative test;
• a choice between options the application offers, such as a payment frequency or a shipping method;
• a combination of inputs that is itself the point of the test, such as the rows of a boundary or permutation table.

Moving these into a pool does not make them reusable; it moves the meaning of each test case out of the Test Cases grid and into a record somewhere else. The usual result is a pool whose records mirror the test cases one to one, with a Data Class per record so that each test case can find its own row again. That is a test case grid stored in the wrong place. If you find yourself naming Data Classes after test cases, the data belongs back in the test cases.

For the full set of value sources a parameter can use, and how they differ, see Use Data Pool data in your tests.

Designing the pool

Once data has earned a pool, a few design choices decide whether the pool stays easy to use. Each is a question to answer before you create the pool, because changing it later has consequences for the tests mapped to it (see Change Impact in Data Pools).

One pool per kind of record

A pool holds records of one kind, where one kind means records that the same Scenario could use interchangeably. Auto policies and home policies are two kinds: no renewal Scenario picks between them, and their flows differ. A pool that mixes them forces every Scenario to work around the records it cannot use. Give each kind its own pool, even when the columns look similar.

Type by what the test does

Pick Single-use when a test consumes the record or leaves it in a state the next test cannot start from. Pick Reusable when tests only read the record. The deciding question is whether the next test can use the same record as it is after this test has run. The data itself does not decide: a customer account is reusable for a balance check and single-use for an account closure, and if the same account must serve both, the closure test needs its own pool.

Data Class

Data Class is the choice a test case makes, so a pool’s Data Classes should be the alternatives one Scenario can sensibly pick between: 4G, 5G and eSIM for an activation Scenario, or Active, Due for renewal and Lapsed for a policy Scenario. Use the words a test author would use when asking for a record. Keep the list short enough to choose from in the Test Cases grid, and avoid these two misuses:

• A Data Class per record, used as a record name. This turns Data Class into a key and defeats the point, which is to ask for a kind of record without naming one.
• Data Classes that no single Scenario would choose between. These are different kinds of record and belong in separate pools.

Columns

Give the pool the columns tests actually use, named the way test authors and the source data already name them, because those names appear in Parameter Configuration and in import files. Do not add columns for expected results or for values a test can derive during the run. Do not create columns named Data Class, Environment, Variant or ID; those names are reserved. Mark a column encrypted only when it holds a secret the test types into the application, such as a password or a PIN; encryption is not a way to hide ordinary data from testers, and encrypted values can never be read back (see Create and manage Data Pools).

Record Scope & Variability

Turn on Application Environment, Application Variant or both only when the data in the pool differs along that dimension. Reference data that is the same everywhere, such as a product catalogue, needs no scope. When scope is on, give every record its environments or variants, and use Any only for a record whose values are genuinely valid everywhere. A record left without environments or variants is set to Any, so a forgotten entry becomes a record that every run can receive. Do not create one pool per environment; one scoped pool is what lets a Scenario run anywhere without changes.

Running the pool

A pool needs a little attention after it is built, and most of it concerns single-use pools, which deplete.

• Check the Ready count before large or parallel runs. A Job starts even when a pool has too few Ready records; the test cases that cannot get a record fail. Give single-use pools a replenishment Job so they are refilled on a schedule (see Build Data Pool replenishment jobs).
• Plan the environment refresh. When a lower environment is restored from a baseline, the pool’s records for that environment need replacing. Decide who does it and how, by replenishment Job or by import, before the first refresh.
• Return records allocated by hand. A record a user allocated stays Allocated until someone changes its status. Make returning records part of the manual testing routine, and look for stale holds by holder and date.
• Share instead of copying. When another project needs the same data, share the pool. A copy drifts from the original and doubles the maintenance. Use Specific projects for a known group and All projects for tenant-wide reference data (see Sharing a Data Pool).
• Check references before changing structure. Use Show References before deleting a Column, changing scope or narrowing sharing, so you know which Scenarios and projects depend on the pool.

Dos and don’ts