Manual Testing
Intermediate 13 min read Manual Testing

Test Execution & Tracking

Executing tests is where the plan becomes evidence. Learn how to run cases systematically, record actual results, handle blockers, and keep defect and coverage data trustworthy as the release approaches.

test executiondefectblockertraceabilitycoveragetest run
Prerequisites: Test Planning & Strategy Test Case Design Techniques
Introduction

What is this?

Test execution is the systematic running of test cases against a build, recording the actual outcome for each step and comparing it with the expected result. A pass means the actual matches expected; a fail means a defect is logged with reproduction evidence; a block means an environment or data problem stops the test before it can complete. Every outcome is recorded so coverage and quality can be measured.

Motivation

Why do you need it?

  • Recorded outcomes turn a release decision into an evidence-based one instead of a guess.
  • A clean pass history shows which areas are safe to ship and which need another cycle.
  • Precise fail records with evidence save developers hours of reproduction effort.
  • Tracking blockers reveals environment and data problems that are separate from product defects.
  • Execution data feeds the metrics that stakeholders actually read before go/no-go.
Think about it

Mental model

Imagine

A pilot's flight log

Think of

A test execution record

A pilot records every leg, every check and every anomaly — not just the smooth flights. A test log records every run, outcome and anomaly so the next crew (or release owner) can rely on it.

Mechanics

How it works

  • Set up the environment to match the plan, seed test data, and verify the build is the expected version.
  • Run cases in a prioritized order, usually critical path and high-risk first.
  • Record the actual result for each step against the expected result, with evidence (screenshots, logs) for failures.
  • Log defects immediately with steps to reproduce; note blockers separately from failures.
  • Summarize the run: pass rate, open defects, blocked tests and remaining risk for the release review.

Execution outcomes and where each one flows.

Test case
Execute
Pass
Fail
Blocked
Record & track
Release review
Reference

Key commands

echo 'TC-101 checkout-payment PASS' >> run-log.txt

Record a passing case with its traceable ID.

grep -c PASS run-log.txt && grep -c FAIL run-log.txt

Compute pass and fail counts for the run summary.

42
3
gh issue create --title 'Checkout tax totals off by 0.01' --body 'See TC-102'

File the defect immediately with the test case as evidence.

curl -sf https://staging.example.com/api/health | jq '.services.pdf'

Diagnose whether a blocker is an environment outage rather than a product defect.

unhealthy
echo 'blocked by PDF 503, retry when service restored' >> run-log.txt

Record the blocker with its root cause so it can be retried, not ignored.

Hands-on

Examples

Recording a test run from the terminal

Recording a test run from the terminal
# Start the run with build and environment context
echo "Build: v2.0-RC2 | Env: staging | Date: $(date -I)" > run-log.txt
 
# Run a critical-path suite (checkout) and append per-case outcomes
echo "TC-101 checkout-payment PASS" >> run-log.txt
echo "TC-102 checkout-tax FAIL (expected 134.99, got 134.98)" >> run-log.txt
echo "TC-103 invoice-pdf BLOCKED (PDF service 503)" >> run-log.txt
 
# Summarize the run for the release review
grep -c PASS run-log.txt   # 1
grep -c FAIL run-log.txt   # 1
grep -c BLOCKED run-log.txt # 1

Every case is recorded with its outcome and the exact mismatch for failures. The summary grep commands turn the log into the numbers the release review reads — pass rate, open failures and blockers.

Real world

In production

  • Teams run a prioritized smoke suite on every deploy and a full regression before release, logging both.
  • Execution records drive the pass-rate numbers that appear on release dashboards.
  • Blocked-test counts surface environment instability that is often the real release risk.
  • Traceable outcomes (case to defect to fix) let auditors verify release quality after the fact.
Guidelines

Best practices

  • Verify the build version and environment health before executing — never test the wrong build.
  • Log every outcome, including passes; a log with only failures has no evidence of coverage.
  • Record exact expected-vs-actual values, not 'didn't work'.
  • Attach evidence (screenshot, log snippet) to every failure.
  • Re-run blocked tests as soon as the blocker is cleared, in priority order.
Watch out

Common mistakes

  • Marking a case passed without actually running it to hit the pass-rate target.
  • Merging failures and blockers in one status, hiding environment problems.
  • Logging defects without reproduction steps, forcing developers to chase them down.
  • Forgetting to record the environment and build, so a good run cannot be repeated.
Root cause analysis

Common issues

Error
A whole suite fails on login
Root cause

Shared test credentials expired or revoked

Fix

Rotate and re-seed credentials, then re-run; do not start logging defects against the app.

Error
Test data mutated between runs
Root cause

Cases share state instead of being isolated

Fix

Seed per-case data and reset the environment between runs.

Error
Pass rate is inflated to 100%
Root cause

Cases marked pass without execution

Fix

Spot-audit recent passes against screenshots/logs and make evidence mandatory.

When things break

Debugging tips

  • For a fail, reproduce it once before logging — it often turns out to be environment drift, not a defect.
  • When many cases fail together, suspect the environment, not the product.
  • Use error messages from logs as search terms to distinguish known issues from new regressions.
  • If a case is flaky, mark it blocked and quarantine it rather than letting it pollute pass rate.
Interviews

Interview checkpoint

Practice

Hands-on lab

Run and Track a Checkout Test Suite
40 min · intermediate
In progress
Objectives
  • Execute a small suite in a priority order
  • Record pass, fail and blocked outcomes with evidence
  • Log a defect with reproduction steps
  • Summarize the run into pass rate and open-defect counts

Run and Track a Checkout Test Suite

40 min · intermediate

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

A case cannot run because the payment sandbox is down. What is the correct status?

2

Recording passing cases is a waste of time.

3

Five cases in the same module all fail with the same error message. What is your first action?

Quick reference

Cheat sheet

Execution outcomes
PASSActual matches expected
FAILLog defect with steps + evidence
BLOCKEDEnvironment/data prevents run
NOT RUNOut of scope or deprioritized
Expected vs actualAlways record the exact values
Go deeper

Official documentation

ISTQB — Test Execution Process
docs
TestRail — Guide to Test Execution
docs
Software Testing Help — Test Execution & Tracking
docs