Test Run Execution — A Step-by-Step Guide
A practical guide to running manual test execution in a structured, evidence-backed way — covering how to read and execute each step, mark pass or fail, log defects with context, handle blocked cases, and read your results after the run.
For QA Engineers executing test cases and Tech Leads reviewing run results.
What Is a Test Run and How Is It Different From a Scenario?
A scenario is the definition — the collection of test cases for a feature area, each with steps, preconditions, and expected results. A scenario is the source of truth. It does not change between executions unless a team member edits it.
A test run is an execution session — a snapshot of one or more scenarios run against a specific version of the application, in a specific environment, by specific team members. A single scenario can be executed in many test runs: once after the initial build, again after a hotfix, again after a refactor. Each run produces an independent record of what was tested and what the results were.
Scenarios are reused. Runs are records.
Updating a test case in a scenario does not alter past run results. Run results are a permanent record of what was tested, when, with which test cases, and what the outcome was. This separation is what makes historical comparison and trend analysis meaningful.
Creating a Test Run
A test run brings together the scenarios you want to test, the environment you are testing against, and the team members who will execute the cases. Getting these three elements right before execution starts prevents the most common run setup mistakes.
Select scenarios and test cases
Choose the scenarios relevant to the change being tested. For a new feature release, include the feature scenario and any scenarios covering functionality that could have been affected. For a hotfix, include only the targeted scenario plus a smoke run of core functionality.
Specify the execution environment
Record which environment the run will test against — staging, pre-production, or production — and note the exact URL. Environment specifics attached at run creation stay linked to every defect logged in that run, giving developers immediate context when they investigate.
Assign test cases to team members
Distribute test cases across your QA team so execution can run in parallel. Assign cases based on each member's familiarity with the feature area. Unassigned cases can still be executed by any team member — assignment is for coordination, not restriction.
Executing Test Cases Step by Step
Test execution is not a reading exercise. Each step requires a deliberate action in the application, a comparison of what happened against what was expected, and an honest mark. The three habits below separate reliable execution from execution that misses bugs.
Pass means the actual result matched the expected result exactly — not approximately, not "close enough." If the system behaved correctly, mark it passed. If anything deviated — a missing validation message, an unexpected redirect, an incorrect value, a UI element in the wrong state — mark it failed.
The instinct to mark borderline steps as passed "because it mostly worked" is how bugs reach production. A system that partially meets the expected result is a system that fails the requirement. If you are uncertain, fail the step, record what you observed in detail, and let the defect review process determine severity and priority.
- When in doubt, fail and document. A false fail is easy to close with context. A false pass that ships is not.
- Mark each step independently — a later step passing does not retroactively validate an earlier questionable step
- If a step passes but produces an unexpected side effect, note it in the actual result field even while marking it passed
When you mark a step as failed, the actual result field is the most important thing you write in the entire execution session. It is what developers use to understand what to fix. An actual result that describes exactly what you observed — with specific values, URLs, and messages — makes the difference between a defect that gets fixed promptly and one that gets closed as "cannot reproduce."
Write what the system did, not your interpretation of what it means. "The form submitted without validating" is an interpretation. The example below shows what a developer-ready actual result looks like.
- Include exact values, error codes, and full URLs — not approximations
- Note any unexpected redirects, network requests, or system state changes that occurred as a result of the failure
- If a console error appeared, copy the exact text from DevTools — not from memory
Logging Defects During Execution
In Evaficy Smart Test, defects are logged in context — attached to the specific step where the failure occurred. This links each defect directly to the test case, scenario, and run where it was found. Every field you complete at the time of logging saves time later in triage, investigation, and re-testing.
Fail the step
Mark the step as Failed. This records the failure at the precise step where the system deviated from expected behaviour, giving the defect exact location context within the test case and the run.
Record the actual result
Enter exactly what the system did — the observable failure, with specific values, URLs, and messages. This is what developers use to diagnose the issue. The more precise your actual result, the faster the fix.
Add defect description, severity, and priority
Use the description field to add context not captured by the actual result: reproducibility (5/5 attempts, or intermittent), environment specifics, related defects, or known workarounds. Set severity based on system impact and priority based on business urgency.
Attach evidence links
Add links to screenshots, screen recordings, browser console exports, and external tracker tickets (Jira, Linear, GitHub Issues). Evidence attached at the step level stays permanently linked to the exact failure point — giving developers and re-testers complete context without searching.
Defects logged in execution stay linked to their test run
Every defect logged during a test run is associated with the specific test case, step, and run where it was found. When a fix is deployed and re-testing begins, the defect record — with its original actual result, severity, and evidence — is available in the same test case it was first detected in.
Handling Blocked and Skipped Test Cases
Not every test case will be executable in every run. Distinguishing between a blocked case and a failed case matters for accurate reporting — the two indicate different types of problems and require different responses.
Failed
You executed the step and the system behaved incorrectly. The deviation is observable and documentable. This is a defect.
- Use when you executed the step and the result was wrong
- Always log a defect with actual result, severity, and evidence
- A failed step is an assertion failure — the system violated its expected contract
Blocked
You could not execute the step at all. A dependency failed, a prior step left the system in an unrecoverable state, or required data or access was unavailable.
- Use when execution was impossible, not when it was wrong
- Always record the block reason: what was missing and why execution could not continue
- A blocked case is a coverage gap, not a defect — but it must be resolved before the run is considered complete
Blocked is not a softer version of Failed
Marking a step as blocked when it actually failed removes the defect from the tracking record. Blocked should only be used when execution was genuinely impossible. If the system responded incorrectly to your action, that is a fail — regardless of whether a later step could still be completed.
Monitoring Run Progress
As your team executes, the run summary updates in real time. The four status counts give you an immediate picture of where the run stands and where attention is needed.
Passed
Failed
Blocked
Not Run
Watch the blocked count as the run progresses. A rising blocked count that is not being investigated means coverage gaps are accumulating. A run that completes with a significant "not run" count is an incomplete run — results from it should not be used to draw conclusions about overall quality.
After the Run — Reading Results
The pass rate is the first number everyone looks at and the one most likely to mislead. A 90% pass rate in a run that skipped 30% of cases, or that only covered happy paths, tells you almost nothing about quality. Reading results accurately requires looking at what the numbers are actually measuring.
What a high pass rate can hide
A high pass rate is only meaningful if the run had strong coverage: representative test cases, full execution, and no significant blocked or not-run cases. A 95% pass rate on a run that only executed happy paths is not evidence of quality — it is evidence of limited scope. Look at the ratio of passed cases to total cases in the scenario, not just passed to executed.
Failure patterns worth investigating
Single isolated failures are usually defects. Failures concentrated in one test case or scenario area often indicate a deeper integration problem or a regression from a shared component change. If the same test cases are failing across multiple consecutive runs, the defect has not been fully resolved — or the fix introduced a new failure.
When to escalate vs. log and move on
Log and monitor: isolated failures in low-risk areas with known workarounds and low severity. Escalate: critical severity failures blocking core user journeys, failures that appear to be regressions of previously closed defects, or patterns of multiple failures in the same integration area that suggest a systemic issue rather than an isolated bug.
Re-testing After Defects Are Fixed
When defects are fixed and a new build is available, re-testing closes the loop. The goal is not to re-run the entire test suite — it is to verify that each specific fix works correctly and has not introduced a regression in adjacent functionality.
Re-test the original steps exactly
Follow the exact steps from the original run — not a similar flow, not a shortened version. A fix that resolves a simplified reproduction is not a confirmed fix. The original steps must produce the expected result before the defect can be marked closed.
Verify against the original expected result
The expected result in the test case is the standard for closure. The actual result must now match it exactly. If the expected result was imprecise when the defect was first logged, the re-test may be ambiguous — which is a reason to keep expected results precise from the start.
Test adjacent functionality for regressions
Fixes that touch shared components, business logic, or database state can introduce regressions in test cases outside the original failure path. After verifying the defect is fixed, run a targeted check of cases that share dependencies with the fixed area.
Reopen the defect if the fix is incomplete
If re-testing reveals the defect persists or the fix is partial, reopen the original defect with a comment describing what was observed in the re-test. Do not close it and log a new report — the history of the original defect is valuable context for the next fix attempt.
Related guides
Defect Reporting Best Practices
The six elements of a useful bug report, severity vs. priority, and how to write defects that get fixed.How to Set Up a QA Project from Scratch
From creating a project and structuring scenarios to submitting for validation and running your first execution.How to Write Test Cases That Actually Catch Bugs
Anatomy of a good test case, common mistakes, and the difference between writing for execution vs. review.Run your first structured test execution
Create a project, build your scenarios, and execute with full step-by-step tracking, defect logging, and run summaries — all in one platform.