第1回では、AI時代に求められる思考力とは何かを問い直しながら、「抽象化」と「アナロジー」という武器の正体を解き明かしました。
分類学をアナロジーに、クジラとカバが実は親戚であるという驚きとともに、具体から本質を抜き出す面白さを感じてもらえたでしょうか。
今回はいよいよ実践編。抽象化とアナロジーを、テスト・QAの現場でどう使うか。テスト観点の洗い出し、同値分割法、状態遷移モデル、そして過去の不具合や競合製品からの類推まで、具体的な手法を通じて「考える力」を使いこなすヒントをお届けします。
抽象化をテストに活用する
抽象化は、具体的な仕様から本質的なテスト観点を抜き出し、体系的で漏れのないテストを効率的に設計するために活用することができます。
1. テスト観点の洗い出しと体系化
個別の機能仕様をそのままテストするだけでなく、それらに共通する「本質的な振る舞い」を抽象化してテスト観点を洗い出します。
例えば、「ユーザー登録画面」「商品購入画面」「問い合わせフォーム」など、入力フォームを持つ複数の画面があります。これらから「入力処理」という概念を抽象化し、「必須項目チェック」「文字数チェック」「型チェック（数値、メールアドレス形式など）」「禁止文字チェック」といった共通のテスト観点を導き出します。これにより、個別の画面ごとにゼロから観点を考える必要がなくなり、テストの抜け漏れを防ぐことができます。
2. テスト技法の適用（同値分割法・境界値分析）
テスト技法そのものが、抽象化の考え方に基づいていることもあります。
例えば、同値分割法を使って「18歳以上が利用可能」という仕様に対し、無数にある年齢の入力パターンを考えます。これを「17歳以下（無効）」「18歳以上（有効）」という2つの抽象的なグループ（同値クラス）に分けます。そして、各グループから代表的な値を一つずつ（例：10歳、25歳）選んでテストすることで、効率的に入力値の検証ができます。これは、具体的な値を「有効」「無効」という概念に抽象化する思考プロセスです。
3. テストモデルの作成
システムの振る舞いを、状態遷移図やデシジョンテーブルといった抽象的なモデルに落とし込むことで、複雑なロジックを網羅的にテストすることができます。
例えば、状態遷移図を使ってECサイトの注文ステータス（「注文受付」→「入金待ち」→「発送準備中」→「発送済み」→「完了」/「キャンセル」）を状態遷移図としてモデル化します。この図を基に、全ての状態と全ての遷移パターンをテストすることで、ロジックの抜け漏れや意図しない状態遷移がないかを確認できます。
アナロジーをテストに活用する
アナロジーは、過去の経験や他の類似システムから類推することで、仕様書には書かれていない潜在的な欠陥や、ユーザーが陥りやすい問題を発見するために活用されます。特に、アナロジーは経験ベースのテストで威力を発揮すると感じています。
1. 過去の不具合事例からの類推
過去のプロジェクトで発生した不具合は、アナロジーを使えばテストケースの宝庫になるかもしれません。
例えば、「以前開発したAというシステムの決済機能で、通信が途切れた際に二重課金される不具合があった。今回のBシステムも同じ決済代行会社を使っているから、同じような状況を再現するテストをしてみよう」と考えることは、過去の事例とのアナロジー（類推）によって、新たなテストケースを発想しています。
2. 類似製品や競合他社からの類推
テスト対象と似た機能を持つ他の製品の挙動は、ユーザーの期待や潜在的な問題点を教えてくれます。
例えば、「競合のCというアプリでは、大量のデータをスクロールするとパフォーマンスが著しく低下する。我々のアプリも似たような一覧表示機能があるので、同様に大量データを登録して性能をテストすべきだ」と考えることで、仕様には明記されていない非機能要件（パフォーマンス）のテスト観点を得ることができます。
3. 実世界のアナロジー
システムの振る舞いを、身近な実世界の出来事に例えることで、ユーザー視点のテストケースを発想します。
例えば、「この会議室予約システムは、ホテルの予約と似ている。ホテルなら『ダブルブッキング』『直前のキャンセル』『連泊予約の途中の日程変更』といった複雑なケースがある。システムでもこれらの操作を試してみよう」と考えることで、単機能のテストだけでは見つけにくい、複数操作が絡んだシナリオテストのアイデアが生まれます。
まとめ: 具体と抽象の「往復」が思考の質を変える
ここまで、分類学という学問をアナロジーに、「抽象化」と「アナロジー」が私たちの思考にどのような恩恵をもたらすかを見てきました。
クジラとカバが親戚であるという驚きは、私たちが「外見」という具体に囚われていたからこそ生じるものです。「胃の構造」や「蹄の数」という抽象のレベルで世界を捉え直したとき、初めてそこに隠れた本質的な繋がりが見えてきます。
これは、日々のテスト業務やQA活動においても全く同じことが言えます。
目の前の仕様書（具体）をただなぞるのではなく、そこにある「共通項」を見抜くこと。そして、過去の失敗や他者の知恵を「あ、これはあのパターンだ」と今の課題に転用（アナロジー）すること。この抽象化のプロセスこそが、複雑化する現代のシステムを効率よく、かつ深く検証するための強力な武器になります。
