Test case review works a bit like a pull request for your test repository. An author submits a new or updated test case, one or more reviewers evaluate it, and only after approval can the changes be merged into the repository. This prevents untested, incomplete, or poorly structured cases from reaching your test runs.
Review is configured per project, so you can enforce it strictly in regulated projects while leaving it optional in exploratory ones.
Configuring review settings
Open Project settings → Repository and configure the review options, then click Update settings:
Setting | Effect |
Review enabled | Team members can optionally send test cases to review. |
Review is mandatory | All test case changes must go through review — the direct Save button is removed. |
Allow self-merge | Allows the review author to merge their own changes (subject to approval requirements). |
Auto-merge | Merges a review automatically as soon as it collects all required approvals. Off by default. |
Approvals required | Sets the number of approvals needed before a review can be merged. |
Default reviewer | One or more team members who are assigned automatically when an author sends a case to review without choosing a reviewer. |
We recommend enabling mandatory review for any project where test cases drive compliance or release decisions. For fast-moving exploratory projects, optional review is usually enough.
Setting default reviewers
Default reviewers save authors from picking a reviewer every time. In the Default reviewer field, use Search for reviewers to add one or more team members, remove anyone you no longer want, and click Update settings.
When an author sends a case to review without choosing a reviewer, every default reviewer is assigned to it. If the author does choose reviewers, their choice is used instead.
A default reviewer is skipped, rather than assigned, when they are the author of the review, or when they can no longer approve reviews in the project — for example, because their role changed or they lost access to the project. Such a member is marked in the list with a hint so you can replace them.
Anyone who can open Project settings → Repository can change the default reviewers.
The review workflow
Submitting for review
Create or edit a test case in the repository.
Instead of saving directly, select Send to Review and choose your reviewer or reviewers — you can nominate several reviewers at once. If the project has default reviewers, you can leave the reviewer empty and they are assigned for you.
The case appears in the Review section with a type label:
New case — a brand-new test case entering the repository.
Update — changes to an existing test case.
When review is mandatory, the Save button is replaced entirely — Send to Review is the only option.
Reviewing a submission
Open any review from the Review section to see exactly what changed, down to individual words, along with comments from other reviewers.
Where the case lives: directly under the review title, the page shows the full suite path of the test case being reviewed. Each level of the path is clickable and opens that suite. When the review moves a case to a different suite, the suite block shows the suite tree as well, so the new location is clear.
What's highlighted:
Changed words in the title, description, preconditions, postconditions, step fields, and text custom fields.
Added, Deleted, and Modified badges on individual steps, including steps that were moved.
Tags, attachments, and select fields, shown as whole values rather than word by word.
Parameter groups, shown in a table.
Shared steps, grouped under their step name.
Converting a case between Classic and Gherkin format is shown as one whole change, not broken down word by word.
The same highlighting appears anywhere test case changes are shown: the review page, case change history, and requirement revisions.
Reviewer actions:
Action | Purpose |
Approve | Cast your vote in favor. The review is not merged yet unless this is the last required approval and auto-merge is on. |
Request Changes | Signal that the case needs work. This is a status indicator visible to all reviewers and the author. |
Edit | Suggest modifications directly within the review. |
Merge | Accept the changes into the repository. Only available when all approval requirements are met. |
Decline | Reject the review entirely. |
Author actions:
Edit — revise the case based on feedback and resubmit.
Merge — available only when self-merge is enabled and required approvals are met (or no approval count is set).
Decline — withdraw the review.
Both authors and reviewers can leave comments throughout the process.
Staying informed: when anyone approves, requests changes, edits, merges, declines or reopens a review, and when a review merges automatically, the author and every reviewer are notified in-app and by email. The person who took the action is not notified of their own move. These notifications are on by default; each person can turn them off under Test Review in their notification preferences.
Merging
Once the required approvals are met, any authorized user can merge. For new cases, the test case appears in the repository. For updates, the reviewed changes replace the current version.
Note: If self-merge is enabled but an approval count is set, the author still cannot merge until the required number of approvals is reached.
Merging automatically
With Auto-merge on, nobody has to remember the final Merge click. The moment a review receives its last required approval, its changes merge into the test case, and the reviewer's page updates straight away to show the merged review.
Auto-merge needs Approvals required set to at least 1 — the setting cannot be saved with auto-merge on and no approvals required.
A review that has all its approvals still waits for a manual merge when:
A reviewer has an outstanding Request Changes. Once that reviewer withdraws it, the review merges automatically if every required approval is in place.
The approval was given on an older version of the proposal. If the author edits the review while a reviewer has it open, that reviewer's approval of the older version is not counted, and they need to approve the current version.
The person whose approval completes the review does not have permission to save test cases in the project.
The audit log, notifications, and the review merged webhook all show whether a review was merged automatically or by hand.
Projects that do not turn on auto-merge keep working exactly as before.
Review API
Reviews are also available through the Qase API: list and filter reviews, get a single review with full details, create a review for a new or existing case (up to 100 in one call), update an open review, and delete a review.
Approving and merging still happen in the UI only — the API does not cover those actions.
See the Reviews API reference for endpoints and parameters.
Permissions
The ability to review, approve, and merge is governed by workspace roles. Ensure reviewers have the appropriate permissions in their role configuration. Owners and administrators can review by default; for custom roles, grant review permissions explicitly.
FAQ
Can I review test cases in bulk?
Reviews are submitted per test case. However, you can view and manage all pending reviews from the centralized Review section in each project.
What happens to a test case while it is in review?
The existing version (if any) remains unchanged in the repository and can still be included in test runs. The reviewed version only takes effect after merging.
Does review work with imported test cases?
Imported cases land directly in the repository. If you need them reviewed, edit them after import and send the update to review.
Why did a review with all its approvals not merge automatically?
Check that Auto-merge is on in Project settings → Repository, that no reviewer still has Request Changes set, and that the last approval was given on the current version of the review. If all of that holds, the person who gave the last approval may not be allowed to save test cases in the project — anyone who is can merge the review by hand.
Why was my default reviewer not assigned?
A default reviewer is never assigned to their own review, and is skipped if they can no longer approve reviews in the project. Open Project settings → Repository — a skipped member is marked in the Default reviewer list.