I have been in similar situation as you.
I have been testing authentiation scenarios for users with very different setup. Scenarios can change the state of the user (e.g., lock user out when invalid password is given 5 times in a row), so it was important to use different users for different scenarios. First idea was to create test users for each scenario, but in our case the process of creating a user and granting certain permission is often time-consuming, increasing test execution time significantly, and hard to automate. Instead, we have decided to find users matching prerequisities for certain tests in existing database.
Here's is how this works:
- Test framework finds a group of X users from DB and caches them in a pool available for all tests
- 1st test gets 1st user from the group, 2nd test gets 2nd user from the group, etc.. X-th test gets X-th user from the group, and then (X+1)-th test gets agains 1st user from the group. If you assume that each test uses only one user and number of tests that you can run in parallel is Y, then everything works fine only if Y <=X. Otherwise, two tests running in parallel can accidentally reuse same user at same time.
- It is very import that the test leaves the user in clear state after completion.
- There can be mutiple pools for different groups of tests, e.g., a pool of users with TFA, a pool of external users, a pool of users who can login only through SSO, etc.
Obviously, this work if pool of users can be coordinated between tests, e.g., all tests are run in the same JVM. However, in Jenkins you can have additional parallelism, where tests from job A and running in parallel to tests from job B but there is no simple way to share a coordinate user pools between those jobs. The way I solved it was grant each job a specific groupId.
This way the pool of users for job A gets first group of matching users from DB (1..X matching users from DB), the pool of users for job B gets second group of matching users from DB (X+1..2X matching users from DB), etc.