テストマトリクスとは？作り方・サンプル・パターン網羅まで実務目線で解説

テストマトリクスとは、テスト対象（機能・画面・項目）とテスト観点（正常系・異常系・境界値など）を縦横の表で交差させ、「どこを・どの観点で・どこまで」テストするかを一枚で可視化するドキュメントです。交点のセルにテストの要否を書き込むことで、検証済みの範囲と手つかずの範囲がそのまま目に見えます。この記事では定義から作り方の4ステップ、コピーして使える実物のサンプル表、テストパターンを減らすペアワイズ法、デシジョンテーブルやトレーサビリティマトリクスとの違い、そして向かない場面までを実務目線で整理します。

まとめ：テストマトリクスの要点

• 正体は「テスト対象 × テスト観点」を交差させた表。交点のセルにテストの要否（●＝必須／-＝任意／×＝対象外）を記入し、網羅状況を一目で確認する。
• 目的は網羅性の可視化と抜け漏れの検知。空欄や×が未検証エリアとして浮かび上がるため、リスクの高い箇所を着手前に特定できる。
• 作り方は「テスト対象の洗い出し → テスト観点の決定 → セル記入 → レビューと更新」の順。1つの用途に1枚を守ると見やすさが保てる。
• 組み合わせが爆発するときはペアワイズ法（オールペア法）で削減する。3因子3水準なら全27通りのテストを9通りまで圧縮できる。
• デシジョンテーブルは条件と動作の論理整理、トレーサビリティマトリクスは要求と成果物の追跡が役割で、テストマトリクス（対象×観点の網羅管理）とは目的が異なる。
• 1枚に詰め込みすぎると形骸化する。確認したいパターンごとにシートを分けるのが実務の定石。

以下では、各ポイントを具体例とサンプル表とともに掘り下げます。

テストマトリクスの定義と表の構成

テストマトリクス（マトリックス表とも呼ばれます。英語では test matrix）は、二次元の表で網羅性を管理するテスト設計ドキュメントです。縦軸（行）にテスト対象を、横軸（列）にテスト観点を並べ、両者が交わるセルに「そのテストが必要かどうか・実施したかどうか」を記します。

構成要素は3つだけです。行のテスト対象は機能・画面・入力項目など検証する単位、列のテスト観点は正常系・異常系・境界値・ブラウザ差といった見る切り口、そして交点のセルがテストの要否と状態を表します。この単純な構造のまま規模を広げられる点が、記憶や口頭管理では追えなくなる大規模開発で重宝される理由です。セルの記号は●（必須）、-（任意）、×（対象外）のように3種類ほどに絞ると、表全体の状況把握が速くなります。

テストマトリクスを使う目的とメリット・デメリット

最大の目的は網羅性の可視化です。どの対象がどの観点でテストされているかを一覧化すると、テストされていないセルが空欄として残り、抜け漏れがそのまま見える化されます。例えばログイン機能で「異常系の入力」がテストされていなければ、該当セルの空白が警告として機能します。

メリットは複数あります。まず効くのが網羅性の確認、次いで進捗管理（実施・未実施・失敗をセルの色で管理）、関係者間の共通認識（開発者・テスター・マネージャーが同じ表を見ること）、そしてレビュー時の議論の土台です。一方でデメリットは更新コストに集中します。仕様変更が多い開発では表の最新化が後回しになりやすく、肥大化すると全体像がかえって見えなくなります。メリットとデメリットは同量ではありません。実務で最初に価値が出るのは「網羅の可視化」一点で、デメリットの大半は次章以降の作り方と運用ルールで抑え込めます。

テストマトリクスの作り方【4ステップ】

初めてでも、手順を分けて進めれば破綻しません。要件定義書や画面設計書を手元に置き、次の順で組み立てます。

ステップ1：テスト対象の洗い出し

最初に行うのは、テストすべき対象を漏れなく列挙することです。要件定義書・仕様書・画面設計書・フローチャートを確認し、機能や画面、入力項目を粒度をそろえて並べます。ここで対象が曖昧だと表全体の精度が崩れるため、機能No・画面No・項目Noのように識別番号を振り、どの機能のどの項目かを後から追える形にしておきます。

ステップ2：テスト観点の決め方（正常系・異常系・境界値）

次に、各対象を「どの切り口で見るか」を決めます。観点が「入力チェック」のように抽象的だとテストケースに落とせないので、「未入力」「最大長超過」「禁止文字」「形式違い」のように具体化します。代表的な観点は正常系・異常系・境界値・状態遷移・権限差・ブラウザやデバイス差です。確認観点や試験観点という言葉で呼ばれることもありますが、要は「対象ごとに何を見れば品質を保証できるか」を分類する作業です。観点の定義はチームで統一し、用語の揺れをなくしておきます。

