bmad-testarch-test-design について
リスクとテスト容易性の評価に基づき、エピック単位のテスト計画を作成する BMAD スキルです。作成、再開、検証、編集に対応し、実行ごとに進捗を管理します。
主な機能
- 01リスクとテスト容易性の評価
- 02エピック単位のテスト計画
- 03作成・再開・検証・編集モード
- 04実行ごとの進捗管理
活用シーン
- 01エピックのテスト計画
- 02中断した計画の再開
- 03既存計画の検証や修正
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ bmad-code-org/ bmad-method-test-architecture-enterprise --skill bmad-testarch-test-designインストール後、Claude Code で/bmad-testarch-test-designを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
bmod.tomlchecklist.mdcustomize.tomlinstructions.mdtest-design-architecture-template.mdtest-design-handoff-template.mdtest-design-qa-template.mdtest-design-template.mdworkflow.yamlresources/test-design-epic-3.example.mdsteps-c/step-01-detect-mode.mdstep-01b-resume.mdstep-02-load-context.mdstep-03-risk-and-testability.mdstep-04-coverage-plan.mdstep-05-generate-output.mdsteps-e/step-01-assess.mdstep-02-apply-edit.mdsteps-v/step-01-validate.md詳細
テスト設計とリスク評価
目標: リスクとテスト容易性の評価に基づいた、エピックレベルのテスト計画を作成します。
役割: あなたはテストアーキテクトの責任者です。
この役割の説明にある詳細を統合しながら、与えられた名前、アイデンティティ、communication_style で引き続き対応します。
規約
- パスのみの指定(例:
instructions.md)は、スキルのルートから解決します。 {skill-root}は、このスキルがインストールされているディレクトリ(customize.tomlがある場所)を指します。{project-root}は、プロジェクトの作業ディレクトリから親ディレクトリをたどり、_bmad/を含む最も近いフォルダーを指します。{tea-knowledge}は、このスキルと同じ場所にインストールされているbmod-teaスキルのknowledge/フォルダーを指します:{skill-root}/../bmod-tea/knowledge。その中のtea-index.csvには、フォルダーからの相対パスですべてのフラグメントが記載されています。{skill-name}は、スキルディレクトリのベース名を指します。instructions.md、checklist.md、steps-c/...、steps-e/...、steps-v/...などの同階層にあるワークフローファイルやテンプレートは、{skill-root}から解決します。
起動時
ステップ 1:ワークフローブロックを解決する
実行:uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow
スクリプトが失敗した場合は、以下の3つのファイルをベース → チーム → ユーザーの順に読み込み、リゾルバーと同じ構造マージ規則を適用して、workflow ブロックを自分で解決します。
{skill-root}/customize.toml— デフォルト{project-root}/_bmad/custom/{skill-name}.toml— チームによるオーバーライド{project-root}/_bmad/custom/{skill-name}.user.toml— 個人によるオーバーライド
存在しないファイルはスキップします。スカラー値は上書きし、テーブルはディープマージします。code または id をキーとするテーブルの配列は、一致するエントリーを置き換えて新しいエントリーを追加します。それ以外の配列はすべて追加します。
ステップ 2:先頭に追加するステップを実行する
続行する前に、{workflow.activation_steps_prepend} の各エントリーを順番に実行します。
ステップ 3:永続的な事実を読み込む
{workflow.persistent_facts} の各エントリーを、ワークフロー実行中に保持する基礎コンテキストとして扱います。file: が先頭に付いたエントリーは、{project-root} から解決されるパスまたはグロブとして扱います。これらを展開し、一致するすべてのファイルを辞書順に読み込み、事実として扱います。それ以外のエントリーは、記載どおりの事実として扱います。
ステップ 4:設定を読み込む
実行:uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core --key modules.tea。スクリプトが失敗した場合は、上記のマージ規則に従い、{project-root}/_bmad/config.toml、{project-root}/_bmad/custom/config.toml、{project-root}/_bmad/custom/config.user.toml をこの順に自分でマージします。_bmad/config.toml が存在しない場合、または modules.tea テーブルがない場合は、TEA が設定されていないことをユーザーに伝え、最初に bmad setup tea を実行するよう依頼して停止します。
core と modules.tea の各キーは {<key>} および後続のステップでの config.<key> として利用できます。値の中の {project-root} はプロジェクトルートに置き換えます。設定の回答は文字列です。"true" と "false" はブール値として読み取ります。
{tea-knowledge}/tea-index.csv が存在しない場合、TEA ナレッジベースはインストールされていません。そのことをユーザーに伝え、npx skills add bmad-code-org/bmad-method-test-architecture-enterprise --skill bmod-tea でのインストールを提案します。ユーザーが同意したら実行し、ファイルが揃うまで停止します。
ステップ 5:ユーザーに挨拶する
{communication_language} で話し、{user_name} に挨拶します。
ステップ 6:末尾に追加するステップを実行する
{workflow.activation_steps_append} の各エントリーを順番に実行します。
起動は完了です。以下のワークフローを開始します。
ワークフローのアーキテクチャ
このワークフローでは、3モードのステップファイルアーキテクチャを使用します。
- 作成モード(steps-c/):新規実行と再開時の継続に使用する主要な実行フロー
- 検証モード(steps-v/):チェックリストに照らした検証
- 編集モード(steps-e/):既存の出力を修正
初期化シーケンス
1. モードの決定
「ワークフローへようこそ。何をしますか?」
- [C] 作成 — ワークフローを最初から実行します
- [R] 再開 — 中断した作成ワークフローを再開します
- [V] 検証 — 既存の出力を検証します
- [E] 編集 — 既存の出力を編集します
2. 最初のステップへのルーティング
- C の場合:
{skill-root}/steps-c/step-01-detect-mode.mdを読み込みます - R の場合:
{skill-root}/steps-c/step-01b-resume.mdを読み込みます(作成モードの続行) - V の場合:
{skill-root}/steps-v/step-01-validate.mdを読み込みます - E の場合:
{skill-root}/steps-e/step-01-assess.mdを読み込みます
すべての出力は {test_artifacts}/test-design/ 以下に保存されます。システムレベルの test-design-architecture.md と test-design-qa.md、エピック計画 test-design-epic-{epic_num}.md、{project_name}-handoff.md ドキュメント、exploration/ 以下の探索用スクリーンショットが含まれます。
各実行では、{test_artifacts}/test-design/test-design-progress-{run_key}.md に個別の進捗チェックポイントが書き込まれます。run_key は、システムレベルの実行では system、エピックレベルの実行では epic-{epic_num} です。ステップ 1 でチェックポイントを特定するため、あるエピックの実行を中断して別のエピックを開始しても、最初のエピックのチェックポイントが上書きされることはありません。
再開モードでは、再開する実行に一致するチェックポイントを選択します。スコープが指定されておらず、複数のチェックポイントがある場合は確認し、runKey が別の実行に属するチェックポイントからの続行は拒否します。明示的な進捗メタデータ(workflowStatus、nextStep、totalSteps)を読み取り、必要に応じて従来の lastStep データにフォールバックします。