本文へ移動
cccskills
無料GitHub で公開

d9-test-data-tool

D9 テストデータ作成ツールの新規作成・更新を行う。テストデータ要件定義書の作成後、開発者にテストデータ作成を依頼する段階で呼び出す。

Acceler-Digital/karuraスター 9(GitHub 9 + cccskills 0)

実行スコア 未検証

インストール方法を見る

含まれるファイル(2)

  • SKILL.md8.1 KB
  • template.md1.1 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

D9: テストデータ作成ツール

遵守すべき重要ルール

  1. 列は ER図の属性名で記載する: テストデータテンプレートの列は、ER図の属性名にする。ER図が無ければ概念データモデルの名前にする。テーブル名・カラム名は記載しない。
  2. 仕様と画面と初期投入データから決まる値は記載する: 一意に決まる値は記載する。決まらない値は、決め方を記載する。
  3. 要件定義書の範囲の外に出ない: 要件定義書に無い要件から表を作らない。
  4. 上流の成果物を直さない: 上流の漏れや誤りに気づいたら、直さずにユーザーへ伝える。
  5. ID を振り直さない: 採番済みの TDT-* は変えず、欠番も再利用しない。

インプットする成果物

成果物のパス内容
docs/D9.test-design/test-data-requirements.mdテストデータ要件定義書。エンティティ、必要な状態、件数、属性(値)の条件、依存、関連テスト観点を、テストデータ作成要否の表と条件の表に利用
docs/D3.system-design/er-diagram.mdER図。テストデータテンプレートの列名に利用
docs/D2.system-requirements/conceptual-data-model.md概念データモデル。ER図が無いときだけ、テストデータテンプレートの列名に利用
docs/D3.system-design/screen-designs/*.md画面設計書。画面の表示内容を、テストデータテンプレートに利用
docs/D2.system-requirements/wireframes/*.htmlワイヤーフレーム。画面設計書が無いとき、画面の表示内容を、テストデータテンプレートに利用
db/dml/seed/初期投入データ。起動時に入る識別子を、テストデータテンプレートに利用。無いときは、識別子は空欄にする

アウトプットする成果物

成果物のパス内容
docs/D9.test-design/test-data-tool.mdテストデータ作成ツール

アウトプットに使用するテンプレート

テンプレートのパス内容
.claude/skills/d9-test-data-tool/template.mdテストデータ作成ツールのテンプレート

処理

1. 分岐する

  • もし docs/D9.test-design/test-data-requirements.md が無いなら、テストデータ要件定義書が先である旨を伝えて終了する。
  • もし docs/D9.test-design/test-data-tool.md が無いなら、§2(新規作成)に進む。
  • それ以外なら、§3(更新)に進む。

2. 新規作成

2.1 テストデータ作成要否の表を記載する

要件定義書の TDR-* を上から、1行ずつテストデータ作成要否の表に記載する。関連要件IDとエンティティは要件から引く。

  • 必要: 手順を始める前に、テストデータを用意しておく必要がある。
  • 不要: 手順を始める前に、テストデータを用意しなくてよい。用意する行が無いとき、手順の中でできるとき、起動時に既にあるとき。
  • 作成方法: 必要な行は「手動」か「スクリプト」、不要な行は「—」とする。画面の操作だけで手順を始める前の状態にできるときは「手動」。画面の操作だけでは用意しにくいとき、データ数が多いときは「スクリプト」。

2.2 テストデータテンプレートを記載する

2.1 で作成方法をスクリプトとした要件を上から進め、要件ごとに1つの見出しと、条件の表と、テストデータテンプレートを記載する。不要な要件と、作成方法が手動の要件は、テストデータテンプレートを記載しない。エンティティ名は要件から引き、ER図の名前と食い違うなら直さずにユーザーへ伝える。ER図が無ければ概念データモデルの名前を見る。条件の表の依存のエンティティが、テストデータ作成要否の表に無いときは、直さずにユーザーへ伝える。

  • 条件の表: 関連要件ID、必要な状態、件数、属性(値)の条件、依存、関連テスト観点を、要件から引く。
  • テストデータテンプレートの列: ER図でそのエンティティが持つ属性を、図の並びで列にする。ER図が無ければ概念データモデルの属性を使う。
  • テストデータテンプレートの行: 必要な状態に業務状態の名前があるときは、その名前を業務状態の列に記載し、1状態1行にする。必要な状態に業務状態の名前が無いときは、件数を満たす行を記載する。
  • 値: 画面設計書の表示内容を記載する。画面設計書が無いときは、ワイヤーフレームの表示内容を使う。属性(値)の条件が求めている内容は、画面の表示から記載する。複数の値は「/」でつなぐ。初期投入データから決まる識別子は引く。初期投入データが無いときは、識別子の列は空欄にする。その場で採番する値は「{自動採番}」を記載する。日時の列は、決め方を「{}」で記載する。

2.3 仕上げる

TDT-* をテストデータ作成要否の表の上から通し連番で振る。作成方法がスクリプトの行は、テストデータテンプレートの見出しにも同じ ID を記載する。そのあと「完成時のセルフチェック」を実施する。

3. 更新

  • インプットした成果物で変わった箇所に関わる行とテストデータテンプレートを §2 の手順で見直す。新しい行には最大値の次の ID を振り、不要になった行とテストデータテンプレートは削除する。
  • すでに埋まった値は消さない。
  • もし要件を追加・削除・変更したなら、その旨をユーザーに伝える。

完成時のセルフチェック

  • 要件定義書の全 TDR-* が、テストデータ作成要否の表の関連要件IDに現れている
  • テストデータ作成要否の表の関連要件IDに、要件定義書に無い TDR-* が現れていない
  • テストデータ作成要否の表の全行に TDT-* がある
  • 作成方法がスクリプトの行だけが、テストデータテンプレートの関連要件IDに現れている
  • テストデータテンプレートの見出しの TDT-* が、作成方法がスクリプトの行の ID と一致している
  • 用意する行が無い、手順の中でできる、起動時に既にある、のいずれかの行が、作成要否は不要になっており、作成方法が「—」になっている
  • 作成要否が必要の行の作成方法が、「手動」か「スクリプト」になっている
  • テストデータテンプレートの列が、そのエンティティについて ER図が定めた属性と一致している
  • テーブル名・カラム名が記載されていない
  • 画面の表示内容が、テストデータテンプレートに記載されている
  • 初期投入データがあるときは、その識別子がテストデータテンプレートに記載されている。無いときは、識別子の列が空欄になっている
  • その場で採番する値が「{自動採番}」になっている。日時の列に決め方が記載されている
  • 条件の表の関連要件ID・必要な状態・件数・属性(値)の条件・依存・関連テスト観点が埋まっており、「同上」等で省略されていない
  • 条件の表の依存のエンティティが、テストデータ作成要否の表に無いときは、その旨をユーザーへ伝えている
  • TDT-* に重複が無い。更新時は既存の ID と行の対応が変わっていない

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

d1-actor-list

無料概要あり

アクター一覧の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本システムに関わるすべての人間アクター(関係者)を一覧化する文書。TOGAFのActor Catalog相当。BRDの下流に位置する成果物。後続の成果物であるプロダクト要求仕様書やユーザーストーリー一覧、C4モデルレベル1、C4モデルレベル2、L1シーケンス、L2シーケンスなど、様々な成果物から参照される。BRD策定後、アクター整理の段階で呼び出す。

Acceler-Digital/karura92026年10月26日 更新

ビジネス要件定義書(BRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)の中でも最上流に位置する成果物であり、ドメイン定義書・プロダクト要求仕様書(PRD)本体・ドメイン要求仕様書群すべての根拠となる業務観点の要求文書。新規プロジェクト立ち上げ時の最初の成果物作成、戦略・スコープの大きな変更、KPI見直しのタイミングで呼び出す。

Acceler-Digital/karura92026年10月26日 更新

ドメイン共通要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)が方針・概念を扱うのに対し、本書は **3 ドメイン以上で横断的に効く具体的な要求(水準・方針・原則)** を集約する文書。**ドメイン要求仕様書群(個別)とは並列の関係にあり、横断的な水準・方針・原則は本書が単独で責務を持つ(=厳密な MECE。個別ドメインで言い換えない)。** 機能要求・非機能要求・UI/UX 方針・セキュリティ要求・データアクセス要求・法務/コンプライアンス要求 の各節を持つ。PRD・アクター一覧・ドメイン定義書 を上流とし、PRD策定後、ドメイン要求仕様書群(個別)の作成前に呼び出す。

Acceler-Digital/karura92026年10月26日 更新

ドメイン定義書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、本プロダクトを構成する業務領域(ドメイン)を網羅・分類する文書。問題空間(プロダクトが扱う業務領域)の整理であり、DDDにおけるBounded Context(解空間としての実装上の境界)とは別レイヤーで扱う。BRDの下流に位置する成果物。後続のプロダクト要求仕様書、ドメイン要求仕様書群(各ドメインごとに1つ)など、様々な成果物から参照される。BRD策定後、ドメイン整理の段階で呼び出す。

Acceler-Digital/karura92026年10月26日 更新

ドメイン要求仕様書の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、プロダクト要求仕様書(PRD)を親文書とし、ドメイン定義書で定義された各ドメインごとに1冊作成される。**ドメイン共通要求仕様書(横断的な水準・方針・原則)とは並列の関係にあり、当該ドメイン固有の業務ルール・業務状態遷移・業務運用(イレギュラー対応)のみを扱う(共通要求と内容が重なる要求は本書に書かない=厳密な MECE)。** PRD・ドメイン定義書の策定後、ドメインごとの業務要求を具体化する段階で呼び出す。下流のユーザーストーリー一覧・ユースケース一覧・機能一覧(D2)・画面要件群(D2)・L1/L2シーケンス図の起点となる。

Acceler-Digital/karura92026年10月26日 更新

プロダクト要求仕様書(PRD)の新規作成・更新・レビューを支援する。AI駆動開発成果物フローのビジネス要求(D1)に位置する成果物で、方針・概念・体験設計・制約・受け入れ基準を扱う文書。具体的な横断要求(機能要求・非機能要求・UI/UX・セキュリティ・法務 等)は独立成果物のドメイン共通要求仕様書に集約し、PRD は要求 ID を持たない。BRD・アクター一覧・ドメイン定義書 を上流とし、BRD策定後、ドメイン共通要求仕様書の作成前に呼び出す。

Acceler-Digital/karura92026年10月26日 更新

Acceler-Digital のスキルをすべて見る

このスキルの問題を報告する