Test case review lets your team check new test cases and changes to existing ones before they reach the repository. Instead of saving, the author sends the case to review; the repository keeps the case as it was until the review request is merged.
Test case review is available on the Pro and Enterprise plans (and during a trial).
Turning review on
Open the project’s Settings and the Repository tab. Turn on Review enabled, then choose how reviews work in the project. While review is off, the other settings are hidden and have no effect.
| Setting | What it does |
|---|---|
| Review is mandatory | Every new case and every change to a case must be sent to review. When off, authors can save directly or send to review. |
| Allow self-merge | The author of a review request can merge it once it has the approvals it needs, even without permission to review test cases. |
| Approvals required | How many approvals a request needs before it can be merged. 0 means no threshold. |
| Auto-merge | Merges a request as soon as it reaches the approvals required, unless a reviewer has requested changes. Needs at least 1 approval required. |
| Default reviewers | Assigned to every new review request in the project. Only members with access to the project who can review test cases can be added. |
| Only approved cases can be added to runs | Runs take in only test cases whose review status is Approved. See Only approved cases in runs. |
Anyone who can open the project can see these settings. Organization owners and administrators, and the project’s owner, can change them. Every change is recorded in the activity log. A default reviewer who leaves the organization, loses access to the project or moves to a role that cannot review test cases stops being assigned.
The buttons on the test case form
The buttons at the bottom of the form for a new case or for editing a case follow the project’s settings:
| Project setting | Buttons |
|---|---|
| Review off (or a plan without review) | Cancel, Save and create another, Save |
| Review on, Review is mandatory off | Cancel, Save and create another, Send to review, Save |
| Review on, Review is mandatory on | Cancel, Send to review |
Save and create another appears only on a new case.
Where mandatory review applies
When review is mandatory, the rule also covers the other ways a case reaches the repository:
| Where the change comes from | What happens |
|---|---|
| + Quick create case in the repository | The new case is sent to review with the project’s default reviewers, and the confirmation shows the request ID. |
| A case’s detail panel | Its fields can’t be edited in place. Click Edit case to open the form and send your change to review. |
| Importing a file | No case is written: each new case becomes a New case request and each replaced case an Update request. A case that already has an open request is skipped and listed. |
| The API and the MCP server | Creating a case, or saving a whole case, opens a review request instead. Other direct edits (steps, custom field values, restoring a version, converting or detaching shared steps) are refused. |
| Duplicate, and copying cases or suites into the project | Refused. |
| Archive in a case’s panel, and Delete in the selection bar | The cases are not archived: each gets an Archive case request instead. See Archiving and deleting through review. |
| Deleting a case through the API or the MCP server | The case is not deleted: a Delete case request is opened instead. |
| Restoring a case from the trash | Takes effect right away: it brings the case back as it was. |
| Deleting a suite with its cases | Refused while the suite or one of its sub-suites still holds a case that is not archived. Archive its cases through review first; an empty suite, or one with only archived cases, is deleted. |
A case keeps its content until a request for it is merged.
Cases synced from Git are not reviewed here. The pull request that changes their .feature file is their review, so their scenario is read-only in Probara. See Syncing feature files from Git.
Sending a case to review
- Fill in the case, or make your changes to an existing one.
- Click Send to review.
- Choose the reviewers. The list starts with the project’s default reviewers; you are never a reviewer of your own request.
- Click Send to review in the dialog.
The request gets an ID such as RV-3, shown in the confirmation, and its page opens. A new case
does not appear in the repository yet, and an existing case keeps its current content: the proposed changes are applied
when the request is merged.
Images you add to steps travel with the request and are kept for as long as it is open.
Asking for a review of cases as they are
You can also ask reviewers to approve cases you don’t want to change, for example to approve cases written before review was turned on:
- In the repository, select cases and click Send to review in the selection bar.
- In a case’s detail panel, click the Request review button. It is shown for a case whose review status is Not reviewed.
Choose the reviewers once (the list starts with the project’s default reviewers) and click Send to review. Each case gets its own request, of kind Review current version. Its page shows the case as it is instead of a list of changes. Merging it marks the case Approved without changing the case or adding a version to its history. If the case is saved directly in the meantime, the request cannot be merged until its proposal is updated.
Cases that already have an open request, and archived cases, are not sent; the confirmation lists them.
Archiving and deleting through review
Archiving and deleting a test case can go through review too:
- When review is mandatory, Archive in a case’s panel and Delete in the repository’s selection bar send the archiving to review: each case gets an Archive case request with the project’s default reviewers and stays active, In review, until the request is merged. Deleting a case through the API or the MCP server opens a Delete case request.
- When review is optional, a case’s panel also offers Send archiving to review next to Archive: choose the reviewers and the archiving waits for their approval.
An Archive case or Delete case request has no changes to compare: its page names the case and shows it as it is now. It cannot be edited. Merging it archives or permanently deletes the case; declining it leaves the case as it was. If the case was saved, or archived, after the request was made, it cannot be merged: decline it and send it again.
One open request per case
A test case can have only one open review request at a time. Sending another change for the same case is refused with a message naming the open request: send your change once that request is merged or declined.
If someone saved the case after you opened the form, sending it to review is refused the same way a save is: reload the case and make your change on its current version.
The Review section
The project’s sidebar always shows Review under Cases. When review is on, the number of requests waiting for your review appears next to it. If your plan doesn’t include test case review, Review shows the plans that do. If review is off for the project, the section says so and links to the Repository settings; requests opened before it was turned off stay listed and can still be decided. The section lists the project’s review requests under four tabs: Open, Assigned to me, Merged and Declined. Each request shows its ID, title and kind (New case, Update, Review current version, Archive case or Delete case), the case it changes, its author, its reviewers (hover an avatar to see who it is; open the request to see their decisions), and its approvals against the number required. Use Add filter to show only the requests of one Author, with one Reviewer or of one Type. The Update type also includes Review current version requests.
Assigned to me
Assigned to me lists the open requests you are a reviewer of that wait for your decision: ones you have not approved or requested changes on yet, and ones whose proposal was edited after your decision. The My decision column shows where you stand on each. Turn on Include requests I already decided to also see the open requests you have approved or requested changes on.
Click a request to open it. Its page shows the proposed changes against the case as it is now (for a new case, the whole proposed case), the reviewers with their decisions and notes, how many approvals it has, and its comments. Anyone who can open the project can see review requests.
Decline and Edit are at the top of the page. Merge, Approve and Request changes are in the panel beside the changes, above the reviewers.
Reviewing a request
What you can do on a request depends on who you are:
| You are | Actions |
|---|---|
| A member who can review test cases (not the author) | Merge, Approve, Request changes, Edit, Decline |
| The author, with Allow self-merge on | Merge, Edit, Decline |
| The author | Edit, Decline |
Edit is not offered on an Archive case or Delete case request.
- Approve records that you agree with the changes. You don’t have to be an assigned reviewer: approving or requesting changes adds you as one.
- Unapprove replaces Approve once you have approved the current proposal. It withdraws your approval, so an approval given by mistake no longer counts, without requesting changes.
- Request changes records that you want more changes before the request is merged. You can add a note, which is shown with your decision. Notes can hold formatting and images.
- Edit opens the case form with the proposed changes, so you can change them yourself. Saving replaces the proposal.
- Decline rejects the request after you confirm it. The case stays as it was and the proposed changes, with any images they added, are discarded. A declined request cannot be reopened.
- Merge applies the changes to the repository: a new case is created, or the case is updated.
While a request is open, its author and any member who can review test cases can change who reviews it: click Edit reviewers next to Reviewers. New reviewers are notified; a reviewer you remove loses their decision.
Merge is available once the request has the approvals the project requires, or right away when the project requires none. Until then the button is disabled, and the reason is shown under it. Your own approval never counts toward a request you sent.
A case updated by a merge shows the version as Merged from review in its History tab.
Deciding on several requests at once
On the Open and Assigned to me tabs, select requests with their checkboxes and choose Approve, Request changes or Decline at the bottom of the page. To request changes or decline, a comment is required: it is shown on every selected request, with your decision or as the reason it was declined. Each request is handled as if you had acted on it alone: requests you cannot act on, such as your own, are skipped and listed in the confirmation, and an approval can merge a request when Auto-merge is on.
When you decline a single request you can also add a note; it is shown on the request.
Edits reset approvals
Approvals and requests for changes belong to the version of the proposal they were given on. When someone edits the proposal, earlier decisions stay visible as Outdated but no longer count: the request needs its approvals again.
When the case changes meanwhile
If someone saves the case after the request was made, the request shows a warning and Merge is blocked, so the merge never overwrites changes the reviewers did not see. Click Edit and save the proposal: it is then made on the case as it is now, and can be reviewed and merged again.
Auto-merge
With Auto-merge on, the approval that brings a request to the approvals required merges it right away, as long as no reviewer has requested changes on the current proposal. If the merge cannot go through, for example because the case changed meanwhile, the request stays open with the approval. If the merge fails for another reason, the approval is still recorded and you are told that the automatic merge failed; merge the request again from its page.
Turning review off
Turning Review enabled off stops new requests, but the open ones are kept: they can still be reviewed, merged or declined from the Review section.
Review status
Every test case has a review status, shown as a chip in the case’s header and as an icon on its row in the repository while review is on in the project:
| Status | Meaning |
|---|---|
| Not reviewed | The case never went through review, or it was changed directly since. |
| In review | A review request for the case is open. |
| Approved | The case’s current content was merged from a review request. |
The status changes on its own:
- A case you create directly is Not reviewed; a case created by merging a New case request is Approved.
- Sending a change to review makes the case In review; merging it makes the case Approved.
- Declining a request puts back the status the case had before it was sent to review.
- Saving the case directly with changes, restoring an earlier version from its History, or importing over it makes it Not reviewed again. Saving it without changing anything keeps its status. A copy made with Duplicate starts as Not reviewed.
- Merging an Archive case request archives the case and keeps the status it had before the request.
To find cases by status, add the Review status filter in the repository’s filter bar, or use the
reviewStatus field in a query.
Only approved cases in runs
With Only approved cases can be added to runs on, a run takes in only test cases whose review status is Approved:
- Cases you pick yourself, in the New test run dialog or when adding cases to a run, must all be approved. The case picker lists only approved cases, and the dialog points out any selected case that is not approved so you can remove it.
- When a run takes cases from a test plan or from the run you run again, cases that are not approved are left out, and you are told how many.
The option has an effect only while Review enabled is on. Results that CI tools report are not affected: they record tests that already ran.
Comments on a request
Below the proposed changes, each request has a Comments thread that works like the comments on a test case: write, reply, pin a comment, and type @ to mention someone. Anyone who can open the project can read the comments; members and above can write them. The thread stays open after the request is merged or declined, so the discussion behind a change stays with it.
When a test case is deleted
Deleting a test case keeps its review requests and their comments. Its open request, if any, is declined automatically, shows Declined because its test case was deleted, and its participants are notified. Every request about the case still names it, as Deleted case followed by the case’s ID and title.
Review notifications
Review requests notify the people involved through the Review group of your notification preferences:
| Preference | You are notified when |
|---|---|
| Test reviews that I have been assigned to | You are made a reviewer of a request, when it is sent (default reviewers included) or reviewers change |
| Decisions on reviews I participate in | Someone approves, requests changes on, declines or merges the request, including an auto-merge |
| Edits to reviews I participate in | Someone edits the proposal |
| Comments on reviews I participate in | Someone comments on the request |
| New mention in a comment | A comment on a request mentions you, or an edit of a comment adds you |
You participate in a request when you are its author, one of its reviewers (approving or requesting changes makes you one), or have commented on it.
Bulk actions send one notification for the whole batch instead of one per request: sending several cases to review tells each reviewer how many reviews they were assigned to, and opens Assigned to me; deciding on several requests at once tells each participant, for example, that Ana approved 12 review requests, and opens the Review list. Actions on a single request keep their own notification. When a comment mentions you, you get only the mention, not the comment notification too. You are never notified about your own actions, and only about projects you can still open.
By default the assignment, decision and mention rows reach you in the app and by e-mail; edits and comments reach you in the app only.