申請フローやログイン機能のように、「現在の状態によって、同じ操作でも結果が変わる機能」のテストに頭を悩ませていませんか。どのような観点でテストケースを作成し、どこまで網羅すればよいのか、判断に迷う場面は多いものです。
このような機能を漏れなく検証するには、「状態遷移表」を使って有効な遷移と無効な操作の組み合わせを整理し、目的に合った「カバレッジ基準」でテスト範囲を絞り込むアプローチが基本となります。
もし正常な操作の流れしか確認していないと、本来できないはずの不正な操作でデータが壊れるといった重大な不具合を見落としかねません。また、網羅の基準があいまいなままでは、関係者への説明やテストの品質保証も難しくなります。
この記事では、状態遷移テストの基本用語から、状態遷移表を使ったテストケースの作成手順、主要なカバレッジ基準の計算方法や実務上の注意点まで、わかりやすく解説します。
状態遷移テストとは
状態遷移テストとは、システムの状態変化とそれに伴う振る舞いを検証する「ブラックボックス型」のテスト設計技法です。主に状態遷移図や状態遷移表をもとにテストを組み立てます。
ソフトウェアには、同じ操作を行っても、その時点のシステムの状態によって異なる動きをする機能が数多くあります。たとえば同じ「承認」ボタンを押す場合でも、申請書が「作成中」なら操作できず、「審査中」であれば処理が進んで「終了」状態に切り替わります。
状態遷移テストの目的は、こうした「現在の状態」と「きっかけ（操作や入力）」の組み合わせを明確にし、システムが意図どおりに動作するかを確認することです。
正常な処理の流れだけでなく、状態遷移表を活用して「受け付けるべき操作」と「防ぐべき操作」の両方を漏れなく整理し、具体的なテストケースへと落とし込んでいきます。
1-1. 状態遷移テストの基本用語
状態遷移テストを理解するうえで、基本となる要素は「状態」「イベント」「遷移」の3つです。
- 状態：システムやデータが置かれている状況や条件（例：申請書の「作成中」「審査中」「終了」など）
- イベント：状態を変化させるきっかけとなる操作や入力（例：「申請」ボタンや「承認」ボタンのクリックなど）
- 遷移：イベントによって、ある状態から別の状態（あるいは同じ状態）へ移り変わること
たとえば申請処理の場合、レビュー待ちである「審査中」が【状態】、管理者が行う「承認」が【イベント】、審査中から「終了」へと切り替わることが【遷移】に当たります。
実際の設計では、特定の条件を満たしたときだけ遷移を認める「ガード条件」や、遷移に伴ってメール送信やデータ保存を行う「アクション」が加わることもあります。これらを整理してテストケースを組み立てていきます。
1-2. 向いているシステムとメリット
状態遷移テストは、現在の状態によって操作の可否や処理結果が変わるシステムの検証に力を発揮します。具体的には、以下のような機能が代表的です。
- 申請・承認を行うワークフロー機能
- ログイン状況によって利用できる画面や機能が変わるWebサービス
- 通信の接続・切断制御や、機器のモード切り替え
この技法を採用する最大のメリットは、状態とイベントの組み合わせを体系的に洗い出すことで、「無効な操作への対応漏れ」や「仕様書の記述不足」を早い段階で発見できる点です。テスト設計の時点で仕様のあいまいさに気づけるため、開発の手戻りを大幅に防げます。
ただし、画面ごとの入力チェックや複雑な計算ロジックなどは、このテスト技法だけではカバーできません。同値分割法やデシジョンテーブルテストといった他の技法と適切に組み合わせて進めることが重要です。
状態遷移図と状態遷移表
システムの状態と振る舞いを整理するツールには、「状態遷移図」と「状態遷移表」があります。図で全体像を視覚的に捉え、表を使って全パターンの組み合わせを漏れなく整理するのが基本的な進め方です。それぞれの違いと特徴を見ていきましょう。
2-1. 状態遷移図と状態遷移表の違い
状態遷移図と状態遷移表は、それぞれ得意とする役割が異なります。
状態遷移図は、システムが取り得る状態を枠（ノード）で表し、有効な遷移を矢印で結んだ図です。処理の流れや、状態が変わっていく順序を直感的に把握するのに向いています。
※状態遷移図の書き方や図式化の詳細は、状態遷移図の具体例と図式化するメリットをご覧ください。
一方、状態遷移表は、行と列を使って状態とイベントの全組み合わせを整理するマトリクス表です。状態遷移図では省かれがちな「許可されていない操作をしたときの挙動（無効な遷移）」まで一覧化できるため、テストケースの抜け漏れを防ぐうえで欠かせません。
2-2. 状態遷移表の書き方
状態遷移表は、一般的に行に「現在の状態」、列に「イベント（およびガード条件）」を配置して作成します。行と列が交差するセルには「遷移先の状態」を記入し、必要に応じて実行されるアクションも書き添えます。
作成時に意識したいのが、「同じ状態にとどまる正常な動作（自己遷移）」と「許可されていない不正な操作（無効な遷移）」の区別です。どちらも結果として「状態が変わらない」ように見えますが、仕様として認められた動きなのか、拒否すべき操作なのかを明確に分けなければなりません。
JSTQBの標準的な記法では、無効な遷移を「空欄」で表現することがあります。しかし実務では、空欄だと「検討が漏れている」のか「意図的に無効としている」のか判断がつきにくくなります。そのため、「拒否」「無効」「×」といった文字を明記するルールにしておくことをおすすめします。（出典：JSTQB「テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02（4.2.4 状態遷移テスト）」）
ここからは、理解を深めるための具体例として、「作成中・審査中・終了」の3つの状態と、「申請・取消・承認」の3つのイベントを持つシンプルな申請フローをもとに解説します。
状態遷移表を使ったテストケースの作り方
状態遷移表が完成したら、その内容をもとにテストケースを組み立てていきます。ここでは、以下の仮の仕様を例に進めます。
【今回の前提仕様】
- 初期状態は、申請前の「作成中」とする。
- 有効な遷移は「作成中に申請すると審査中へ」「作成中に取り消すと終了へ」「審査中に承認すると終了へ」の3つ。終了状態からの遷移はない。
- ガード条件はなく、アクションは状態値の保存のみとする。
- 上記以外の操作はすべて無効とし、状態を維持したまま「現在の状態では実行できません」というエラーメッセージを表示する。
この仕様を状態遷移表にまとめると、次のようになります。
| 現在の状態 | 申請 | 取消 | 承認 |
| 作成中 | 審査中 | 終了 | 拒否 |
| 審査中 | 拒否 | 拒否 | 終了 |
| 終了 | 拒否 | 拒否 | 拒否 |
この表から、「有効な遷移が3件」「無効な遷移が6件」あることがわかります。これらをもとに、「事前準備」「操作」「期待される結果」を具体化していきます。
3-1. 有効な遷移のテストケースを作る
有効な遷移をテストケースにする際は、表の各セルから次の3つの要素を抜き出します。
- 事前状態：テストを開始するとき、システムがどの状態にあるべきか
- 操作・条件：ユーザーがどのような操作を行うか
- 期待する状態・動作：操作後、どの状態になり、どんなアクション（保存や通知など）が実行されるか
今回の例における有効な遷移は、以下の3つのテストケースになります。
| ケース番号 | 事前状態 | 操作・条件 | 期待する状態・動作 |
| 1 | 作成中 | 申請 | 審査中になり、その状態値が保存される |
| 2 | 作成中 | 取消 | 終了になり、その状態値が保存される |
| 3 | 審査中 | 承認 | 終了になり、その状態値が保存される |
実際のテスト現場では、「事前状態をどう用意するか」も考慮が必要です。たとえばケース3（審査中で承認）を実施するには、あらかじめ「作成中」のデータを作成し、「申請」を行って「審査中」の状態を作っておく必要があります。
そのため、必ずしも1ケースごとにテストを区切る必要はありません。「作成中から申請し、続けて承認する」といったように、一連の流れの中で連続して検証するテストケースを組むのも効率的です。
3-2. 無効な遷移のテストケースを作る
状態遷移表を使う大きな価値は、仕様上許可されていない「無効な操作」のパターンを漏れなく洗い出せる点にあります。今回の例では、表内で「拒否」と書かれた6つの組み合わせが無効な遷移です。
今回の仕様では、無効な遷移について次の3点を確認します。
- 操作が正しく拒否されること
- システムの状態が勝手に変わらず、元の状態が維持されること
- 仕様どおりのエラーメッセージが表示されること
今回の例における無効な遷移のテストパターンは、以下の6つです。
- 作成中 × 承認：操作が拒否され、「作成中」が維持され、「現在の状態では実行できません」と表示される
- 審査中 × 申請：操作が拒否され、「審査中」が維持され、「現在の状態では実行できません」と表示される
- 審査中 × 取消：操作が拒否され、「審査中」が維持され、「現在の状態では実行できません」と表示される
- 終了 × 申請：操作が拒否され、「終了」が維持され、「現在の状態では実行できません」と表示される
- 終了 × 取消：操作が拒否され、「終了」が維持され、「現在の状態では実行できません」と表示される
- 終了 × 承認：操作が拒否され、「終了」が維持され、「現在の状態では実行できません」と表示される
無効な遷移をテストする際の大原則は、「1つのテストケースで試す不正な操作は1つだけにする」ことです。複数の不正操作を続けて行うと、最初のエラーによって後続の処理が止まり、別の不具合を見逃してしまうリスク（欠陥のマスキング）があるためです。
また、仕様書に無効操作時の挙動が明記されていない場合、テスター側で勝手に期待値を判断したり、現行の実装をそのまま正解としたりしてはいけません。必ず設計者に確認し、正しい仕様を決めてからテストケースを作成してください。
状態遷移テストのカバレッジ基準
テストをどこまで実施すれば十分といえるのかを判断し、その達成度をチームや顧客に説明するには、客観的な「カバレッジ基準（網羅対象を定める基準）」が必要です。
ただし、カバレッジは「何を分母（測定対象）にするか」によって意味が大きく変わります。状態遷移テストで用いられる代表的な基準と計算例を確認しておきましょう。
4-1. カバレッジ基準の種類
状態遷移テストの代表的なカバレッジ基準には、「全状態カバレッジ」「0スイッチカバレッジ」「1スイッチカバレッジ」「全遷移カバレッジ」の4つがあります。
| カバレッジ基準 | 網羅対象（カバレッジアイテム） | 概要・特徴 |
| 全状態カバレッジ | システムの取り得るすべての状態 | モデル内のすべての状態に少なくとも1回到達したかを測る基準です。すべての状態を通っても、そこに至るすべてのルート（遷移）を確認したとは限らないため、基準としては弱めです。 |
| 0スイッチカバレッジ（有効遷移カバレッジ） | 単一の有効な遷移 | 個々の有効な遷移を網羅したかを測る基準です。「確認した有効な遷移の数 ÷ 有効な遷移の総数 × 100」で網羅率を算出します。実務でもよく使われます。 |
| 1スイッチカバレッジ（Nスイッチ） | 連続する2つの有効な遷移（NスイッチはN+1個の連続遷移） | 「AからBへ遷移し、さらにBからCへ遷移する」といった、連続する2つの遷移を網羅したかを測る基準です。操作の順序や履歴が影響する不具合の検出に役立ちます。 |
| 全遷移カバレッジ | すべての有効な遷移および無効な遷移の実行試行 | すべての有効な遷移を通るだけでなく、モデル上で無効とされる遷移（不正な操作）もすべて試したかを測る基準です。0スイッチでは保証されない無効操作の検証を担保できます。 |
4-2. カバレッジの計算例
先ほどの申請処理の例を使って、0スイッチカバレッジと1スイッチカバレッジを実際に計算してみましょう。
今回の仕様における対象数は以下のとおりです。
- 0スイッチの対象（単一の有効な遷移）：「申請」「取消」「承認」の合計3つ
- 1スイッチの対象（連続する2つの有効な遷移）：「作成中 →（申請）→ 審査中 →（承認）→ 終了」の1パターンのみ（※「取消」は1回の操作で終了するため、後続の有効な遷移がなく対象外）
ここで、「作成中から申請を行い、続けて承認して終了させる」という一連のテスト（申請→承認）を1回実行したとします。このときのカバレッジは次のようになります。
- 0スイッチカバレッジ：有効な3つの遷移のうち「申請」と「承認」の2つを通ったため、2 ÷ 3 × 100 ≒ 66.7%
- 1スイッチカバレッジ：存在する唯一の連続遷移（申請→承認）を通ったため、1 ÷ 1 × 100 = 100%
注意したいのは、「1スイッチカバレッジが100%だからといって、すべての機能を確認できたわけではない」という点です。上記のテストだけでは、作成中から直接終了に至る「取消」の遷移を一度も確認できていません。
別途「作成中で取消を実行する」ケースを実施して初めて、0スイッチカバレッジも 3 ÷ 3 × 100 = 100% に達します。この場合、実行したテストケース数は2本ですが、網羅した遷移数は3つです。このように、テストケース数と網羅した遷移数は必ずしも一致しません。
また、同じテストを何度繰り返しても網羅した遷移数は増えないため、カバレッジの数値が上がることもありません。
4-3. カバレッジを扱う際の注意点
実務でカバレッジの数値を扱う際は、「100%」という数字の前提を正しく認識しておく必要があります。
カバレッジの網羅率は、あくまで「作成したモデルや採用した基準の範囲内での達成度」を示しているにすぎません。たとえば0スイッチカバレッジが100%であっても、それは「有効な遷移をすべて確認した」だけであり、無効な操作への対策は1つも確認できていない可能性があります。
また、そもそもの仕様分析が不足していて状態やイベント自体が表から漏れていれば、モデル上で100%を達成しても不具合は見抜けません。
さらに、連続遷移をどこまで深く追うかも慎重に判断する必要があります。連続する遷移を長く追う（2スイッチ、3スイッチ…）ほど、組み合わせの数は爆発的に増加するためです。
JSTQBのAdvanced Levelシラバスでも、2スイッチ以上（3つ以上の連続遷移）で100%を目指すのは、予期しない操作順序によって重大な事故につながる極めてリスクの高いシステムに限るべきだとされています。（出典：JSTQB「ISTQB® テスト技術者資格制度 Advanced Level シラバス日本語版 テストアナリスト（CTAL-TA）Version 4.0.J01（3.2.2 状態遷移テスト）」）
システムの重要度や許容コスト、納期をふまえ、「基本は0スイッチ＋主要な無効遷移」「リスクの高い重要ルートのみ1スイッチ」など、費用対効果の高いテスト範囲を設定することが大切です。
まとめ｜状態遷移表で組み合わせを整理し、適切な基準で網羅する
状態によって結果が変わる機能を確実にテストするには、状態遷移表を活用して「有効な遷移」と「無効な操作」を整理し、適切なカバレッジ基準でテスト範囲をコントロールすることが欠かせません。
テストケースを設計する際は、「事前状態」「操作」「期待する結果」の3点を具体化しましょう。特に無効な操作に対しては、「状態が勝手に変わらないこと」「仕様で定めたエラー応答が返ること」などを確認します。
また、カバレッジを測定する際は指標ごとの意味を正しく理解し、数値の高さだけに惑わされないように注意してください。
まずは担当するプロジェクトから、申請フローやステータス管理機能などを1つ選び、状態遷移表を書いてみましょう。それだけでも、これまで見落としていた仕様の抜け漏れや、考慮すべき操作パターンに気づけるはずです。
テスト条件の抜け漏れや網羅範囲の判断に課題がある場合は、バルテスのテスト計画・テスト設計支援もご検討ください。プロジェクトの目的やリスクに応じたテスト範囲の整理と、テスト技法を用いた設計を支援します。