ステップ3：Excel・スプレッドシートでのセル記入

テストマトリクスはExcelやGoogleスプレッドシートで作るのが一般的です。行に対象、列に観点を配置し、交点のセルに記号を入れていきます。実施状態は「未実施・成功・失敗・対象外」を色分け（成功＝緑、失敗＝赤、未実施＝黄）すると、進捗が一目で読み取れます。条件付き書式を使えば入力に応じて自動で色が変わり、見出し行を固定すればスクロールしても観点を見失いません。

ステップ4：レビューと更新ルールの設計

作ったら必ずレビューにかけます。観点の漏れ・重複、粒度のばらつき、命名の不統一を、開発者とテスト担当の両方の目で確認します。さらに重要なのが更新ルールです。仕様変更が起きたときに「誰が・いつ・どこを直すか」を決め、変更履歴を別シートかバージョン管理ツールに残しておくと、後からの追跡が容易になります。更新が止まったマトリクスは、実装とずれた瞬間に信頼性を失います。

テストマトリクスのサンプル（実物の表で見る）

言葉だけでは伝わりにくいので、ログイン機能を例にした最小のサンプルを示します。行が入力項目、列が観点、セルがテストの要否です（●＝必須、-＝任意、×＝対象外）。

この一枚だけで、「ログインボタンのブラウザ差はテスト対象だが、パスワードのブラウザ差は任意」といった判断が共有できます。空欄を作らず、対象外も×で明示します。空白を「未検証」と「もともと不要」のどちらにも読めてしまうと、抜け漏れ検知の機能が働かなくなります。サンプルは一度作れば社内の標準テンプレートとして再利用でき、次のプロジェクトの立ち上げが速くなります。

テストパターンの網羅と削減（組み合わせ爆発への対処）

テストマトリクスが本領を発揮するのは、条件が複数絡んでテストパターンが膨れ上がる場面です。ここを設計せずに総当たりすると、工数が現実的でなくなります。

組み合わせ爆発とパターン表での可視化

例えばECサイトの購入フローで「ユーザー種別（一般・会員・法人）」「デバイス（PC・スマホ）」「決済手段（クレジット・コンビニ・電子マネー）」が絡むと、単純な総当たりで 3×2×3＝18通り、条件が増えればさらに桁が跳ね上がります。これをテストパターン表（各条件を軸に取ったマトリクス）に展開すると、どの組み合わせを実施するか・優先するかを視覚的に整理できます。まず全体像を表で並べ、そこから減らすのが正しい順序です。

ペアワイズ法（オールペア法）でケースを減らす【27→9】

ソフトウェアの不具合の多くは、1つまたは2つの因子の組み合わせで起きるという経験則があります。これを根拠に、すべての2因子ペアの水準組み合わせを最低1回ずつ網羅すれば、全組み合わせを試さなくても実用上の網羅性を保てるという考え方がペアワイズ法（オールペア法）です。具体的には、3因子3水準のケースで全組み合わせは27通りになりますが、ペアワイズ法なら9通りまで削減できます。

似た技法に直交表がありますが、直交表が全因子・全水準を均等に出現させるのに対し、ペアワイズは「ペアが1回以上現れればよい」とゆるめます。今回の3因子3水準では直交表（L9）も9通りで同数ですが、因子や水準が増えるほどペアワイズの方がケース数は少なくなります。PICTやPictMasterといった生成ツールを使えば、因子と水準を入力するだけで削減後の組み合わせが得られます。

境界値分析・同値分割との組み合わせ

パターンを減らすもう一つの軸が、各因子の代表値の選び方です。入力値を「正常な範囲」「最小値」「最大値」「限界を超えた値」に分けて代表ケースだけを取る境界値分析と、同じ挙動になる入力をひとまとめにする同値分割を使うと、各観点で試すべき値そのものが絞れます。これらはブラックボックステストの基本技法で、考え方はブラックボックステストとホワイトボックステストの基本的な違いとは何かで詳しく整理しています。テストマトリクスの観点列にこれらの技法を割り当てると、削減の根拠を説明しやすくなります。

削減してよいケースの線引き

