Testing dashboard examples: keep untested cases beside the pass rate

A failed test passes on retry, turning the pass rate green. Two planned cases still lack a pass-or-fail result.

Put execution coverage beside the pass rate so the retry cannot hide unfinished work.

The example starts with six fictional case points in plan P01, build B01, configuration C01. Three passed, one failed, one is blocked, and one has not run. That produces 3/4 passed, or 75%, and 4/6 executed, or about 66.67%. Apply the supplied passing retry to T04 and the pass rate becomes 100%, while execution coverage stays 4/6. The dashboard lets you inspect the counted IDs and retained attempts.

What is still untested?
What is still untested?
Open the full example ↗

Declare what counts as executed

For this review, only a latest Passed or Failed result counts as an executed point. Blocked and Not run remain visible outside that denominator. This definition belongs to the example; use your team's documented outcomes when adapting it.

The starting register is T01 Passed, T02 Passed, T03 Passed, T04 Failed, T05 Blocked, and T06 Not run. T05 lacks the approved environment. T06 has no execution attempt. Their different follow-ups deserve separate labels even though neither contributes to the four executed points.

Microsoft's test-run documentation distinguishes pass rate, outcomes, environment metadata, and execution attachments. Keep those categories available when preparing your own register. A result label alone does not supply the log or observed behavior behind it.

Read the two fractions together

Start with the numerator. The passed IDs are T01, T02, and T03. Then inspect the denominator: T01 through T04 have pass-or-fail results. The pass fraction is therefore 3/4.

Execution coverage asks a different question. Four executed IDs sit inside a six-point plan, giving 4/6. This is coverage of the declared test plan, not a claim about all code paths or requirements. The six statuses reconcile as three passed plus one failed plus one blocked plus one not run.

Use the status buttons to inspect the underlying rows. Selecting Blocked shows T05 and its environment note. The scope and full-plan totals remain visible while the row list is filtered. A short list should not silently become a new release-level denominator.

Inspect the retry without erasing the failure

T04 has an earlier failed attempt, A04a. The illustrative retry button adds later attempt A04b with Passed as its outcome. Both belong to P01/B01/C01, and their supplied earlier/later order determines which one is latest.

After the retry, four latest points passed out of four executed points. There are now five pass-or-fail attempt records, because T04 has two. Five attempts still represent four executed points. Repeating the button does not add another attempt or another planned point.

The T04 history explains that difference directly. It preserves A04a and identifies A04b as the latest supplied attempt. These are fictional records, with no real timestamps or artifacts attached. Do not treat the passing retry as evidence that a bug was fixed or a release was approved.

Prepare the next testing conversation

For an actual review, add each attempt's scope, timestamp, expected result, observed result, and evidence reference to your maintained tracker. If two competing attempts cannot be ordered reliably, resolve the ordering before selecting a latest outcome. A similarly named case in another configuration cannot settle this one.

Copy this prompt

Create a self-contained US-English testing evidence dashboard in one HTML file. Use an original compact engineering-review layout with strong typography, a visible scope strip, two clearly labeled fractions, and a readable point register. All text must be at least 16px and the layout must fit 360px without horizontal scrolling. Include local styles and JavaScript only.

Label every record fictional. Scope is plan P01, build B01, configuration C01. Six unique planned points: T01 Passed, T02 Passed, T03 Passed, T04 Failed, T05 Blocked because the approved environment is missing, T06 Not run. Define executed as latest Passed or Failed. Initially show 3/4 pass rate = 75% and 4/6 execution coverage = approximately 66.67%, plus one blocked and one not run.

Provide type=button status filters that expose matching IDs while preserving the full-plan summary and scope. Include a T04 history panel. An Apply illustrative retry button adds later A04b Passed while retaining earlier A04a Failed. Recompute latest outcomes: pass rate 4/4 = 100%, coverage remains 4/6, five pass/fail attempts represent four executed points. Repeated application must not duplicate the attempt. Include Reset.

Keep actual timestamps and artifacts unavailable; do not fabricate working evidence links. Explain that the supplied order applies only within this scope. No real test execution, connection, release approval, persistent records, or notification features. Use explicit element selectors, labeled accessible buttons, keyboard focus, and textual state feedback. Return the complete HTML.

Ask the environment owner what would unblock T05 and schedule T06's first execution. When reviewers need to see why the green pass rate leaves those questions open, present a sanitized HTML review in NOS, whose editor previews HTML. Keep the test tracker and release decision in the team's existing records.

Keep reading