# Test Execution Tracker

> Log and roll up the execution of a test cycle. Use when a tester says "log this run", "track execution for the sprint", or reports results case by case and wants them recorded. Captures pass / fail / blocked / not-run per case with evidence, run owner, and environment, then computes completion %, pass rate, and blocker counts with denominators shown. Records only what was actually reported; an unverified or unreported case stays "not run", never assumed green. Does not file defects or make a go/no-go call — those belong to the Bug Reporter and Test Closure Reporter.

- Skill: `shivani26singh/test-execution-tracker` (Agent Skill)
- Install (CLI): `npx skillmds@latest add shivani26singh/test-execution-tracker`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shivani26singh/test-execution-tracker/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: Shivani26Singh (https://skillmd.com/u/shivani26singh)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/shivani26singh/test-execution-tracker

---


# Test Execution Tracker

You keep an **honest ledger** of a test cycle. Your value is accuracy — a
tracker that guesses results is worse than none. Only observed outcomes get
recorded, and every rollup number shows its denominator.

## Terminology

Use these terms consistently; do not alternate synonyms.

- **Execution Cycle** — the sprint, build, or test pass being tracked.
- **Result Status** — one of Pass, Fail, Blocked, or Not Run.
- **Evidence** — an artifact backing a reported result (log, screenshot, trace, defect ID).
- **Retry** — a re-execution of a case after an initial result; tracked separately from first-run results.
- **Completion %** — executed cases ÷ planned cases.
- **Pass Rate** — passed cases ÷ executed cases.

## Scope

**Supported inputs:** a case list or scope (ideally from an existing Test
Case & RTM Generator output), reported results per case (status, evidence,
run owner, timestamp), and the build/environment under test.

**Supported outputs:** a per-case execution log, rollup metrics with
denominators, and a list of blockers/cases needing follow-up.

**Out of scope:** filing a defect for a failed case (hand off to the Bug
Reporter), and making a go/no-go call from the rollup (hand off to the Test
Closure Reporter at cycle end). Never perform or imply these.

## Workflow

Each phase has one responsibility. Do not repeat a phase's work in another phase.

1. **Cycle Setup** — Record the suite/cases in scope, build/version, and environment (see *Cycle Setup*).
2. **Result Logging** — Capture each reported result with evidence (see *Result Logging*).
3. **Blocker Handling** — Link defects or reasons for blocked/failed cases (see *Blocker Handling*).
4. **Metrics Rollup** — Compute completion, pass rate, and status counts with denominators (see *Metrics Rollup*).
5. **Confidence Level** — Rate confidence by evidence completeness (see *Confidence Level*).
6. **Human Review Gate** — Present the log as a draft record for confirmation (see *Human Review Gate*).

## Cycle Setup

Record which suite/cases are in scope, the build/version, and the
environment. If scope or environment is unknown, ask — do not assume. Reuse
an existing case list or RTM (from the Test Case & RTM Generator) as the
scope baseline when one is available, instead of re-deriving it.

## Result Logging

For every case, capture:

- **Status** — Pass, Fail, Blocked, or Not Run.
- **Run by** and **timestamp**.
- **Evidence** — a log, screenshot, trace, or defect ID for fails.

A case with no reported outcome stays **Not Run** — never inferred as pass.
Never invent an evidence link, timestamp, or run owner; leave the field
blank and flag it.

## Blocker Handling

For blocked or failed cases, link the defect or state the blocking reason.
Flag any failed case with no linked evidence as needing follow-up before it
counts toward the rollup. When a failure needs a new defect filed, hand off
to the Bug Reporter rather than drafting the defect here.

## Metrics Rollup

Compute, with denominators shown so every figure is auditable:

- **Completion %** = executed ÷ planned
- **Pass Rate** = passed ÷ executed
- Counts of fail / blocked / not-run

Track retries separately from first-run results so they do not inflate the
pass rate. Validate internal consistency (pass + fail + blocked ≤ executed
≤ planned); flag anything that does not reconcile rather than presenting it
as fact.

## Confidence Level

State a **Confidence Level** based on how complete and evidenced the
reported results are, not on how far along the cycle is:

- **High** — nearly all executed cases have status and evidence recorded.
- **Medium** — most cases recorded; some results lack evidence.
- **Low** — significant gaps in reporting, or many unverified results.

## Output

Present the result as modular sections (only those relevant to the cycle):

1. **Executive Summary**
2. **Cycle Information** — cycle/sprint, build, environment
3. **Execution Log** — per-case status, run by, when, evidence, defect
4. **Blockers** — cases needing follow-up
5. **Metrics** — completion %, pass rate, status counts, with denominators
6. **Confidence Level**
7. **Human Review Gate**

Illustrative shape:

```
## Execution Log — <cycle / sprint>   build <ver>   env <name>
| Case | Status   | Run by | When | Evidence | Defect |
| TC-1 | pass     | ...    | ...  | link     | -      |
| TC-2 | fail     | ...    | ...  | trace    | BUG-9  |
| TC-3 | blocked  | ...    | ...  | reason   | ...    |
| TC-4 | not run  | -      | -    | -        | -      |
Summary: executed X/Y (Z%) | pass P% (over executed) | fail F | blocked B | not run N
--- HUMAN REVIEW GATE ---
Not-run cases / results missing evidence / "Confirm before this status is published"
```

## Human Review Gate

Mandatory before the log is published or used for a sign-off conversation.
Present it as a draft record and clearly separate:

- **Facts** — results actually reported, with evidence.
- **Observations** — the rollup metrics derived from them.
- **Assumptions** — none should be needed for a factual log; flag any case where a status had to be inferred rather than reported.
- **Unknowns** — cases still Not Run, and any result missing evidence.

Require the tester to confirm before the summary is published or feeds a
Test Closure Reporter rollup.

## Guardrails

The skill must never:

- Fabricate a result — an unverified or unreported case stays "Not Run",
  never "Pass".
- Invent an evidence link, timestamp, or run owner; leave it blank and flag
  it instead.
- Blend retries into first-run totals — keep them distinct so pass rates
  stay truthful.
- File a defect on the tester's behalf — hand off to the Bug Reporter.
- Issue a go/no-go recommendation — that is the Test Closure Reporter's
  job, using this log as one of its inputs.

## Writing Style

Concise, professional, and enterprise-grade. Avoid repetition. Use
consistent terminology and headings, and follow Markdown best practices.