Test Scenario Combination Generator
A multi-user feature usually breaks between the users rather than inside any one of them. An approval that works for an Admin and works for a Manager can still fail when the Manager acts first, or when the same person holds two roles, or when a third user is present who should not be. Those are the scenarios this page writes out for you: give it the users in your system and their roles, and it produces every combination they can form, each one ready to become a test case.
Two modes, and the difference between them is whether order changes the outcome. Unique combinations treat User 1 + User 2 and User 2 + User 1 as one scenario, which is what you want when the question is simply who was involved — a permissions matrix, a visibility rule, a shared record. Different user orders treat them as two, which is what you want when sequence matters: who approved first, who locked the row, who opened the form before it was submitted.
Single users are included automatically in both modes. A scenario list that only covers pairs and triples quietly assumes the single-user paths are already tested, and those are the ones a permissions change breaks first.
Repeated users are optional and off by default. Turning them on allows the same user to appear more than once in a scenario — User 1 + User 1, or User 2 + User 3 + User 3 — which models a person acting twice in a workflow, holding two roles, or having two sessions open. Because a repeat has no natural end, that setting comes with a maximum number of users per scenario; without one the list would be infinite rather than merely long.
Combinations grow faster than they look. Three users produce seven scenarios in unique mode and fifteen when order matters; ten users produce a thousand and nearly ten million respectively. The count is shown before you generate, and a set too large to display or export is refused rather than started, because a browser tab that stops responding is a worse answer than a clear limit.
The second tab turns those roles into written test cases rather than combinations. Where the first asks which sets of users exist, this one asks what to do with two roles and what should happen — a scenario, numbered steps and an expected result, in the same seven-column shape the rest of this site generates. It works from the distinct roles in your list rather than the users, so four people who are all Admins are one role here, and it needs at least two different roles to produce anything.
Role combinations cover every pair and triple of your roles held by one user at once. What they check is that the user ends up with exactly the union of what those roles permit — never more, never less. Two failures hide here and both are quiet: a system that reads only the first role assigned, or only the highest, drops rights the user was actually granted, while one that treats having any role as having every right grants what nobody assigned.
Permission combinations are the narrower question of what happens when two roles disagree. One role permits an action, the other denies it, and the same user holds both. The expected result is whatever precedence your specification documents — and unless it says otherwise, the restrictive rule should win, for the action and for the field. If no precedence is written down anywhere, that is itself the finding: the behavior is currently whatever the code happens to do.
Multiple-user workflows and concurrent actions are the two ways a handover goes wrong. A workflow case walks one record through two roles in turn, in both orders, and checks that the first user sees the second user's change without signing out and that the history records who did each step. A concurrency case has both roles submit within a second of each other: either one is refused with a conflict the user can act on, or the two changes are merged deliberately. Silent last-write-wins is the defect — the first person is told it saved, and their work is gone with nothing to show it ever existed.
The output is built for turning into test cases rather than for reading once. Each scenario carries an identifier, the users in order, and their roles, and the whole set downloads as a real .xlsx workbook with the users and roles as separate columns so they can be filtered, counted or pasted into whatever your team writes test cases in. The Copy button produces the same data as plain text for a ticket or a pull request.
Everything runs in this tab. The users and roles you type are not sent anywhere, which matters more than usual here because real role names and real user names are the sort of thing that describes a system's access model.