ソフトウェアテストの設計をする際に「状態遷移図」や「状態遷移表」を作成しているでしょうか?
ソフトウェアテストでバグを見逃すことなく検出するためには、バグを検出できる十分なテストを実施する必要があります。
しかし、開発仕様書は主に開発の為のドキュメントとして作成されているため、十分なテストケースを作成することを考えたときに記載が不足していることが多いです。そのため、開発仕様書からそのままテストケースを作成してしまうと、本来実施すべきテストケースに抜け漏れが発生し、バグを見逃すことに繋がってしまうことがあります。そこで、開発仕様書に書かれている内容を整理したり、テストケースを作成するのに必要な内容を補ったりすることが必要になります。
今回は、「状態遷移テスト」の有効なツールである「状態遷移図」、「状態遷移表」の内容と使い分け、書き方について解説していきます。

- もくじ
1.状態遷移テストとは
状態遷移テストとは、設計仕様どおりにイベントによってソフトウェアの状態が変化することを確かめるテストのことをいいます。
そもそも「状態遷移」とは、ある「状態」から異なる状態に変化することを指します。また、ある状態が異なる状態に変化するきっかけを「イベント」と呼びます。
テレビの場合を例にとると、テレビの電源の状態が「OFF」の時に、「リモコンの電源ボタンを押す」というイベントを起こしたら、テレビの電源の状態が「ON」に変わることを確認する、あるいは表示されている番組が「1チャンネル」の状態で、「リモコンの2のボタンを押す」と「2チャンネル」が表示されることを確認するのが状態遷移テストです。
2.仕様を見える化する「状態遷移図」と「状態遷移表」とは
冒頭に記載した通り、多くの開発仕様書では、テストをするのに十分な記載がされておらず、明確にソフトウェアの状態が記載されていなかったり、必要な情報がまとまっていなかったりしているため、ソフトウェアの状態遷移を正確に把握できないことがあります。
そこで、ソフトウェアの状態やイベントを開発仕様書から抽出し「状態遷移図」や「状態遷移表」として図や表にまとめます。これらの資料を作成し、仕様を整理し見える化することで、より深く製品の仕様を把握することができ、テストの漏れ抜けを防止することができます。
また、仕様の漏れ抜けも開発の早い段階で検出でき、バグの作り込みを防止することにも繋がります。
この章では「状態遷移図」と「状態遷移表」について詳しく解説します。
2-1 「状態遷移図」で状態遷移の全体的な流れを把握
状態遷移図は、システムの状態とその変化を図形や矢印で表したものです。
状態を四角で表し、その遷移を矢印で図示します。また、状態名を四角の中に、状態を遷移させるきっかけとなるイベントを矢印のそばに記載します。
例えば、テレビの電源がOFFの状態でリモコンの電源ボタンを押すと電源がONになり、もう一度ボタンを押すと電源がOFFになる場合、「OFF」と「ON」をそれぞれ四角で囲んで相互に矢印を引き、矢印のそばに「電源ボタン」と記します。
状態遷移図を作成することにより、仕様書に文章で個々の遷移について記載されているのを読むよりも、状態遷移全体の流れを視覚的に捉えることが可能です。開発者とテスト担当者で完成イメージを共有するためにも、状態遷移図は役立ちます。開発仕様書に記載されているような一つ一つの状態の動作や遷移は個々のテストを行いやすいのですが、全体の流れが適切でなかったり、必要な遷移が漏れていたりしていることがあります。状態遷移図は、そのような設計の不備を見逃すことなく発見できます。
2-2 「状態遷移表」でテストケースの抜けや漏れの防止
状態遷移表は、「遷移前の状態」と「遷移後の状態」、「イベント」を表形式でまとめたものです。
状態遷移表では、状態遷移図とは違い、遷移が発生しない「状態」と「イベント」の組み合わせも把握できます(上図では"-"になっている個所)。
遷移が発生しないのであればわざわざ確認する必要はないのでは?と思うかもしれません。
しかし、設計で想定していない状態とイベントの組み合わせは、何が起こるか開発者も分からないことが多いのです。そのため、あらかじめ設計時に想定されたイベントよりもバグが潜みやすい部分となっています。
そのようなバグを検出できるテストを実施するために、状態遷移表は効果を発揮します。
3.状態遷移図と状態遷移表は相補関係にある
状態遷移図と状態遷移表にはそれぞれ異なる特徴があります。状態遷移図はシステム全体を俯瞰有効ですが、状態ごとのイベントの処理方法は分かりにくいです。
これに対して状態遷移表は、システム全体を俯瞰するには向いていませんが、状態ごとのイベントの処理方法を細かく漏らさず表せます。
このように、状態遷移図は全体を俯瞰するのに役立ち、状態遷移表は各状態の動きを細かく漏らさず確認するのに役立ちます。
状態遷移図と状態遷移表の両方を作成することで、お互いに不足している部分を補うことができ、状態遷移テストの効果向上が期待されます。また、開発の段階で状態遷移図と状態遷移表を作成すれば、テストの質が向上するのみならず、ソフトウェアの不十分な点、誤りに早期に気付いて、バグの作り込みを防止することもできるのです。
4.状態遷移図の書き方
状態遷移図は、まずシステムがどんな状態にあるのか、「状態名」をつけて書き出すことから始めます。
テレビの電源なら、「OFF」と「ON」という具合です。それが、遷移する方向へ矢印を引きます。そして、遷移したきっかけ、いわゆる「イベント」を矢印の隣に書き込みます。「OFF」から「ON」への矢印には、「電源ボタンを押下」となります。なお、1つの遷移に対して、矢印は1本です。「ON」から「OFF」への遷移も、「電源ボタンを押下」という同じイベントになりますが、それは別の矢印で書き込むことになります。
5.状態遷移表の書き方
状態遷移表は、縦軸が「状態」、横軸が「イベント」です。すべての「状態」、すべての「イベント」を網羅的に書き出すことが大切です。先ほどのテレビの例では、「電源ボタンを押下」というイベントに対し、それによって起こる遷移である「ON」「OFF」の状態を下図のように書くことになります。
まとめ
今回は状態遷移テストの説明と、このテストで利用される状態遷移図と状態遷移表の内容と違いについてご紹介しました。
改めてまとめると、状態遷移図は、図式によってソフトウェアの仕様を「見える化」することで、ひと目で全体像を把握することができます。
また、仕様の全体を感覚的に掴める状態遷移図に対し、感覚では掴みきれない細部を漏れなく拾ってくれるのが状態遷移表です。仕様で盛り込んでいないことや起こると想定されていないことまでチェックすることができます。
状態遷移図と状態遷移表を組み合わせることで、正しく動作しているか、間違った動作がないかをフルカバーでき、状態遷移の全体の流れの把握、開発仕様書の抜け漏れの防止を行うことができます。
それぞれの特徴を理解して、ソフトウェアのテスト設計に取り入れてみてはいかがでしょうか。