古典テスト技法 × モデリング × LLM
QA学園・放課後再現部「これ、MBTってことですよね？」
※このエントリは、創作世界「QA学園」を舞台にした
テスト設計／LLM活用のストーリー仕立て解説です。
内容はかなり実務寄りですが、登場人物はフィクションです。
0. 今日のテーマ：「これMBTってことで合ってますか？」
放課後、QA学園の「再現部」の教室。
- ユウタ：現場寄りQA、テスト設計担当見習い
- テラ：モデル厨。因子水準表／状態遷移が大好物
- アヤ：ユーザ体験と感情の波形（Ew）に敏感な人
- 言坂先生（ことさか）：品質アーキテクトな担任
- QA-Lite：教室に置かれたLLM端末
今日も、フォームのテストをどうやって設計するか、という話をしていた。
1. 仕様だけ食べさせたAIのテストが「惜しい」
まずはユウタの一言から、議論が始まる。
ユウタ「先生、LLM（QA-Lite）に
『この画面のテストケース出して』って頼むと、
それっぽいんですけど 抜けとダブりが多い んですよね。」
テラも頷く。
テラ「仕様書の文章だけ渡してるから、
QA-Lite の中で暗黙にモデルを組み立ててるはずなんですけど、
どんなモデルで考えてるかが見えない のがネックですね。」
アヤの違和感は、もう少し感情寄りだ。
アヤ「なんか、“ここ刺してほしい”ってところじゃない観点を
ひたすら攻めてくる時あるんだよね。
ユーザー Ew 的には “そこじゃない” っていう。」
ここで、言坂先生が口を開く。
言坂先生「じゃあ今日は、
古典的なテスト技法を“モデル”としてAIに教えたらどう変わるか、
それと、
『それっていわゆる MBT（Model-Based Testing）なのか？』
を一緒に確かめてみようか。」
2. 各自の役割：古典技法を「モデル」として言語化する
言坂先生はホワイトボードに３つの箱を書く。
- 同値分割・境界値
- 状態遷移・決定表
- シナリオ／探索的テスト
そして３人に、それぞれ担当を振った。
- ユウタ：同値分割・境界値
- テラ：状態遷移・決定表
- アヤ：シナリオ／探索的テスト
2.1 ユウタ：同値分割・境界値 → 因子・水準表への落とし込み
題材はログイン画面。
- メールアドレス
- パスワード
- 「利用規約に同意」チェックボックス
ユウタは、同値分割・境界値を 因子・水準表（FL表） に落とし込んでいく。
因子A: メールアドレス形式
- A1: 正形式
- A2: 不正形式
因子B: パスワード長
- B1: 最小未満
- B2: 最小ちょうど
- B3: 最大ちょうど
- B4: その他
因子C: 規約チェック
- C1: ON
- C2: OFF
2.2 テラ：状態遷移・決定表 → フローのモデル
まず、ユウタの一言から。
ユウタ「同値分割って、
要は 入力空間を“意味のあるクラス”にまとめる操作 ですよね。
これをそのまま QA-Lite に渡して、
『この因子と水準を前提に、代表テストを出して』って頼んでみたい。」
テラは、対象として「パスワード再設定フロー」を選びます。
フローの代表的なステップはこんな感じです。
- メールアドレス入力
- メール送信
- トークン検証
- 新パスワード設定
- 完了画面
各ステップには、例えば次のような分岐があります。
- 成功／失敗の遷移
- トークン期限切れ
- 再送要求
テラはこれを 状態遷移図 ＋ 簡易決定表 に落とします。
テラ「状態遷移図は、
“どの順番で世界が動くか” のモデル で、
決定表は、
その場ごとの条件と結果の対応 です。
これを QA-Lite に渡して、
『各遷移を少なくとも1回は通るテストフローを列挙して』
ってお願いしてみます。」
2.3 アヤ：シナリオ／探索的テスト → ユーザーストーリー＋Ew
アヤは Kノートを開き、ユーザーストーリーを書き出します。
たとえば、こんなシナリオです。
- 「深夜2時、眠くてイライラしながらパスワード再設定をする」
- 「電波が不安定な電車内で、再設定リンクを踏む」
それぞれの場面で、
- どこで不安・怒り・不信感（Ew）が上がりやすいか
をメモしていきます。
アヤ「探索的テストって、
ユーザーの感情の波形（Ew）に沿ってシナリオを歩く技法 だと思ってて。
QA-Lite には
『このシナリオで Ew を悪化させないためのテスト出して』
って頼みたい。」
3. 仕様だけ vs モデル込み：AIの出力はこう変わる
3.1 仕様だけ渡したとき（Before）
まずは対照実験として、仕様テキストだけを QA-Lite に渡し、
「テストケースを10件提案して」
と依頼した結果はこんな感じでした。
- 典型的な「空値」「形式不正」「長すぎる」テストは出る
- しかし…
- クラス代表値のダブりが多い
- 実際には辿れない画面遷移を前提としたテストが混ざる
- ログイン → 再設定 → 再ログイン…といった“流れ”が薄い
ユウタ「すごく雑ではないけど、
“このままテスト設計に採用するには足りない” 感じですね。」
3.2 モデル込みで渡したとき（After）
次に、さっき 3 人が作ったモデルを前提として QA-Lite に渡します。
- 同値分割・境界値 → 因子・水準表
- 状態遷移・決定表 → フローモデル
- シナリオ＋Ew → ユーザー状況の定義
このうえで、QA-Lite には例えば次のように指示します。
- 「この因子・水準を使って、重複しない同値クラス代表テストを列挙して」
- 「この状態遷移図の 各遷移をすべて通るテストフロー を出して」
- 「このシナリオの Ew が悪化しないか確認するテスト も追加して」
その結果──
同値分割／境界値
- 各水準から代表値が1つずつ取り出され、ダブりが減る
- 境界値も明示的にカバーされる
状態遷移
- 与えたフロー内で、現実的な 正常系＋異常系パス が揃う
シナリオ／探索的
- 「深夜で眠い」「電波不安定」といった状況に紐づいた
具体的なテストが出てくる
テラ「モデルを先に人間が握ってから AI に仕事を振ると、
ここまで出力の質が変わるんですね。」
4. これって結局 MBT なの？（先生パート）
ここでテラが、前から気になっていたことを聞きます。
テラ「これって、
欧米でやってるっていう MBT（Model-Based Testing） なんですか？」
言坂先生は、少し考えてから頷きます。
言坂先生「考え方としては ほぼMBT だね。
画面やフローを“モデル”として明示して、
そこからテストケースを導く。
ただし──」
と指を一本立てて続けます。
言坂先生「クラシックな MBT はね、
- UML ステートマシンや形式的なモデルをきっちり書いて
- 専用ツールでテストを自動生成する
というスタイルが多い。
今日やったのはそこまでガチガチじゃなくて、
“軽量MBT＋LLM” くらいの位置づけ だね。」
ユウタがまとめます。
ユウタ「つまり、
古典技法でモデルを作って、
ジェネレータ部分を LLM にやらせてる
って理解でいいですか？」
言坂先生「その通り。
“技法そのもの” を AI にやらせるんじゃなくて、
人間が作ったモデルの上で、
列挙・組合せ・補完をさせる。
それが今日のやり方だね。」
アヤは Kノートに、一行だけメモします。
アヤ「“MBT的な考え方＋AI＝
ちゃんとモデル作った人が強い世界” って感じ。」
5. 実務に持ち帰るチェックポイント
最後に、先生がホワイトボードに 4 つのポイントを書きます。
-
LLM に丸投げしない
- 人間側で最初のモデル（FL表／状態遷移／シナリオ）を作る
- モデルは古典テスト技法を “圧縮表現” として使う
- 同値分割・境界値・状態遷移・決定表・探索的テスト
- LLM には、
- 「どのモデルを前提に、何を列挙してほしいか」を明示して伝える
- 出てきたテストは人間がレビューする
- 抜け・ダブり
- 現実に辿れるフローか
- ユーザー Ew 的に “そこじゃない感” がないか
言坂先生「MBTというラベルを使うかどうかは、正直どっちでもいい。
大事なのは、
“モデルを握った人間の頭の中” を、
AIにどうやって安全に共有するか なんだ。」
３人はそれぞれ、今日の Kノートに
自分なりの Fth（しきい値）を書き込んで、教室を後にしました。
おわりに
この放課後再現部エピソードでやっていたことを一言でまとめると、こんな感じです。
「古典テスト技法で作ったモデルを、
LLM に食べさせるライトウェイト MBT」
仕様だけ食べさせたときの “惜しい AI テスト” から一歩進んで、
- 人間側のモデリング力 × LLM の列挙力
を組み合わせるスタイルが、今後もう少し広がっていくのではないか、
という仮説も込めています。
あなたの現場では、
MBT 的なやり方と LLM をどう組み合わせていますか？