A Check Plan Is Not a Result

A check report should say what the records establish, even when that leaves the work incomplete. A plan describes what you meant to check. A recorded output describes what came back. Calling the work successful requires comparing that output with the stated criterion.

That distinction matters when you write the methods and results in a blog post. “We planned these checks” and “these checks passed” make different claims. I recommend keeping the criterion, output and judgment together, rather than compressing them into a reassuring sentence that the records contradict.

Start With the Criterion and the Plan

Everything below is original fictional teaching material: an invented plan and an invented log, not checks performed by this article’s author. The exercise concerns only three code-and-title copying checks. It does not represent an actual app or establish the correctness of an entire method.

Here is the criterion: a recorded output passes a check only when both its code and its title exactly match that check’s expected pair. Matching the code alone is insufficient.

The complete plan contains:

• T1: expected code C01, expected title Cloud.

• T2: expected code C02, expected title River.

• T3: expected code C03, expected title Field.

These are expected values. Writing them into a plan supplies no observed output. A useful article brief can state what you intend to demonstrate; the finished methods paragraph must still reflect what the result records actually contain.

Read Each Log Entry Against Its Own Pair

T1: Both Values Match

The supplied log marks T1 output recorded and gives code C01, title Cloud. Those values match its expected C01 and Cloud, so T1 passes the stated check.

Keep the criterion in the explanation. “T1 passed” is a conclusion; the matching pair shows why that conclusion follows here.

T2: The Code Matches and the Title Differs

The supplied log marks T2 output recorded and gives code C02, title Ridge. The expected pair is C02, River. Its code matches, but Ridge differs from River, so T2 fails the pair-matching check.

The log records no cause and no later repair. Describing a typing error or saying the title was fixed would add a new event to the story. Report the mismatch; reserve an explanation or repair claim for a record that actually supplies it.

T3: The Log Says Not Run

The supplied log explicitly marks T3 not run and records no output. Its planned C03 and Field values remain expectations, rather than observed results.

This status comes from the explicit entry. An absent output in some other log would leave open whether the check ran and its result was omitted. Here, the invented log supplies the status directly.

Write the Report the Records Support

There are three planned checks, two with recorded outputs, one pass, one failure and one not-run case. The two recorded outputs account for the pass and the failure; the third planned case remains explicitly unrun.

Here is the completed methods-and-results paragraph:

In this fictional teaching packet, three exact code-and-title checks were planned and two have recorded outputs. T1 matched C01 and Cloud. T2 matched code C02 but recorded Ridge instead of the expected River, so it failed the stated pair-matching check; the cause and any repair are not recorded. T3 was not run. The supplied log therefore contains one pass, one failure and one not-run case, and does not establish that all three checks passed or that the whole method is correct.

I favor this paragraph because it gives the reader a specific account of the work’s limits. It retains the failed case and the unfinished case without turning either into a diagnosis. The reader can see exactly which conclusion needs another record.

Three tempting rewrites would change that account:

• “All three planned checks passed.” T2 mismatches and T3 has no output.

• “Two of the three checks failed.” T3 is marked not run; only T2 fails the criterion.

• “The wrong title was caused by a typing error and has been fixed.” Neither the cause nor a repair appears in the supplied log.

The goal is a report that remains useful after the reassuring language is removed. A mismatch tells you what needs investigation. A not-run entry tells you which planned work is outstanding. Neither needs a more dramatic or more flattering label.

When the Criterion Is Missing

Now consider a separate changed packet for T2. It supplies expected code C02, leaves the expected title unknown, and records observed code C02, title Ridge.

The code matches. Pass or fail for the complete pair is not established, because the expected title is missing. Obtain this packet’s actual expected title before judging it; do not silently carry River over from the original packet.

This is why I would state the criterion beside the result rather than rely on an outcome label alone. The same observed title can receive no complete judgment when a required expectation is absent.

When you write the finished blog post, use the verbs your records justify: planned, recorded, matched, differed or not run. Then return to your blog topic plan with a clear account of what this article answers and what still needs evidence.