削減には品質リスクが伴います。減らしすぎれば未検証の組み合わせで不具合が出ます。線引きの基準は、利用頻度・障害が起きたときの影響度・変更の入りやすさです。利用頻度が高くトラブル時の影響が大きい組み合わせは削らず残す、逆に低頻度かつ影響の小さい組み合わせから優先的に外す、というリスクベースの判断を取ります。そして削ったケースは「なぜ外したか」を記録に残しておきます。後の見直しや、外部レビューで判断の根拠を示すときに、この記録が効いてきます。

テストマトリクスと他のテスト設計手法の違い

「マトリクス」と名の付く表は複数あり、混同されがちです。デシジョンテーブル、トレーサビリティマトリクス、テスト観点表は、整理する軸も目的も別物です。

デシジョンテーブル（決定表）は、条件の組み合わせとそのときの動作を表にしたもので、仕様の分岐ロジックを漏れなく確認するために使います。テストマトリクスが「対象をどの観点で見るか」を管理するのに対し、デシジョンテーブルは「ある条件群でシステムがどう振る舞うべきか」を定義します。トレーサビリティマトリクス（要求トレーサビリティマトリクス、RTM）は、要求と設計・コード・テストケースの対応を追跡し、要求漏れや仕様変更の影響範囲を押さえるための表です。テストマップという呼び名で観点の地図を指すこともありますが、いずれもテストマトリクスの代わりではなく、目的に応じて併用するものと捉えると整理がつきます。

テストマトリクスが向かない場面と失敗パターン

テストマトリクスは万能ではありません。次の場面では、無理に使うとかえって品質管理を鈍らせます。

第一に、確認したい用途が異なるパターンを1枚に詰め込むのは失敗の典型です。テキストボックスの文字数チェックとチェックボックスの組み合わせ確認を同じ表に混ぜると、無関係なセルで埋め尽くされ、横に延々とスクロールする読みにくい表になります。用途ごとにシートを分けるべきです。第二に、条件分岐そのものの仕様確認が目的なら、テストマトリクスではなくデシジョンテーブルを選びます。第三に、更新体制を用意できないプロジェクトでの運用は避けます。仕様変更のたびに直す担当とルールがないと、表はすぐ実装とずれ、形だけ残って誰も見ない資料になります。「作ること」が目的化したマトリクスは、網羅性の確認という本来の価値を生みません。粒度をそろえ、用途を絞り、更新し続けられる範囲で作る——この三点を守れないなら、チェックリストなど軽い手段に切り替えた方が実務は回ります。

よくある質問（FAQ）

テストマトリクスとテストケースの違いは？

テストケースは「特定の条件で何を入力し、どんな結果を期待するか」を記した個別の手順書です。テストマトリクスは、それらのケースがどの対象・どの観点に対応しているかを俯瞰する一覧表です。マトリクスで網羅すべき範囲を設計し、各セルの中身を具体化したものがテストケース、という関係になります。

結合テストでもテストマトリクスは使える？

使えます。単体テストでは機能や画面の項目を対象に取りますが、結合テストでは「連携する機能の組み合わせ」や「データの受け渡し経路」を対象に置き換えれば、同じ構造で網羅を管理できます。テストレベルごとの考え方は単体テストと結合テストはもう古い！Google流テストサイズとは？もあわせて参考にしてください。

デシジョンテーブルとの違いは？

整理する軸が異なります。デシジョンテーブルは「条件 × 動作」で分岐ロジックを定義する表、テストマトリクスは「テスト対象 × 観点」で網羅状況を管理する表です。複雑な条件分岐の仕様を確認したいならデシジョンテーブル、テスト全体の抜け漏れを管理したいならテストマトリクスを選びます。

Excelのテンプレートはどう作る？

1枚目にテスト対象の一覧、2枚目に観点の一覧を置き、3枚目で両者を掛け合わせたマトリクスを作る構成が扱いやすいです。状態管理用のプルダウン（未実施・成功・失敗・対象外）と条件付き書式での色分けを入れておくと、進捗の集計まで一つのファイルで完結します。

テストパターンはどこまで減らしてよい？

利用頻度・障害影響・変更頻度の三軸でリスクを評価し、影響の小さい低頻度の組み合わせから外すのが基本です。ペアワイズ法で全2因子ペアを網羅していれば、実用上の網羅性は確保できます。減らした組み合わせとその理由は記録に残し、リリース後に問題が出た際に見直せるようにしておきます。

関連記事

• ブラックボックステストとホワイトボックステストの基本的な違いとは何か
• 単体テストと結合テストはもう古い！Google流テストサイズとは？
• AI品質・AIテストの基本的な考え方：従来のソフトウェアテストとの違い
• Testing Trophyとは何か？Kent C. Dodds氏提唱の新テスト指針の概要と背景を徹底解説