Tabular Variables are a simple way to inject dynamic data into your test steps. Within a test step, these variables act as placeholders which are replaced with data when a tester executes one of your tests. This allows you to effortlessly assign each tester a unique value.

How to use tabular variables

Within the step editor, click '{} step variables' to bring up the step variables menu:

Click on any of the step variable groups to reveal all the step variables within it:

Last, click the variable you wish to insert.

Adding new tabular variables

To add new tabular variables, open the "Step Variables" settings page and click on the "Add New" button in the "Tabular Variables" section.

  • Enter a name for your variable group, consisting of letters, numbers, and underscores. Spaces and special characters are not supported at this time.
  • Enter a description for your tabular variable so that all members of your team can understand at a glance the purpose and intent of this variable.
  • Last, select "Choose a file'' under the 'File' row to select the CSV file* for the tabular variable. Each row will be converted into a new tabular variable, named in the pattern #{{variable_group_name.header_name}}.

For example, a new tabular variable group named "logins" from the CSV file below would automatically contain two new tabular variables; #{{}} and #{{logins.password}} (note the names from the required header row):

Once created, you can edit or remove tabular variables as needed by clicking Edit or Delete on the right-hand side of each variable in the list.

Note: To avoid disrupting your test runs, you must send through sufficient variables for each tester to have a unique variable. You can calculate the number of variables needed according to the instructions in the following section.

Don't hesitate to get in touch with us for any further details or help.

How many Step Variables do you need?

When a test is initiated, each tester will be assigned one unique row of variable values, which will be repeated any time the placeholder is used again within a specific test. To ensure that you will have sufficient variables for your testers, we use the following equation:

Recommended minimum number of variable rows:

Tests * Browsers/Platforms * 6 Testers 

  • tests = number of tests using this variable
  • browsers/platforms = number of browsers or platforms you're running the tests against
  • testers = number of testers we send to each test

For example, to successfully run a Signup test against 3 browsers and 2 mobile device types, the minimum number of step variables we recommend would be 30 (1 Test * 5 browsers/platforms * 6 testers).

How are they assigned?

Variables are randomly assigned and will not repeat per run unless they have been marked as reusable.

Note that marking variables as reusable can have a significant impact on your test result time. Reusing variables causes a sort of gate system of "One out, one in" for your testers.

For example, if you have two login variables, but three testers, the third tester will not be able to proceed with the test until one of the first two has finished. In terms of speed, it is always best practice to add more rows of variables rather than listing something as reusable.

Common use cases

The most common use-case for tabular variables is assigning unique login credentials to each tester a unique login to avoid any shared state** issues arising from the different testers' actions.

Once you're familiar with how step variables work, you can use them for any set of data that you wish to test against. A few ideas:

  • Login credentials
  • Unique account information
  • Product category codes
  • Educational course names

There are endless use-cases, so please get in touch if you're not sure where to take advantage of tabular variables.

* Rainforest assumes that all tabular variable files are encoded in UTF-8. As such, please ensure that the files provided are encoded in UTF-8.
** Shared state refers to when two people—testers in our case—are trying to use the same account at the same time. For example, imagine two testers trying to update a Facebook profile picture at the same, one may very likely over-write the other. This causes intermittent and unexpected failures and can be avoided.

Did this answer your question?