test-reporting について
実プロジェクトのテスト報告を支援し、実行、レビュー、フォローアップに使える形で結果を整理するスキルです。証拠と推論を分け、証拠不足時に合格やリリース可能とは判定しません。
主な機能
- 01リスクと業務影響による優先付け
- 02事実、推論、証拠不足の区別
- 03テスト済み・未テスト範囲の整理
- 04主要な不具合、リスク、リリース提案の明記
- 05証拠不足時の合格判定の回避
活用シーン
- 01テスト実行状況レポートの作成
- 02リリースレビュー向けリスクと提案の整理
- 03証拠が不完全な場合の品質状態の説明
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ naodeng/ awesome-qa-skills --skill test-reportingインストール後、Claude Code で/test-reportingを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
output-formats.mdquick-start.mdREADME.mdagents/openai.yamlevals/eval.yamlevals/cases/basic-success.yamledge-incomplete-input.yamledge-no-execution-evidence.yamledge-risk-priority.yamlreview-raw-execution-statistics.yamlreview-unknown-denominator.yamlevals/graders/review-raw-execution-statistics.pyexamples/README.mdoutput-templates/template-csv.csvtemplate-excel.tsvtemplate-json.jsontemplate-markdown.mdtemplate-word.mdtemplate-xmind.mdprompts/test-reporting.mdreferences/local/FAQ.mdscripts/batch_convert_templates.pyconvert_formats.pyconvert_output_formats.pyconvert_to_csv.pyconvert_to_excel.pyconvert_to_json.pyconvert_to_markdown.pyconvert_to_word.pyconvert_to_xmind.py詳細
翻訳後に原文が更新されています。最新の内容は原文をご確認ください。
テストレポート
中国語版: 対応する中国語スキルを参照してください。
使用する場面
- 実際のプロジェクトの状況に即したテストレポートの作成を支援してほしい場合。
- 実行、レビュー、または後続対応にそのまま使える出力が必要な場合。
ワークフロー
- Progressive disclosure に記載されたメインプロンプト(対象範囲、構成、品質基準)を読み、その指示に従います。
- 結果に影響するプロジェクトのコンテキストのみを追加します:対象範囲、環境、制約、リスク、依存関係、期待される成果物。
- 入力が不完全な場合は、実用的な初稿を返し、前提と不足情報を明示します。
- 既定では Markdown を使用し、ユーザーの要望がある場合にのみ形式を切り替えます。
中核となる制約
- リスク/ビジネスへの影響に基づいて優先順位を付け、すべてを同等に扱わないでください。
- 確認済みの事実と現時点での前提を区別します。
- 確認済みの事実、推論、不足している証拠、残存リスク、推奨事項を、それぞれ判別できるセクションに分けます。
- ユーザーが提示していないエンドポイント、フィールド、環境、根本原因を作り出さないでください。
- 出力は実行可能なものにします:具体的なシナリオ、明確な優先順位、明確な次のステップを含めます。
- 実行証拠と不具合の証拠の両方がない場合、全体的な品質状態として認められるのは
not executed or insufficient evidenceのみです。合格またはリリース準備完了とは報告しないでください。
段階的な情報開示
- 出力を作成する前に、
prompts/test-reporting.mdを読み、指示に従います(最低限の対象範囲、出力構成、品質基準)。 - Excel/CSV/JSON/Word が指定された場合は、
output-formats.mdを読み、指定形式に従います。 - 既製のテンプレートが適している場合は、
output-templates/以下の対応するファイルを使用します。 - 形式変換や補助的なチェックでは、一から作り直すのではなく、既存の
scripts/を優先します。 - このスキルを評価/回帰テストする場合は、skill-up と
evals/を使用します。
提出前チェックリスト
- メインプロンプトの出力構成に従った
- 最低限の対象範囲に注力した:テスト済みの範囲、未テストの範囲、全体的なステータス、重大な不具合またはブロッカー、リスクの概要、カバレッジの信頼度、環境またはデータの問題、推奨するリリース判断、…(詳細はメインプロンプトを参照)
- 最低限のチェックリストを網羅した、または省略した項目について説明した
- リスクの高い項目に明示的な優先順位を付けた
- ユーザーが提示していない詳細を作り出さなかった
- 前提と不足情報を明記した
- 証拠のレベルを区別した。計画、環境の準備状況、役割上の意見を合格の証拠として扱っていない
- 実行証拠や不具合の証拠がないことを、合格、不具合ゼロ、またはリリース準備完了という結論にしていない
よくある落とし穴
- 対象範囲やコンテキストが不足しているのに、完全であるかのように見せないでください。
- すべての項目を同等に重要なものとして扱わないでください。
- 前提や情報の不足を省略しないでください。
- 計画上のケース数を実行済みの数に置き換えたり、不具合一覧がないことを不具合ゼロとみなしたりしないでください。
- 現在のツールチェーンに関係のない一般論を並べないでください。
コメント
Markdown 対応