Group interchangeable Authenticated Profiles into a pool, and name the pool in the Inject Profile step. Each Test Run then takes its own free Profile from the pool and keeps it until the run ends, so parallel runs stop signing each other out. A pool is the answer when your application allows one session per account, or when your Test Cases change the state of the signed-in user.
Without a pool, Test Runs that inject the same Profile share one account, and Exclusive makes them wait for each other. A pool of ten Profiles lets ten Test Runs go at once.
Before you start
Record one Authenticated Profile per test account, for example buyer-01 to buyer-10. Every account in a pool must have the same rights in your application, because any Test Run can get any of them. See How do I make my tests start already signed in?
Create a pool
Open your Test Project, select Configure, then Settings, and open the Authenticated Profiles tab.
Select New pool.
Enter a Pool name, for example
buyer. Profiles and pools share one list of names, so a pool cannot take the name of a Profile.In Profiles, select the Profiles to add.
Select Create pool.
The pool appears under Pools, above the Profiles. The Profiles that belong to a pool leave the main list. Select Show pool members to list them again.
Use the pool in a Test Case
Add an Inject Profile step at the top of the Test Case.
In Profile or pool, pick the pool. Pools are listed under Pools, above the Profiles.
Save the step.
The editor confirms the choice: "This step takes one free profile from the pool buyer." A pool always reserves its Profile for one Test Run, so you do not turn on Exclusive.
Each Test Run takes the free Profile that was used the longest time ago. It keeps that Profile until the run ends or until its next Inject Profile step. No other Test Run uses the Profile in the meantime.
A Capture Profile step writes to one Profile, so it names a Profile and never a pool.
When every Profile is in use
A Test Run that finds no free Profile waits, and takes the next Profile that another run frees. A run that waits more than 15 minutes fails. To run more Test Cases at once, add more Profiles to the pool.
When a session no longer works
When a Test Run injects a Profile and your application does not keep the user signed in, that Profile shows Session rejected. The pool skips it until somebody records the Profile again under the same name, so one dead account does not fail random runs. When every Profile of the pool is rejected, the step fails at once and names the Profiles to record again.
Read the pool page
Select a pool to open its page. It shows how many Profiles are Free, In use and waiting, and lists each Profile with its state:
State | What it means |
Free | The Profile is ready for the next Test Run |
In use | A Test Run holds the Profile. Select Open run to see it |
Session rejected | The last Test Run that injected it did not stay signed in. It is skipped until the Profile is recorded again |
Next pick marks the Profile the next Test Run takes. Below the Profiles, Runs waiting for a free profile lists the runs in line.
From the pool page, you can Add profiles, Remove from pool, Rename pool and Delete pool. Removing a Profile, or deleting the pool, keeps the Profiles themselves. Renaming or deleting the pool breaks the Inject Profile steps that name it, so update those steps in the same sitting.
Frequently asked questions
How many Test Runs can a pool serve at once?
One per Profile in the pool. A pool of ten Profiles serves ten Test Runs at once, and further runs wait for a free Profile for up to 15 minutes.
How do I bring back a Profile that shows Session rejected?
Record it again under the same name from the Authenticated Profiles tab. The pool uses it again from the next Test Run.
How do I keep the sessions of a pool fresh?
Leave Renew the saved session on in the Inject Profile step. Each Test Run then saves the session the application returned into the Profile it used.
How do I use another account on one Environment?
On that Environment, record a Profile with the same name as the pool. A Test Run on that Environment then injects that Profile instead of the project pool, and every other Environment keeps the pool. The record dialog says so before you save.
Do Schedules and CI runs use the pool?
Yes. Every Test Run takes its own Profile from the pool, whatever started it.