Assigning Testers to Cases

Putting a tester’s name against cases happens on the run’s Cases tab itself — there is no separate assignment modal. Change one case with its assignee picker, or select a batch and assign them together from the bulk bar.

Assigning is not the same as choosing which cases are in the run. Run membership is composed in the test case repository — see Creating a Run, and Edit run… in an open run’s breadcrumb menu to change it later. This page is about handing cases that are already in the run to a person.

Who can assign

What the picker offers depends on two Test Runs permissions in your role:

• Create test runs — you assign anyone: any case, to any tester, or back to nobody.
• Execute tests without Create test runs — you pick up any open case, including one another tester already holds, and hand back only your own. The picker offers Assign to me, plus Unassign me on a case that is yours.
• Neither — the face shows who holds the case and opens the person card, but no menu.

Only people who can execute tests in the project can be assigned, so they are the only names the picker lists. The built-in roles carry both permissions, so this only changes anything for a custom role.

Both paths are optimistic — the rows update as you click rather than waiting on the server. If the server refuses the change, the row goes back to what it was and a message says why: You can’t assign testers in this project, or <name> can’t be assigned: they can’t execute tests here for someone whose role changed after the list was loaded.

Assigning one case

The assignee avatar on the row is itself the picker — click it (or tab to it and press Enter) to open a menu of the people who can execute tests in the project, with a tick against whoever holds the case now. Choose a person and the row takes their avatar; choose No assignee, the first item in the menu, to clear it.

The face is also the person: hover it, or focus it with the keyboard, and after a moment a card shows the tester’s name and avatar with Tester on C-12 — the same card the Created by face shows on Test Cases. Clicking still opens the assign menu, and the card and the menu never show together. An unassigned case has no card.

An unassigned case shows a neutral empty avatar — a dashed ring with a faint silhouette — rather than the word “Unassigned”, so the row reads the same width in every state. The same control appears in list rows, the table’s Tester column, and board cards. The Tester column is 72px wide and shows the face only, like the Created by column on Test Cases. Without either permission, or on a closed run, the face is still shown and still opens the person card, but clicking it opens no menu.

Assigning several at once

1. Open the run and go to its Cases tab.
2. Narrow the list to the cases you want to hand over — see Finding the set below.
3. Tick the checkbox on each row you want. The bulk bar rises from the bottom of the viewport showing N cases, with an inline × to clear the selection (or press Esc).
4. Click Assign in the bulk bar. Its menu is headed Assign to · N selected and lists the people who can execute tests in the project. With Execute tests alone it offers Assign to me instead, and Unassign me only when every selected case is yours or unassigned and at least one of them is yours.
5. Pick the person. The rows update straight away.

Handing work back to the pool. The last item in the Assign menu is Unassign (Unassign me with Execute tests alone). It clears the tester from every selected case in one action.

The bulk bar also carries Set result (with Clear result) and Remove from run — see Bulk results. Each action has its own permission: Set result needs Execute tests, and Remove from run needs Create test runs. With Create test runs alone the bar offers Assign and Remove from run; with Execute tests alone, Assign and Set result. Without either, rows have no selection checkboxes.

Finding the set you want to hand over

Because you assign over the rows on the tab, the work is in narrowing the tab first. The Cases tab toolbar gives you several ways to do that, and they combine:

• Folder jumper — scope the list to one of the run’s folders, including everything in its sub-folders. All cases clears the scope.
• Quick-filter chips — All, Untested, Failed · Blocked, and Mine, each with a live count.
• Search — match on case title within the run.
• Filter — the property fly-out (shortcut f), covering built-in facets and your workspace’s enabled custom fields. Active choices show as removable chips below the toolbar.

Narrowing with the folder jumper, a quick-filter chip or a filter loads the rest of the run first (up to 500 cases), so the rows you select come from the whole run, not just the first 100 — see how cases load. See Run Detail for the full toolbar reference.

Common patterns

Hand a folder to one tester

Scope the list to the folder with the folder jumper, select the rows, then Assign. Cases in sub-folders are included in the scope.

Give all the failures to one person for retest

Click the Failed · Blocked quick-filter chip, select the rows, then Assign.

Take an assignment back

Select the cases and choose Unassign from the Assign menu.

A closed run cannot be reassigned. Closing a run drops the selection checkboxes and the assignee pickers, and the per-case runner’s rail reads Run is closed — reopen to reassign. Reopen the run first.