テスト設計コンテストというコンテストのアイデアを練る中で、儚くもボツになった内容を書き残しておきます。
はじめに
LLMを活用して、テスト観点*1を導出する場合、短時間で多くの視点を得られる反面、一見整理された文章で出力されるため、その出力が十分なのか、誤りは含まれていないのかを人間が判断するのが難しいという課題があります。
そこで、メタファーを用いれば、LLMが導出したテスト観点と向き合うことができ、人間自身が思考するきっかけを作ることができるのではないかと考えました。
TRIMについて
Trail-map-based Route and Interaction Method (TRIM)は、テスト対象のソフトウェアやシステムを山や森に見立て、その山を登る(登山)ことを想像しながら、テストの中で「どこをどう確認すればよいか」を整理するためのフレームワークです。 登山という比較的イメージしやすいメタファーを用いることで、LLMと対話(Interaction)することを目指しています。
TRIMは、登山道を中心に、以下のような要素で構成されます。
- 山頂
- 登山道
- 樹海
- 天候
- 登山者の属性
- 地図の破れ・歪み
- 落石
- 道しるべ
- 山の管理者
各エリアの詳細は次のとおりです。
山頂
ユーザーが最終的に達成したい目的地を示します。 操作上のゴールだけでなく、サービスを通じて得たい本質的な価値も含みます。
例えば、ホテルの予約完了という操作上のゴールだけでなく、旅行を楽しみたいという本質的な価値も含まれます。
登山道
登山道は、ユーザーがシステムを「どのように利用するか」という典型的な操作の流れを指します。これはユーザーが特定の目的を達成するために行う「一連の行動」そのものです。例えば、「チケットを探して予約し、決済する」といった一連のステップが含まれます。
樹海
通常のルートから外れた予測困難で危険な領域を指します。 入力の限界値や過去の問題領域、仕様の隙間を含みます。
天候
天候とは、システムの外側を取り巻く環境や条件を表すメタファーです。 通信環境、端末の種類、ネットワークの状態、外部サービスの稼働状況、法的規制など、システムを取り巻く外部要因を記載します。
登山者の属性
登山者の属性は、システムを利用する「人の特徴・スキル」に着目します。 例えば、年齢層、システムを利用する回数、障がいの有無、異なる言語、悪意を持ったユーザなどが含まれます。
地図の破れ・歪み
要求仕様の曖昧さや不明点を指します。どの部分の仕様が不明確かを特定するための視点です。
落石
予期せぬ入力や操作によるエラーや例外発生を指します。システムが正常な処理を行えず、ユーザーの行動を妨げる可能性のある事象を列挙します。
道しるべ
ユーザーが迷わず目的の機能にたどり着けるかを確認する視点です。UIやナビゲーションの分かりやすさ、操作性、一貫性を含みます。
山の管理者
システムの健全性やトラブル対応力を支える運用・監視の視点です。ログ出力・システム監視、バックアップなどの視点を含みます。
出力フォーマット
テストベースと、これらの定義を読み込ませた上で、json形式で、以下のフォーマットに従って出力させます。 エリアの名称と、そのエリアに含まれる観点を出力させ、その根拠となったドキュメントをsourcesとして列挙させます。
{ "sources": [ {"id": "1", "name": "hogehoge.md"}, {"id": "2", "name": "hogahoga.md"} ], "sections": [ { "name": "山頂", "items": [ {"text": "チケットの予約が行えること", "source": ["1", "2"]} ] } ] }
json形式を扱いやすくするために
このjsonを付箋形式で便利に扱うためのVSCode拡張機能まで作っちゃいました。*2
でも、公開していないです。でも、どうしても興味がある方はこっそりとご連絡ください。
このフレームワークの課題
ボツになった理由はいくつかあります。
- なんとなくそれっぽい出力は出てくるものの、抽象的なものから具体的なものまで挙げてくるので、元々やりたかった「それが十分なのか」を判断するには不十分
- ここで出力したテスト観点をどうテストに落とし込んでいくのか、TRIMの考え方を活かした方法が思い浮かばなかった
- 富士山をメタファーにした考え方がすでにある
一方で、異なるテスト対象に対しても、出力の型を決めて毎回同じ型で出力させるというやり方は、TRIMに限らず有効だと感じました。
