Use Data Pool data in your tests

A test can get data from a Data Pool in three ways. In an automated Scenario, you bind a parameter to a pool, and ACCELQ supplies a record to each test case when it runs. When Action logic needs to fetch or work with records itself, it uses the Data Pool commands. Manual testers allocate a record in the pool before they test. This article covers each of these, and ends with guidance on when a pool is the right source for a value.

Data-driven parameters

A Scenario runs once for each of its test cases. A parameter is data-driven when its value can differ from one test case to the next, which is what lets a single Scenario cover many cases. 

Two value sources make a parameter data-driven: values entered in each test case, and values drawn from a Data Pool. Both are set row by row in the Test Cases grid. The difference is who supplies the value: with test case values you type it in each row; with a Data Pool binding you choose the kind of record for each row, its Data Class, and ACCELQ selects a record and fills the value.

The other value sources work differently. A fixed value, a Global Property or a Run Property supplies one value that every test case uses, overriding per-test-case data. Use them when the value should not vary between test cases. Linking from a previous step is a separate case again: the value is produced during the run by an earlier step.

Related ACCELQ concept

Test cases are the rows of data a Scenario runs with; each test case is one execution of the Scenario with its own values.

Bind a parameter to a Data Pool

Map the parameter to a pool and column

Open the parameter’s configuration from the Scenario (click the parameter, or use Configure Parameters). In the Parameter Configuration dialog, set Value comes from to From a Data Pool, choose the Data Pool and the Column that fills the parameter, and choose Save.

Map each parameter that should come from the pool the same way. Parameters mapped to the same pool draw from the same record by default, so an MSISDN and an ICCID parameter mapped to a SIM pool both come from the same SIM.

Choose the Data Class for each test case

A pool holds many records, so each test case states which kind it wants. Open the Test Cases grid for the Scenario and find the pool’s column under the Data Pool Records group. In each test case row, click the cell and choose a Data Class such as 5G, or choose Any to accept any record of the pool. A cell left unset is shown as a prompt, so it is clear a choice is still needed.

What happens at run time

For each test case, ACCELQ selects a record that matches the chosen Data Class and fills every mapped parameter from it. If the pool uses Record Scope & Variability, only records valid for the environment and variant of the run are considered (see Data Pools: overview and concepts). For a single-use pool the record is reserved (by changing the status to "allocated") so parallel runs do not collide, consumed when the test uses it, and released automatically if the test turns out not to use it.

Advanced mapping

Most tests (test cases) need one record per pool, chosen by its Data Class. Two advanced capabilities cover the cases that need more.

Use more than one record (for a given test case) from the same pool

Sometimes one test needs two records from the same pool, for example a current SIM and an upgrade SIM in a migration test. Open the configuration of a parameter that draws from the pool and choose Draw a separate record for this parameter. Give the new record a name, such as Upgrade SIM, and confirm.

[IMAGE: The record Edit dialog with multiple record selection.]

Once a pool supplies more than one record, the Parameter Configuration dialog shows a Record field for parameters mapped to that pool, so you can choose which record each parameter draws from. In the Test Cases grid each record gets its own Data Class to choose.

[IMAGE: The test case grid that shows two columns in the data pool columns group.]

Note 

A second record is only offered when the pool feeds more parameters than it has records. A new record needs a parameter to fill it, so you draw one only when there is a parameter to assign it to.

Match a record to a record in another pool

When a record must belong to another, such as a bill that belongs to the chosen account, set it to be chosen by matching instead of by its own Data Class. In the Test Cases grid, open the Data Pool Records panel with Manage, find the record in its pool’s records list, and choose Edit. Change Select the record to by matching a record selected from another pool, choose the matching record, and choose the two columns that must be equal: this record’s column and the matched record’s column. Save, and from then on the record is picked automatically to match its partner.

[IMAGE: The record Edit dialog with 'by matching a record selected from another pool' chosen, the matching record, and the two match columns.]

Note

ACCELQ prevents circular relationships, so a record cannot be matched to one that already matches back to it, directly or indirectly.

Review what a Scenario uses

The Data Pool Records panel, opened with Manage, is the one place that shows, for each pool, which parameters draw from which column, how many records the pool supplies, and any relationships. It is also where you rename records, set or change relationships, and remove records.

[IMAGE: The Manage panel showing a pool section with its parameter table and records list.]

Fetch pool data from Action logic

This is the second way to use pool data, for when your logic itself must fetch and act on data rather than receive it as a parameter: fetching a number of records decided at run time, fetching in a loop, or deciding mid-test whether, or which, record to fetch.

Related ACCELQ concept

Action logic is the no-code logic you build inside an Action using the Logic Editor and its commands. The Data Pool commands below are used there.

Commands for reading data

Every Data Pool command identifies the pool by its ID, shown for each pool in the Data Pools list. The ID never changes, so renaming a pool does not affect your logic.

• Fetch and consume a Data Pool record: reserves an available record (single-use pools) and stores a reference to it. Only valid for single-use pools.
• Read a Data Pool record (without consuming): selects a record without changing its status; valid on any pool.
• Get a column value from a Data Pool record: reads one column off a record you fetched; call it for each column you need.
• Fetch and consume a matching Data Pool record: the relationship case, in logic.
• Get count of available Data Pool records and Verify available Data Pool records is at least: guards before you fetch.

Example

In the Logic Editor the steps read as plain sentences. Here DP-1042 is the ID of a Prepaid SIMs pool:

You never handle record IDs yourself; the reference a fetch returns is passed straight to the next command.

Settling reserved records

In an automation run, consuming a record thru Parameter binding releases an unused record for you; with commands, settling the record is part of your logic. Fetching with mark as Used, the default, settles the record at the moment it is fetched and is the safe choice. If you choose keep reserved, add a Release a Data Pool record or Mark a Data Pool record as Used step later in the same logic, placed so that every path through the logic reaches it, so the record is settled once the test is done with it.

Use pool data in manual testing

Binding parameters to a Data Pool applies to automated Scenarios. A manual tester takes a record straight from the pool instead, by allocating it so that no automated run or other tester uses it in the meantime.

Set a record aside and return it

1. Open the pool and find a Ready record of the kind you need; filtering by Data Class narrows the list.
2. Select the record, choose Change status, and set it to Allocated. It is now held, shown with you as the holder, and no longer counted as available.
3. Use its values in your manual test.
4. When you are done, select it again and use Change status to set it to Ready if the data is still usable, or Used if your testing consumed it.

This works the same in a project the pool is shared with: a tester there can change a record’s status in the same way.

The record stays allocated until its status is changed; nothing releases it automatically. Any user can return it, so a record left allocated by mistake can be returned by a teammate. Reusable pools need none of this: their records are never consumed, so a manual tester simply reads the record from the pool.

Best practices

Pool values or test case values

Both are data-driven, but not every value belongs in a Data Pool. The following is guidance, not a requirement. Data is usually a good fit for a Data Pool when:

• you select it by kind (any 5G SIM, any business account) rather than needing one exact value for one test case;
• it is reused across many Scenarios or test cases, so a single managed source is worth having;
• it is consumed and must not be handed to two runs at once, such as SIMs or one-time codes, where the pool manages allocation for you;
• a record has several fields you use together, not a single value;
• it changes when environments are refreshed and benefits from central maintenance.

Keep the value in the test case when it is specific to that test case, such as an expected result or a one-off input. If it is a single value every test case should share, it is not data-driven at all: use a fixed value or a Global Property instead (see Data Pools: overview and concepts).