improve-test-cases

テストケースを改善する

既存の Markdown 形式の手動テストケースを分析し、QA チームにとって分かりやすい内容に改善します。

• テストタイトルを分かりやすく改善します。
• テストの説明を充実させます。
• 形式の崩れや Markdown 構文の誤りを修正します。
• テスト構造をテスト管理ツールの形式に統一します。
• 用語と表現を統一します。
• タグとラベルを更新します。

変更禁止事項：

• 元のテスト／スイート ID。
• 元のテストの意図。
• 元の言語（分かりやすさ、文法、誤字の修正のみ行います）。

ステップ 1：テストファイルを探す

• 一般的な場所（./test-cases、./tests/manual、./docs/tests）にある Markdown テストファイル（.test.md または .md）を探します。
• 見つからない場合は、プロジェクト全体からテストケースを含む .md ファイルを検索します。
• それでも見つからない場合は、ユーザーにテストディレクトリのパスを尋ねます。

ステップ 2：テスト品質を分析する

各テストを読み、次の問題を特定します。

タイトル：

• タイトルが分かりにくい、または曖昧。
• アクションと対象の形式になっていない。
• テスト対象を理解するには具体性が足りない。

説明：

• テストの目的が曖昧、または分かりにくい。
• 説明がない、または不十分。

手順と期待結果：

• 期待結果がない。
• 手順の形式が統一されていない。
• アクションが分かりにくい。
• 手順の順序が論理的でない。
• 期待結果が手順に関連していない。
• 合格／不合格の基準がない。

書式：

• Markdown 構文が崩れている。
• セクションが不足している。
• 見出し階層が統一されていない。

曖昧さ：

• 一般的、または主観的な表現（「動作するはず」「失敗する可能性がある」など）。
• 複数の解釈が可能な曖昧な表現。
• 客観的に検証できない手順。
• 具体的な値、データ、または条件が不足している。

ステップ 3：概要をユーザーに提示する

• テストごとに見つかった問題を列挙します。
• 具体的な改善案を提示します。
• 作業を進める前に、ユーザーに確認を求めます。
• ユーザーが確認しない場合は、何も変更しません。

ステップ 4：テストを改善する

タイトル：

• 明確で具体的なタイトルにします。
• アクションと結果の形式を使います：「［アクション］の結果、［期待する結果］になることを確認する」。
• タイトルが実際のテスト目的を表すようにします。

説明：

• 目的を明確かつ簡潔にします。
• 関連する場合は、親スイートのコンテキストを含めます。
• 文法とスペルのみを修正します。

手順：

• 各手順に、明示的な期待結果を設定します。
  • ネスト形式：「- 手順のアクション...」とし、その下にインデントして「期待結果: ...」を記載します。
• アクションを具体的かつ再現可能にします。
• 測定可能な合格／不合格基準を追加します。
• 結果が手順のアクションに直接関連するようにします。
• 結果を測定可能かつ検証可能にします。
• 曖昧な表現を避け、具体的な値と条件を使用します。

曖昧さ：

• 一般的な表現を、具体的でテスト可能な表現に置き換えます。
• 主観的な表現（「動作するはず」「失敗する可能性がある」など）を避けます。
• 手順を客観的に検証できるようにします。

メタデータ：

• テストメタデータに type: manual を設定します。
• 優先度には次の値のみを使用します：low、normal、important、high、critical。

ステップ 5：変更を保存する

• 元のファイルを上書きします。
• ファイル名とディレクトリ構造は維持します。
• 元のテスト／スイート ID をすべて保持します。

ステップ 6：最終概要を提示する

• 変更したファイル数。
• 改善したテスト数。
• 主な改善点。

参考資料

TMS Markdown 形式の例：references/TESTOMAT_MARKDOWN_EXAMPLE.md