QAIA-Project test-plan-and-closure — the two documents someone above the tester reads
Every other artefact QAIA produces is consumed by a tester: a test book, a suite, a score, a defect report. The two ends of the ISTQB test process — planning and closure — produce the documents a manager reads, and QAIA produced neither.
That is not only a conformance gap. A project whose every output is read by testers alone speaks to nobody who decides.
The rule that keeps these two documents from being wallpaper
Nothing in a plan or a closure report may be written that is not derivable from an artefact.
A test plan generated by a language model is, by default, template-filling: it will happily produce "risks: integration issues, tight deadlines" for any project on earth, because it read the shape of a plan and not this project. Such a document costs a signature and returns nothing.
So every section below names where its content comes from. If the source artefact does not
exist, the section says so — "no risk analysis available: prioritize was not run" is a useful
sentence. An invented risk is not.
The plan
Written before or at the start of a campaign, from what the pipeline already holds.
| Section | Derived from | If missing |
|---|---|---|
| Scope — what is under test | the ingested requirement (us-ingest, openapi-ingest) |
there is no plan to write |
| Out of scope | the requirement's silences and ADR 0004, the declared level boundary | state that nothing was excluded deliberately |
| Test conditions and their priority | istqb-design + prioritize |
say the campaign is unprioritised — that is a finding |
| Techniques applied, and why | istqb-design, which already justifies each choice |
— |
| Entry criteria | the requirement's open questions: which must be resolved before starting | — |
| Exit criteria | the gate in force (ADR 0001, the refusal-path coverage gate) and aptitude-gate |
— |
| Environments and data | dataset-generate, the run configuration |
say the environment is undocumented |
| Risks | prioritize's probability × impact scores — these and no others |
say no risk analysis exists |
Entry and exit criteria are the two sections that make a plan worth signing. A plan without them is a description of intent. With them, it is a commitment that can be checked later — which is exactly what the closure report does.
The closure report
Written at the end, and its value is proportional to how much it admits.
| Section | Derived from |
|---|---|
| What was covered | the traceability matrix: requirement → scenario → test → result |
| What was not covered, and why | the difference between the conditions designed and the tests run |
| Exit criteria: met or not | the plan's criteria, checked one by one against the run |
| Defects still open at delivery | defect-report outputs not closed by confirm-fix |
| Questions never resolved | every # open: Qn still carrying no answer |
| What the numbers do not say | the stated limits of each measurement |
The second and the last rows are the ones nobody writes and everybody needs. A closure report that only lists what went well is a press release.
Steps
- Inventory the artefacts the campaign actually produced. This is the plan's raw material and its limit.
- Write each section from its source, naming the source.
- Leave a hole where a hole exists, with the sentence saying which skill was not run.
- For the closure report, check each exit criterion of the plan — one by one, against the run, with the file that proves it.
- List what remains open before what was achieved. A reader who stops after two paragraphs should have read the bad news.
What this skill must refuse
- Inventing a risk, a criterion or a scope. If it is not derivable, it is not written.
- Declaring an exit criterion met without the file that proves it.
- Aggregating away a failure. "48 tests, 94 % pass rate" hides which three failed and why; the closure report names them.
- Writing a plan for a campaign that has not been designed. Without
istqb-design's conditions, a plan has no content — only a shape. - Presenting a self-administered measurement as external validation. A judge panel run by this project on its own output is a hostile reading, not an audit.
Applied for real
Only the closure half has been applied for real. It was produced for the json-server campaign — a campaign that had already finished, so nothing could be tailored to make it look good: the closure report.
The plan half has never been used. No plan was written before that campaign, which is why its closure report has to state that there were no exit criteria to check. The half of this skill that carries entry and exit criteria is therefore specified and unexercised — say so rather than let the example imply otherwise.
The closure report states, among other things, that three of the four failures on the current version were the test book's fault and not the code's, that one finding was counted as contested because the test extrapolated, and that the campaign's central question — is any of this useful to a human doing this job — was not answered and could not be.