【JSTQB試験対策】ブラックボックステスト技法④「状態遷移テスト」について、分かりやすく解説
状態遷移テストとは
JSTQB Foundation Level試験を目指して学習中の皆さん、こんにちは。前回は「デシジョンテーブルテスト」について解説しましたが、今回はシステムの”状態の変化”に着目してテストを設計する「状態遷移テスト」について詳しく解説していきます。
システムの中には、同じ操作をしても現在の状態によって異なる結果になるものがたくさんあります。例えばログイン前と後では操作できる機能が違いますし、ショッピングサイトのカートも「空」「商品あり」「決済中」などの状態で振る舞いが変わります。このような”状態と遷移”を整理し、テストケースへ落とし込むための技法が状態遷移テストです。
状態遷移テストの定義
状態遷移テストとは、システムが取り得る「状態」と、状態を変化させる「イベント」、そしてイベントによって生じる「遷移」や「アクション」を整理し、各遷移が仕様どおりに動作することを確認するブラックボックステスト技法です。
状態遷移テストは、仕様を状態遷移図や状態遷移表といった図表で可視化してからテストケースを設計します。可視化することで、見落としていた遷移や、仕様に定義されていない”あってはならない遷移”にも気づきやすくなります。
状態遷移テストの基本要素
状態・イベント・遷移・アクション
状態遷移テストは、主に以下の4つの要素で構成されます。
- 状態（State）：システムが取り得るある時点の状況（例：ログイン前、ログイン済み）
- イベント（Event）：状態を変化させるきっかけとなる入力や操作（例：ログインボタン押下）
- 遷移（Transition）：イベントによって、ある状態から別の状態へ移ること
- アクション（Action）：遷移の際に実行される処理（例：ログイン成功メッセージ表示）
■重要なポイント
同じイベントであっても、現在の状態が異なれば結果となるアクションや遷移先が変わる点が、状態遷移テストの最大の特徴です。「どの状態で」「どのイベントが起きたら」「どうなるのか」を常にセットで考えましょう。
状態遷移の2つの表現方法
状態遷移テストでは、仕様を可視化するために「状態遷移図」と「状態遷移表」の2つの表現方法を使い分けます。それぞれの特徴を押さえておきましょう。
状態遷移図（State Transition Diagram）
状態を丸や四角で表し、遷移を矢印で結んだ図です。矢印にはイベント名（必要に応じてアクション名）を記載します。全体の流れを俯瞰しやすく、仕様の説明やレビューに向いています。
状態遷移表（State Transition Table）
縦軸に「現在の状態」、横軸に「イベント」を並べ、交差するセルに遷移先の状態（または”遷移なし”）を記載した表です。状態遷移図では見落としやすい「仕様に定義されていない遷移」や「あってはならない遷移」を網羅的に確認できる点が強みです。
■図と表の使い分け
状態遷移図は「全体像の理解」に、状態遷移表は「遷移の抜け漏れ・妥当性の確認」に向いています。実務では両方を併用して整理するのが一般的です。
状態遷移テストの実践手順
実際に状態遷移テストを設計する手順を見ていきましょう。
ステップ1：状態とイベントを洗い出す
テスト対象の仕様を読み込み、システムが取り得る「状態」と、状態を変化させる「イベント」をすべて洗い出します。業務フローや画面遷移図、仕様書を参考にしましょう。
ステップ2：状態遷移図を作成する
洗い出した状態とイベントをもとに、状態遷移図を描きます。全体の流れを視覚化することで、関係者間で認識を合わせやすくなります。
ステップ3：状態遷移表に展開する
状態遷移図を状態遷移表に落とし込みます。すべての”状態×イベント”の組み合わせを記載することで、仕様に明記されていない組み合わせや、”あってはならない遷移”を発見できます。
ステップ4：テストケースを導出する
どのカバレッジ基準を目標にするかを決め、必要な遷移を網羅するテストケースを設計します。各テストケースには「初期状態」「イベント」「期待される次の状態」「確認観点」を明記します。
具体例で理解する状態遷移テスト
例：動画配信サービスの会員ステータス
動画配信サービスの会員ステータスを題材に、状態遷移テストを考えてみましょう。
仕様：
- 会員ステータスは「未登録」「無料会員」「有料会員」「解約済み」の4つがある
- 未登録ユーザーは「新規登録」により無料会員になる
- 無料会員は「有料プラン申込」により有料会員になる
- 有料会員は「プランダウングレード」により無料会員に戻れる
- 無料会員・有料会員は「退会」により解約済みになる
この仕様をもとに、以下のようなテストケースを作成します。
TC-01〜TC-05は仕様で許可されている正常な遷移を確認するテストです。一方、TC-06のように”仕様で定義されていない遷移”をわざと実行し、エラー表示や遷移不可の挙動を確認することも、状態遷移テストでは非常に重要です。
状態遷移テストのカバレッジ基準
状態遷移テストでは、どこまでテストすれば十分かを判断するためのカバレッジ基準があります。JSTQB試験でも頻出のポイントなので、しっかり押さえておきましょう。
① 全状態カバレッジ（All States Coverage）
すべての状態を少なくとも1回は訪問することを目標とするカバレッジ基準です。最も基本的な基準ですが、遷移そのものの正しさは保証できません。
② 全遷移カバレッジ（All Transitions Coverage / 0スイッチカバレッジ）
状態遷移図に定義されているすべての遷移を少なくとも1回は実行する基準です。状態遷移テストにおいて最も基本かつ重要なカバレッジ基準とされており、通常はこの基準の達成が目指されます。
③ Nスイッチカバレッジ（N-switch Coverage）
連続するN+1回の遷移の組み合わせを網羅する基準です。例えば1スイッチカバレッジでは、2回連続した遷移のすべてのパターンを実行します。欠陥の多くは複数の遷移をまたいで発生するため、より堅牢なテストを行う場合に用いられます。
■基準の選び方
一般的なアプリケーションでは「全遷移カバレッジ100％」を目標とすることが多いです。金融・医療・組込みなど、信頼性が高く求められるシステムではNスイッチカバレッジまで検討しましょう。
状態遷移テストのメリット
状態遷移テストを活用することで、以下のようなメリットが得られます。
1. 状態による振る舞いの違いを体系的に確認できる
「同じ操作でも状態によって結果が変わる」という仕様を、漏れなく確認できます。画面遷移、認証状態、ワークフローなど、幅広いシステムに適用できます。
2. “あってはならない遷移”を発見できる
状態遷移表を使うことで、仕様に明記されていない組み合わせや、本来実行してはいけない遷移を可視化できます。これにより、不正な操作時のエラーハンドリングのテストも設計できます。
3. 仕様の曖昧さを発見しやすい
遷移を整理する過程で、「このイベントが起きた場合の挙動が定義されていない」といった仕様の抜けに気づけます。テスト設計段階で仕様の品質を高められる副次的な効果があります。
4. ドキュメントとしての再利用性が高い
状態遷移図・遷移表は、テストだけでなく仕様書・設計書・引継ぎ資料としても活用できます。開発者・テスト担当者・業務担当者の共通言語として機能します。
状態遷移テストの注意点
状態遷移テストを適用する際は、以下の点に注意が必要です。
⚠️ 状態の粒度を適切に設計する
状態を細かく分けすぎると図表が複雑化し、逆に大まかすぎると重要な違いを捉えられません。「振る舞いが明確に変わる単位」で状態を定義することが重要です。
⚠️ 隠れた状態・隠れたイベントに注意
仕様書に明記されていなくても、タイマーによる自動遷移や、裏側で動くバッチ処理による状態変化など、”見えない遷移”が存在する場合があります。開発者とコミュニケーションを取りながら洗い出しましょう。
⚠️ 状態数が多い場合の工数増加
状態やイベントの数が多いシステムでは、全遷移の組み合わせが爆発的に増加します。重要度に応じてテストする遷移を取捨選択したり、同値分割法・デシジョンテーブルと組み合わせたりすることで、効率化を図りましょう。
JSTQB試験での出題ポイント
JSTQB Foundation Level試験では、状態遷移図・遷移表を読み取り、カバレッジや遷移を正しく判断できることが重要です。以下のポイントを押さえておきましょう。
- 📌 基本要素の理解：状態・イベント・遷移・アクションの違いを正しく区別できるか
- 📌 図と表の読み方：状態遷移図・状態遷移表から正しい遷移を読み取れるか
- 📌 カバレッジ基準：全状態・全遷移・Nスイッチカバレッジの違いを理解しているか
- 📌 テストケース導出：指定された初期状態とイベントから、期待される次の状態を導けるか
- 📌 不正な遷移の検出：仕様に定義されていない遷移・あってはならない遷移をテストする意義を理解しているか
まとめ
状態遷移テストは、システムの状態と遷移に着目してテストを設計するブラックボックス技法です。以下のポイントを再確認しましょう。
- 状態遷移テストは、状態・イベント・遷移・アクションの4要素で整理する
- 状態遷移図は全体像の把握に、状態遷移表は漏れの発見に強い
- カバレッジ基準には全状態・全遷移・Nスイッチの3種類がある
- 通常は「全遷移カバレッジ100％」が実務上の目標となる
- “あってはならない遷移”のテストも、品質確保のために重要
状態遷移テストは、画面遷移・認証フロー・ワークフロー・組込みシステムなど、現場のあらゆる場面で活躍する技法です。状態遷移図と状態遷移表を使い分け、カバレッジ基準を意識してテストを設計することで、仕様に忠実かつ堅牢なテストが実現できます。実務でもJSTQB試験でも、”状態の変化”というレンズでシステムを捉える視点を身につけておきましょう。
次回は、経験と直感を活かしてテストを設計する「経験ベースのテスト技法」について詳しく解説していきます。
JSTQB(日本ソフトウェアテスト技術者資格)は、ソフトウェアテストの専門的な知識と技術を認定するための資格です。この資格は、ソフトウェアテストのプロフェッショナルとして必要なスキルを証明するものとして、業界で広く認知されています。
JSTQBは、国際的な基準であるISTQB（International Software Testing Qualifications Board）に基づいており、日本国内のソフトウェアテスト分野における実務能力を向上させるための指針となっています。
株式会社NSITでは、ソフトウェアテストに従事するエンジニアの約9割が、JSTQBの資格を取得しております。
