Assign manual test cases to testers
Distribute the manual half of a plan across your team by load and area affinity — and re-run it safely without reshuffling anyone's queue.
Once a plan is classified, the automated cases take care of themselves in CI. The manual ones need a person, a due date and a queue they can actually work through — and that distribution is the part teams usually do in a spreadsheet and then lose.
Assign a plan version
Publish the plan version first. Assignment works against a version, so the cases being distributed are pinned at known revisions.
Open the version and choose Assign manual cases.
Pick the candidates. Members with the tester role are offered by default; you can add or remove anyone, and "any agent" is a valid target.
Set a due date if the run has a deadline. Overdue state is computed from it and shown at the top of each tester's queue.
Confirm. BugMojo creates or reuses the manual run, attaches the assignments, and each tester's list appears under their own queue.
How the balance is decided
The database supplies three facts — which cases are in scope, who is available, and who has executed cases in each feature before — and the decision itself is a pure function over them. That is why it behaves predictably and why the guarantees below are testable rather than aspirational.
- Load — open assignments each candidate already holds. The lightest queue takes the next case.
- Area affinity — who has previously executed cases in the same feature, read from result history. Familiarity beats a perfectly even split by one case.
- Nothing vanishes silently — an automated case, a case from another project, a soft-deleted case or an unknown id is reported by name as a warning.
The tester's queue
Each tester sees their own list grouped by plan version, overdue first, with the step count and the run each assignment belongs to. Statuses move ASSIGNED → IN_PROGRESS → DONE, with BLOCKED available when something outside the tester's control is in the way.
Executing a case is covered in run a manual test with the extension — the evidence it captures is the reason the assignment is worth tracking at all.
Testers without a seat
Client QA and contractors often should not have an account. A signed tester link solves that without widening anything: the token names one company, one project, an explicit list of assignment ids and an expiry, and verification requires both a valid signature and a live registry entry — so revoking is a single write that takes effect on the next request.
From the run, choose Invite a tester and select the assignments the link may touch.
Set an expiry, and optionally the email address it is issued to.
Send the link. The tester executes their cases with full evidence capture and consumes no seat.
Revoke it the moment the engagement ends. A revoked link stops working immediately, even though it has not expired.
From an agent
assign_test_cases balance manual cases across members (or explicitly)
list_my_test_assignments the tester queue: grouped by version, overdue first
suggest_run_scope rank cases for SMOKE / CORE / FULL / RISK_BASED
create_scoped_run turn that scope into a run and place its casesCommon questions
What happens if I run the assignment twice?
Nothing moves. A case that already has an open assignment in the same scope is skipped and reported as a warning, so nobody's queue is reshuffled mid-run.
Can I assign work to an AI agent instead of a person?
Yes. Assignment uses one polymorphic assignee field, and "any agent" is a valid target that puts the work in the shared agent inbox.
Does a contract tester need a paid seat?
No. Issue a signed tester link: it names the exact assignments it may touch, expires, is revocable in one write, and consumes no seat.
Why was a case skipped with a warning?
Automated cases, cases from another project, soft-deleted cases and unknown ids are each reported by name. The tool always says what it did not do.
Related articles
- Run a manual test with the extensionTest Run mode records replay, console, network and a screenshot per step while you work — the same evidence a CI run produces.
- Manual vs automated: modes and reason codesEvery case gets a mode, a readiness score from 0 to 100, and named reason codes explaining exactly what is blocking automation.
- Test plans and versionsPublish a frozen v1 of your test plan, edit freely afterwards, and diff v1 against v2 when the next release ships.
- Client reports and sign-offTurn a published plan version and its runs into a shareable, hashed report a client signs — with their name on it, not an email thread.

