The Expert Validation Workflow — How to Review Test Cases Before Execution
How Evaficy Smart Test's built-in review step works — the real draft/pending/approved/rejected states, who can submit and who can review, and what actually happens after a decision.
For QA Engineers submitting scenarios and Owners, Product Owners, and Tech Leads reviewing them.
Why Validate Before Executing?
Executing an unreviewed scenarioA saved collection of test cases for a specific feature or user flow — for example, "User Registration" or "Checkout Flow". In Evaficy Smart Test, scenarios are the core unit of organisation: they are created from acceptance criteria, submitted for expert validation, reused across test runs, and used to track coverage over time. A good scenario covers the happy path, negative paths, and key edge cases for the feature.Full definition → is like shipping unreviewed code — it might be fine, but nobody checked. A validation step catches scenario design flaws before execution time gets spent on them, and separates the person who wrote the test cases from the person confirming they're technically sound and aligned with what the business actually asked for.
This matters most right after AI generation: an AI-generated test suite can look complete while still missing an edge case only a Tech Lead would catch, or covering the letter of an acceptance criterion while missing its intent — something a Product Owner is better placed to notice.
Submitting for validation doesn't block you
Test cases can still be edited while pending review, and a scenario doesn't need to be fully approved before you look at it again — validation runs alongside your work, not in front of it.
Want expert sign-off on your own scenarios?
Validation is included on Advanced and Enterprise plans — start a project and try it with your team.
The Real Model: Draft → Pending → Approved or Rejected
Each test case in a scenario carries its own validation status. There's no separate "under review" or "changes requested" stage — it's a straightforward four-state model:
Draft
Pending
Approved
Rejected
"Pending" is the only real waiting state — approval or rejection are the two possible outcomes once a reviewer looks at it. When a reviewer rejects a case, they can attach a note (up to 500 characters) explaining what's wrong. That note is the mechanism for requesting changes — there's no separate status for it.
Editing an approved or rejected case resets it to Draft
If you edit the content of a test case after it's been approved or rejected, its validation status silently resets to Draft and it drops out of the reviewer's queue until it's resubmitted. This is easy to miss — a scenario you think is "approved" can quietly stop being approved the moment someone tweaks a step, and it won't get re-reviewed until someone notices and resubmits it.
A scenario doesn't have its own independent status — it's derived from the test cases inside it: none (nothing submitted yet), pending, partial (a mix of approved and rejected cases), or fully approved / rejected.
Who Can Submit, Who Can Review
Submission and review are held to very different standards on purpose.
Who can submit
Any project member — submission is not role-restricted. It happens either by checking "Request validation for this scenario" in the Save Scenario dialog, or by clicking the "Validate" button on an already-loaded scenario.
Who can review
Only a project's Owner, Product Owner, or Tech Lead can approve or reject a test case. QA EngineersThe project role responsible for writing and executing test cases. A QA Engineer can create scenarios and submit them for expert validation, but — unlike the Owner, Product Owner, or Tech Lead roles — cannot approve or reject a validation request themselves. This keeps the person writing a scenario separate from the person signing off on it.Full definition → cannot — the same person who writes a scenario is never the one who signs off on it.
The TL/PO split is a convention, not a system rule
You'll often hear "Tech Leads review technical correctness, Product Owners review business alignment" — that's genuinely how most teams divide the work, but it's a team convention, not something the platform enforces. Both roles (and the project Owner) have identical approve/reject permissions; the system doesn't restrict either of them to a specific kind of check.
The Validation Queue — What Reviewing Looks Like
Reviewers work from a single screen: the Validation Queue at /validation.
Open the Validation Queue
Reviewers open the /validation page and filter by project. It lists every scenario currently sitting at Pending, grouped into an accordion — one entry per scenario, with its test cases inside.
Review individually or in bulk
Each test case can be approved or rejected on its own, or a reviewer can use "Approve All" / "Reject All" on the whole scenario at once when every case is in the same state of readiness.
Add notes on rejection
Rejecting a test case opens a confirmation dialog with an optional notes field (up to 500 characters) — this is where a reviewer explains what needs to change. There is no separate "request changes" action; a clear rejection note is what fills that role.
The scenario status rolls up automatically
A scenario's own status is derived from its test cases: none of them submitted yet, some pending, a mix of approved and rejected ("partial"), or fully approved / fully rejected. You don't set the scenario status directly — it reflects the state of the cases inside it.
What Happens After a Decision
A reviewer's decision doesn't just update a status field silently — it's surfaced in a few places so nothing gets missed.
Once a scenario is fully approved or fully rejected, the person who submitted it gets a notification — they don't have to keep checking the queue to find out what happened to their work.
Availability by Plan
Expert validation is not included on the free Basic plan — Basic users see an "Upgrade to Advanced" prompt where the Validation Queue would be. It's included on Advanced and Enterprise plans, with no separate feature toggle beyond the plan itself.
Where this fits in your plan
If your team is on Basic and wants a second set of eyes on scenarios before execution, expert validation is one of the concrete reasons to move to Advanced — along with custom fields and a larger project/team allowance.
Related guides
How to Set Up a QA Project from Scratch
Where the "Request validation" checkbox lives — as part of saving your first scenario.QA Test Run Execution: A Step-by-Step Guide
What happens once a scenario is approved and ready to execute.Acceptance Criteria — The Foundation of QA
What reviewers are actually checking a scenario against.QA Team Roles & Best Practices
The full role breakdown — Owner, Product Owner, Tech Lead, QA Engineer.Get a second set of eyes on every scenario
Expert validation is included on Advanced and Enterprise plans — submit scenarios for review and track decisions in one place.
See Advanced & Enterprise plansFree Resource
This topic is covered in the QA Leader’s Handbook
A free 10-chapter PDF guide for Tech Leads and Product Owners.