■ 1. テスト要求仕様（TRS）の導入
- e-dash QAチームのドキュメント構成:
- テストケースの前にテスト設計書（Test Design）を用意する
- 直近ではさらにその前にテスト要求仕様（Test Requirement Spec、TRS）を挟む
- TRSの役割:
- テスト対象がどう動くべきかを確定させる文書
- 確認に使う因子と水準まで事前に決めておく
- TRS導入の効果:
- テスト設計が想定よりはるかに楽になった
■ 2. 従来のテスト設計とその限界
- 従来のテンプレート構造:
- 改修内容、やること、テストパターンの3部で構成する
- 確認項目ごとにテスト観点と因子水準を整理する
- 因子水準を組み合わせてテストパターンに落とす
- テストパターンの位置づけ:
- テストケース相当のものであり、テスト管理ツールに登録して実施する
- 段階的に整理する形の価値:
- 最も良くないのはいきなりテストケースを書くこと
- 構造がないと、十分かどうかがレビューアにも書いた本人にも分かりにくい
- 何を根拠に網羅したと言えるのかが残らない
- 因子水準を整理し組み合わせてパターンにする段階には意味があった
- 対象が大きくなった時の問題:
- 設計書の記載量が増え、中身の把握や追跡が難しくなる
- 追いにくくなる原因:
- 「確認項目 n」の切り方は書き手が自分で決めたもので、決まりがない
- 切り方は書き手の頭の中にあり、ドキュメントに現れない
- 確認項目ごとのパターンが大きくなり、全体量を見渡しづらい
■ 3. TRSによる構造の変化
- 切り口の決め方の変化:
- 従来は切り口を書き手が都度決めていた
- TRSではUS / UC / 振る舞い / ACで切り口が決まる
- 網羅の作り方（因子水準、組み合わせ、テストパターン）は変わらない
- 用語の意味:
- US: ユーザーストーリー
- UC: ユースケース
- 振る舞い: 正常・準正常・例外という分類
- AC: 受け入れ基準（Acceptance Criteria）
- TRSの2層構造:
- 仕様レイヤーで「あるべき挙動」を確定させる
- テスト設計レイヤーで「それをどう検証するか」を定義する
- 読む順も書く順も仕様レイヤーからテスト設計レイヤーへの一方向
- 仕様レイヤーの構成:
- 基本情報: PBI ID、タイトル、関連リンク
- 対象範囲: US × UCの対応表
- User Story: As a / I want to / So that と振る舞い
- Acceptance Criteria: Gherkinで記述し、UC単位でまとめる
- テスト設計レイヤーの構成:
- Test Design: 因子一覧、因子制約、因子間の関連、全組み合わせ指定
- Open Issues: 未解決事項
- ACの記述方法:
- BDDで使われるGherkin記法で書く
- 具体的な値は書かず、<権限>や<操作>のような可変部だけを書く
- 因子一覧の役割:
- 因子ごとに入力値、水準、必須/任意、水準確定を表で管理する
- ACの可変部と因子が1対1で対応する
- 「どの値でテストするか」の単一の情報源となる
- ACと因子一覧の分担:
- ACは「何が変わると振る舞いが変わるか」だけを書く
- 値と組み合わせは因子一覧が引き受ける
- BDDと因子水準の組み合わせ:
- BDDだけでは網羅性を体系的に確かめにくい
- 因子水準だけでは対話しながら書く良さが出ない
- Gherkinで振る舞いを書き、網羅は因子水準で担保する
- TRSから作るテスト設計書:
- 切り分けの単位が「確認項目 n」からACに変わった
- ACごとに因子水準、組み合わせ、テストパターンを持つ
- AC IDの意味:
- @US-01_UC-01_AC-基本正常-001のようなIDそれ自体が切り方を表す
- どのUSの、どのUCの、どの分類の、何番目かを示す
- 「基本」は基本フロー・代替フロー・例外フローのいずれかを表す
■ 4. TRS導入で楽になったこと
- 適用対象の状況:
- 画面をまたぐ規模の機能で、既存機能にも横断的に影響する
- 開発と並行して進めたため、作成中にも仕様が動いた
- 切り分け方に迷わなくなった:
- 最も大きな効果
- 従来はどこで切るかを毎回ゼロから考え、判断基準も自分で作っていた
- TRSではUS、UC、振る舞いの分類という階層を先に整理し、その下に因子を並べる
- 切り方の根拠:
- USはユーザーのゴールなので、機能が変わっても意味が変わらない
- 誰が切っても同じところで切れる
- 副次的効果:
- 因子水準から積み上げると、途中で確認の目的を見失うことがある
- USを起点に降りてくると目的を見失いにくい
- 確認すべきことの枠が先に決まる:
- USごとに振る舞いを正常・準正常・例外の3つに分けて書く
- 分類は事後条件、つまりUCのゴールを達成できたかで決める
- 3分類の定義:
- 正常: まっすぐ成功し、事後条件を達成する
- 準正常: ハンドリング済みのエラーが起きるが、再操作などで完了でき、事後条件を達成する
- 例外: UCが中断して完了できず、事後条件を達成しない
- 「なし」の明示:
- 該当がなければ「なし」と明示することが重要
- 従来は確認すべきことが揃っているかを書き手の判断に頼っていた
- 3分類は枠なので、埋まっていない枠が目に見える
- AC 81本の内訳:
- 正常61本、準正常2本、例外18本
- 準正常の少なさは書き漏らしではなく、UCごとに「なし」と判断した結果
- 書いていないのか、検討して無かったのかが区別できる
- レビューで例外系の抜けを目で探せる
- 未決事項を設計書の中で管理できる:
- TRSには未解決事項を書くOpen Issuesセクションがある
- 開発と並行すると「これは決まっているのか」という疑問が次々に出る
- 疑問をOpen Issuesに書き留め、仕様として決める必要があるものはチケット化した（今回6件）
- 早期発見の効果:
- 6件のうち3件は仕様書そのものの修正につながった
- いずれもテスト実行ではなくTRS作成中に見つかった
- テスト実行時に気づくと、設計とテストケースを作り終えた後に直すことになる
- TRSの段階ならACと因子を直すだけで済む
- チケットとOpen Issuesの役割の違い:
- Open IssuesにはIssue Link列があり、チケットへのリンクを持てる
- チケットは「誰がいつまでに決めるか」を回すための入れ物
- Open Issuesは設計書のどこが未確定かを示す印
- 二重管理に見えても役割が違うため、設計書の中にも書くのが良い
- Open Issuesの利点1: 完成度の判定:
- 未解決の行が残っていれば、TRSが未確定だと開いた瞬間に分かる
- チケットだけに逃がすと、設計書単体では完成しているように見える
- Open Issuesの利点2: 文脈の保持:
- 影響AC列により、どのACの話かがその場に残る
- チケットに転記すると、読むたびにどこの話かを組み立て直すことになる
- Open Issuesの利点3: 履歴の保持:
- 解決後も消さず履歴として残す運用とする
- 半年後に「なぜこの仕様なのか」を設計書だけで辿れる
■ 5. TRSをエージェントの入力に活用
- テスト設計書生成エージェントへの入力:
- 書き上げたTRSをそのまま渡してテスト設計書を生成した
- エージェントの設計は同チームの10mo8氏の記事「AIにQAエンジニアとして思考させるエージェントQA設計の思想」に詳しい
- 渡せる理由:
- US / UC / 振る舞い / ACで切り口が決まり、因子と水準が表になっている
- 人にとって整理しやすい構造が、そのまま機械に渡せる構造でもある
- 生成の規模:
- 人が書いたAC 81本から、テストケース360件が生成された
- 従来はこの360件分を人が組み立てていた
- 人の役割の変化:
- 生成物はそのままでは使えず修正が入る
- ゼロから書くのとレビューして直すのとでは、時間も頭の使い方も違う
- 人の仕事が「書く」から「レビューする」に移る
- 上流の精度の重要性:
- TRSが雑なら、雑なテスト設計が大量に出てくる
- 人が書くのはTRSだけなので、上流の精度がそのまま下流の質になる
■ 6. AIに書かせる際の注意点
- 期待値の正:
- テストの期待値の正は仕様書とデザインであり、実装ではない
- 実際に起きた事例:
- AI支援でTRSを作成中、ある画面の絞り込み条件が「確定」としてACに書かれていた
- 根拠を確かめるとフロントエンドの実装コードだった
- 実装を根拠に期待値を決めないようAIに指示した
- 実装から期待値を作る問題:
- テストが「コードがコード通りに動くこと」の確認になる
- 仕様と実装のズレは定義上ひとつも見つからず、テストの意味が消える
- 人間とAIに共通する傾向:
- 人間も仕様が曖昧なときはコードを見に行きたくなる
- AIは素直なので放っておくと確実に実装を参照する
- もっともらしい文章で書くため、根拠を確かめないと気づけない
- 運用ルール:
- 期待値の根拠は仕様書とデザインとする
- 実装は「その状態を作れるか」を確かめるためだけに見る
- 仕様書とデザインのどちらにも書かれていなければ「未定義」として扱う
- 3つめのルールの重要性:
- 外すと未定義を実装で埋めてしまい、Open Issuesに書くべきものが消える
- Open Issuesの仕組みが丸ごと効かなくなる
■ 7. まとめ
- ドキュメントが1つ増えることへの抵抗:
- 身構えるのは自然で、当初は同じだった
- 実際には増えた手間より後で楽になる分のほうがずっと大きい
- 変えたこと:
- 因子水準を整理し組み合わせてテストパターンに落とす流れは従来どおり
- 「何を1つの単位として切るか」を決まった形であらかじめ書くようにした
- 推奨:
- 設計書の記載量が増えるほど追いにくくなる感覚があれば、切り口の決め方を先に固める価値がある