D8 システムテスト計画書の新規作成・更新を行う。全体テスト計画書の作成後、システムテストのスコープと進め方を定める段階で呼び出す。
実行スコア 未検証
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
STPLAN-SCOPE-* は変えず、欠番も再利用しない。| 成果物のパス | 内容 |
|---|---|
docs/D8.test-plan/overall-test-plan.md | 全体テスト計画書。各見出しの記述を、差分の判断とリンク先に利用 |
docs/D8.test-plan/test-policy.md | テストポリシー。組織として決まっているテストのやり方を、逸脱の判断に利用 |
docs/D8.test-plan/*_test-strategy.md | テスト戦略書。1章の品質リスクマップのプロダクトリスクを、優先度に利用。テストを削る条件を、中断・再開基準との整合に利用。ファイル名は YYYYMMDD_test-strategy.md |
docs/D1.business-requirements/user-story-list.md | ユーザーストーリー一覧。やりたいことと Acceptance Criteria を、テストスコープの対象／対象外の判断と、優先度の判断に利用 |
docs/D1.business-requirements/use-case-list.md | ユースケース一覧。ユースケースと機能の対応を、テストスコープの対象／対象外の判断と、優先度の判断に利用 |
docs/D1.business-requirements/product-requirement-document.md | プロダクト要求仕様書。正常系とイレギュラー対応を、優先度の判断に利用 |
docs/D2.system-requirements/function-list.md | 機能一覧。機能を、テストスコープの単位に利用。ユースケースとの対応を、対象／対象外の判断と、優先度の判断に利用 |
docs/D2.system-requirements/c4-level1-system-context.md | C4モデル レベル1。対象システムを、テストアイテムの1行に利用。誰が何をし、どこまで進めるかを、概要に利用 |
docs/D3.system-design/c4-level2-container.md | C4モデル レベル2。コンテナの名称とIDを、概要の役割に利用 |
docs/D3.system-design/c4-level2-sequences/*.md | C4モデル レベル2シーケンス。外部システムとのやり取りを、対象外の判断に利用。処理の流れ・分岐・エラー時の振る舞いを、技法の選定に利用 |
docs/D3.system-design/batch-list.md | バッチ一覧。バッチを、テストスコープの単位に利用 |
docs/D3.system-design/screen-designs/*.md | 画面設計書。入力項目の値域・区分値・必須の有無を、技法の選定に利用 |
| 成果物のパス | 内容 |
|---|---|
docs/D8.test-plan/system-test-plan.md | システムテスト計画書 |
| テンプレートのパス | 内容 |
|---|---|
.claude/skills/d8-system-test-plan/template.md | ISO/IEC/IEEE 29119に沿ったシステムテスト計画書のテンプレート |
docs/D8.test-plan/system-test-plan.md が無いなら、§2（新規作成）に進む。<br> で「対象は次を結合した状態。」と、役割ごとの ・ で全コンテナの名称とIDを記載する。FUNC-*・BATCH-* ごとに対象／対象外を判断する。対象には STPLAN-SCOPE-* を振る。システムごとの違いは、テストアイテム列で区別して記載する。対象／対象外は、機能一覧・バッチ一覧のほか、紐づくユースケースとユーザーストーリーを見て判断する。バッチ一覧が無いときは BATCH-* は無いものとして扱う。【要確認】 を付ける。プロダクト要求仕様書の正常系、ユーザーストーリー、ユースケースを見て、終点まで届く機能は一段階上げ、イレギュラー対応にしか無い機能は一段階下げる。高より上、低より下にはしない。テスト戦略書 リスクレベル(高・中・低)のため、戦略書が無い行は テスト戦略書のリスクレベルが無いため【要確認】 とする。終点まで届く機能は届くために要ることを、イレギュラー対応にしか無い機能は終点までの流れに要らないことを、「〜のため」で記載する。表の下には、初期値と、終点まで届く機能は一段階上げ、イレギュラー対応にしか無い機能は一段階下げることを記載する。【要確認】 を付ける。【要確認】 を付ける。全体テスト計画書の記述がシステムテストに当てはまるかを確かめ、外れる点があれば差分を記載する。全体テスト計画書が無いときも「全体テスト計画に準拠」とリンクを記載し、中身は仮置きしない。
「完成時のセルフチェック」を実施する。
docs/D9.test-design/test-perspectives.md の見直しが必要になる旨をユーザーに伝える。FUNC-* と、バッチ一覧があるときの全 BATCH-* が、テストスコープのいずれかの行（対象／対象外）に現れている【要確認】 があるSTPLAN-SCOPE-* がすべてテストスコープに存在し、テストスコープの対象の STPLAN-SCOPE-* がすべて 5.3 のいずれかの技法に対応付けられているSTPLAN-SCOPE-* に重複が無く、更新時は既存の ID と内容の対応が変わっていないまだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。
ビジネス要件定義書(BRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)の中でも最上流に位置する成果物であり、ドメイン定義書・プロダクト要求仕様書(PRD)本体・ドメイン要求仕様書群すべての根拠となる業務観点の要求文書。新規プロジェクト立ち上げ時の最初の成果物作成、戦略・スコープの大きな変更、KPI見直しのタイミングで呼び出す。
ドメイン共通要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)が方針・概念を扱うのに対し、本書は **3 ドメイン以上で横断的に効く具体的な要求(水準・方針・原則)** を集約する文書。**ドメイン要求仕様書群(個別)とは並列の関係にあり、横断的な水準・方針・原則は本書が単独で責務を持つ(=厳密な MECE。個別ドメインで言い換えない)。** 機能要求・非機能要求・UI/UX 方針・セキュリティ要求・データアクセス要求・法務/コンプライアンス要求 の各節を持つ。PRD・アクター一覧・ドメイン定義書 を上流とし、PRD策定後、ドメイン要求仕様書群(個別)の作成前に呼び出す。
ドメイン定義書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本プロダクトを構成する業務領域(ドメイン)を網羅・分類する文書。問題空間(プロダクトが扱う業務領域)の整理であり、DDDにおけるBounded Context(解空間としての実装上の境界)とは別レイヤーで扱う。BRDの下流に位置する成果物。後続のプロダクト要求仕様書、ドメイン要求仕様書群(各ドメインごとに1つ)など、様々な成果物から参照される。BRD策定後、ドメイン整理の段階で呼び出す。
ドメイン要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)を親文書とし、ドメイン定義書で定義された各ドメインごとに1冊作成される。**ドメイン共通要求仕様書(横断的な水準・方針・原則)とは並列の関係にあり、当該ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)のみを扱う(共通要求と内容が重なる要求は本書に書かない=厳密な MECE)。** PRD・ドメイン定義書の策定後、ドメインごとの業務要求を具体化する段階で呼び出す。下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)・画面要件群(D2)・L1/L2シーケンス図の起点となる。
プロダクト要求仕様書(PRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、方針・概念・体験設計・制約・受け入れ基準を扱う文書。具体的な横断要求(機能要求・非機能要求・UI/UX・セキュリティ・法務 等)は独立成果物のドメイン共通要求仕様書に集約し、PRD は要求 ID を持たない。BRD・アクター一覧・ドメイン定義書 を上流とし、BRD策定後、ドメイン共通要求仕様書の作成前に呼び出す。