test-reporting

Test Reporting

Chinese version： See the corresponding Chinese skill.

When to Use

• Need help with test reporting in a real project context.
• Need an output that can be used directly for execution, review, or follow-up.

Workflow

1. Read and follow the main prompt listed under Progressive disclosure (coverage, structure, quality bar).
2. Add only project context that changes the result: scope, environment, constraints, risks, dependencies, expected deliverable.
3. If input is incomplete, return a usable first draft and explicitly mark assumptions and gaps.
4. Default to Markdown; switch formats only when the user asks.

Core Constraints

• Prioritize by risk / business impact — do not treat everything equally.
• Separate confirmed facts from current assumptions.
• Keep confirmed facts, inference, missing evidence, residual risk, and recommendations in identifiable sections.
• Do not invent endpoints, fields, environments, or root causes the user did not provide.
• Keep output executable: concrete scenarios, clear priority, clear next steps.
• When both execution and defect evidence are absent, the only overall quality state is not executed or insufficient evidence; never report pass or release readiness.

Progressive Disclosure

• Before producing output, read and follow prompts/test-reporting.md (minimum coverage, output structure, quality bar).
• When Excel/CSV/JSON/Word is requested: read output-formats.md and honor the format.
• When a ready-made template fits: use matching files under output-templates/.
• For format conversion or helper checks: prefer existing scripts/ over reinventing.
• For evaluating/regressing this skill: use evals/ with skill-up.

Pre-delivery Checklist

• Followed the main prompt's output structure
• Minimum coverage focus: scope tested, scope not tested, overall status, critical defects or blockers, risk summary, coverage confidence, environment or data issues, recommended release position, ... (details in main prompt)
• Covered the minimum checklist, or explained omissions
• High-risk items have explicit priority
• Did not invent details the user did not provide
• Assumptions and gaps are marked
• Evidence levels are separated; plans, environment readiness, and role opinions are not treated as pass evidence
• Missing execution and defect evidence did not become a pass, zero-defect, or release-ready conclusion

Common Pitfalls

• Do not pretend completeness when scope/context is missing.
• Do not treat every item as equally important.
• Do not skip assumptions and information gaps.
• Do not turn a planned case count into execution, or an absent defect list into zero defects.
• Do not dump generic theory unrelated to the current toolchain.