株式会社FLINTERSでエンジニアをしている工藤です。
ソフトウェア開発の品質保証において、テストケースの作成は核心的な作業です。
しかし、その作成方法一つで、テストの信頼性や効率は大きく変わってきます。
本記事では、属人的になりがちなテストケース作成から脱却し、組み合わせテストの考え方をベースにした「テストマトリクス」の活用法について紹介します。
箇条書きリストのテストケースが抱える問題点
「テストケースを作成してください」と依頼されたとき、以下のような箇条書きリストを作成していませんか？
- 正常なユーザー名とパスワードでログインする。
- パスワードを空欄にしてログインを試みる。
- ユーザー名の文字数を最大長で試す。
作成した本人は「このリストで十分」と感じるかもしれません。
しかし、こうした経験や思いつきに基づいたリストには、以下の問題が潜んでいます。
- 意図の読み取りにくさ
- 第三者には、「なぜそのテストが必要なのか」「何を考慮した結果、このケースになったのか」といった設計意図が伝わりにくい。
- 網羅性の欠如
- 複数の入力項目や条件が絡む複雑な機能では、「特定の組み合わせ」の考慮が抜け落ちやすく、重要なバグを見逃すリスクが高まる。
こうした属人性を排除し、誰もが理解できる形でテスト範囲を可視化することが、次のステップです。
テストマトリクスが「考慮漏れ」を防ぐ仕組み
この問題に対し、体系的なアプローチを提供するのが「テストマトリクス」です。
テストマトリクスは、テスト対象の入力項目や条件を整理し、それぞれの値や状態の組み合わせを一覧化した表形式のドキュメントです。
マトリクスのメリット
- 網羅性の可視化
- 縦軸と横軸（または列）に項目を割り当てることで、テストすべきすべての組み合わせが一目で確認できます。
- 客観的なレビュー
- 「この条件とこの値の組み合わせは試したか？」と、具体的な議論が可能になり、レビューの質が劇的に向上します。
- テスト設計の思考ツール
- 項目と値の洗い出しから組み合わせの決定に至る過程で、設計者の思考が整理され、テストへの抜け漏れを防ぐ効果があります。
テストマトリクスの具体的な書き方
ここでは、シンプルな「ユーザー設定更新機能」を例に、テストマトリクスの作成手順を解説します。
（１）入力項目とテスト値の洗い出し
まず、テスト対象の機能に関わる入力項目（または条件）を特定し、その項目に対して適用すべき代表的なテスト値や状態を列挙します。
| 入力項目/条件 | 代表的なテスト値/状態 | 目的/分類 |
|---|---|---|
| ユーザーID | 正常値 / 最大文字数 / 未入力（空欄） | 境界値、異常系 |
| 通知設定 | ON / OFF | 機能の正常動作 |
| 年齢 | 18歳 / 17歳（下限境界） / 正常値（例：30歳） | 境界値 |
質の高いテスト値の選び方
ここで、「テスト値の洗い出し」は、闇雲に行ってはいけません。
網羅性を高めるためには、古典的かつ強力なテスト設計技法を組み合わせます。
-
同値分割 (Equivalence Partitioning)
- 入力値の範囲を「同じ挙動を示す」と期待されるグループ（同値クラス）に分割し、各グループから代表値を一つ選んでテストする手法です。これにより、無駄な重複テストを排除します。
- 例：年齢制限が18歳以上の場合、「18歳以上」と「18歳未満」という二つの同値クラスに分割します。
-
境界値分析 (Boundary Value Analysis)
- 不具合は、有効な値と無効な値の境目（境界）で発生しやすいという知見に基づき、その境界値（例：最大値、最小値、±1の値）を重点的にテストする手法です。
- 例：最大文字数が10文字の場合、「10文字（有効境界）」「11文字（無効境界）」「9文字（有効値）」をテストします。
テストマトリクスの行と列は、この同値分割と境界値分析で洗い出された「代表的な値」で構成すべきです。
この基礎を徹底することで、マトリクスの設計品質が保証されます。
（２）組み合わせの定義とマトリクスの作成
次に、これらの値の組み合わせをテストケースとして定義し、マトリクス形式に落とし込みます。
各行が1つの実行すべきテストケース（シナリオ）に対応します。
| No. | ユーザーID | 通知設定 | 年齢 | 期待される結果 | 備考 |
|---|---|---|---|---|---|
| T-01 | 正常値 | ON | 正常値 (30歳) | 正常に更新される | 正常系（基本パターン） |
| T-02 | 正常値 | ON | 18歳 | 正常に更新される | 境界値テスト（年齢：有効） |
| T-03 | 正常値 | ON | 17歳 | エラー (登録不可) | 境界値テスト（年齢：無効） |
| T-04 | 正常値 | OFF | 正常値 (30歳) | 正常に更新される | 準正常系（通知設定OFF） |
| T-05 | 最大文字数 | ON | 正常値 (30歳) | 正常に更新される | 境界値テスト（ID） |
| T-06 | 未入力 | ON | 正常値 (30歳) | エラー (ID必須) | 異常系テスト（ID） |
（３）テストケース削減技法：ペアワイズ法
項目が増えるほど、すべての組み合わせをテストすることは非現実的になります（組み合わせ爆発）。
例えば、項目が10個、それぞれに3つのテスト値がある場合、テストケースは3の10乗で59,049通りにもなります。
ここで役立つのが、テストケースを効率的に削減する組み合わせテスト技法です。
特に広く使われるのが「ペアワイズ法（Pairwise Testing）」です。
ペアワイズ法は、「ほとんどのバグは、2つのパラメータの特定の組み合わせによって引き起こされる」という統計的知見に基づき、すべてのパラメータのペア（2要素の組み合わせ）を最低1回はテストできるように、テストケースを大幅に削減する手法です。
この手法を用いれば、網羅性を大きく損なうことなく、テストケース数を実用的なレベルにまで削減することが可能です。
具体例：ペアワイズ法による削減効果
3つの入力項目（A, B, C）があり、それぞれ3つのテスト値（1, 2, 3）を持つと仮定します。
| 項目 | 値1 | 値2 | 値3 |
|---|---|---|---|
| A | A1 | A2 | A3 |
| B | B1 | B2 | B3 |
| C | C1 | C2 | C3 |
【全件テスト（全組み合わせ）の場合】
3 × 3 × 3 = 27通りのケース数が必要です。
【ペアワイズ法を適用した場合】
この9種類のペア（A1-B1, A1-B2, ..., C2-B3など）をすべてカバーするための最小限のケース数は、9通りに削減されます。
| No. | A | B | C | 備考 |
|---|---|---|---|---|
| T-01 | A1 | B1 | C1 | A1を含むペアをカバー |
| T-02 | A1 | B2 | C2 | A1を含むペアをカバー |
| T-03 | A1 | B3 | C3 | A1を含むペアをカバー |
| T-04 | A2 | B1 | C2 | A2を含むペアをカバー |
| T-05 | A2 | B2 | C3 | A2を含むペアをカバー |
| T-06 | A2 | B3 | C1 | A2を含むペアをカバー |
| T-07 | A3 | B1 | C3 | A3を含むペアをカバー |
| T-08 | A3 | B2 | C1 | A3を含むペアをカバー |
| T-09 | A3 | B3 | C2 | A3を含むペアをカバー |
複雑なツールを使わずとも、この手法を活用するだけで、テスト工数を大幅に削減しつつ、高いカバレッジ（網羅率）を維持できます。
テストマトリクスを品質保証の武器に
テストマトリクスは、単に「表を作る作業」ではなく、「何をテストし、何を網羅したか」を論理的かつ客観的に証明するためのドキュメントです。
- 誰でもわかる可視化によって、属人性を排除します。
- 項目と値の列挙によって、テストの抜け漏れを防ぎます。
- ペアワイズ法といった手法と組み合わせることで、効率性と網羅性を両立します。
あなたのチームのテストプロセスにテストマトリクスを導入し、「なんとなく」のテストケースから、論理的な品質保証へとステップアップしましょう！
Discussion