コラム

  • 2021.09.08
  • ソフトウェアテスト
  • #テスト実行
  • #テスト技法
  • #テスト計画
  • #テスト設計
  • #基礎知識
  • #開発手法

状態遷移図と状態遷移表。2つの違いとテスト工程における使い方をご紹介

現代のソフトウェア製品は、さまざまな条件の組み合わせで挙動するため、仕様が複雑化する傾向にあります。テストをする際にも、条件や仕様を網羅できているかどうか、不安になることもあるでしょう。その不安を解消するために、今回は、「状態遷移テスト」の有効なツールである「状態遷移図」、「状態遷移表」の内容と使い分けについてご紹介いたします。

状態遷移図とは

「状態遷移」とは、ソフトウェアやシステムの状態がさまざまな条件やイベントによって変化することを指しますが、それらの変化を図形や矢印で表現したものが「状態遷移図」です。システムやソフトウェアの仕様が文章で書かれている場合に、ビジュアルでより俯瞰的に仕様をとらえることができます。

図A:状態遷移図

状態遷移図のイメージ図

状態遷移表

状態遷移図に似ている言葉に「状態遷移表」があります。「状態遷移表」とは「状態」と「イベント」をマトリクスで表現したものです。状態遷移図と比較すると、状態とイベントの組み合わせを網羅的に検討できるため、仕様として無効な組み合わせも検討することができます。

図B:状態遷移表①

状態遷移表のイメージ図

状態遷移図と状態遷移表をつくる目的とは?

状態遷移図と状態遷移表は、どちらも仕様の全体像を把握することや条件を整理することに適していますが、みえてくるものが異なります。
状態遷移図を活用すると、ソフトウェアやシステムの全体像を俯瞰的にとらえることができ、各状態とイベントが線で結ばれているため、流れを把握することができます。

例)状態A⇒(イベントa)⇒状態B⇒(イベントe)⇒状態C

一方で、状態遷移表は各状態とイベントに対する遷移後の状態をマトリクスで表現することになるため、条件や組み合わせの網羅性を検討することができます。図Cの黄色ハイライト部分は、「組み合わせとして無効」となることが多いですが、状態遷移図では表現されていない条件・組み合わせについて検討するきっかけにもなります。

図C:状態遷移表②

状態遷移表:条件や組み合わせの網羅性の検討イメージ図

仕様検討や設計工程の段階では、目玉機能のイベントや、条件が複雑なイベントに対しては「できること」「できないこと」がしっかり記載されているケースが多いのですが、よくある処理や、こまかな例外処理などは検討がおざなりになることが多いです。認識齟齬を発生させないためにも、仕様検討や詳細設計工程で、状態遷移図や状態遷移表を適切に取り入れて、条件や組み合わせの仕様を明確にするのが効果的ともいえます。

ソフトウェアテスト入門動画

状態遷移テストとは?

状態遷移テストは、これまで述べてきたとおり、仕様ベースで挙動を確認するテスト技法の1つです。

この技法は、状態遷移図や状態遷移表を基に

●有効な状態遷移が正しく行われること
●無効な状態遷移が行われないこと

をテストすることになります。

状態遷移図を使った状態遷移テスト

状態遷移図によるテストでは、図に描かれた遷移の経路をそのとおりに動くかどうか(有効な状態遷移が正しく行われるか)、状態を網羅し、確認していきます。その経路を検討する過程で、シナリオのパターンを検討することができるので、テストケースを作成する際には、ソフトウェアやシステムの全体像と流れを把握するために状態遷移図を作成するのがよいでしょう。

状態遷移表を使った状態遷移テスト

状態遷移表によるテストは、状態遷移表で表現されたセルを「-」も含めて、「遷移できない(しない)こと」(無効な状態遷移が行われないこと)も含めてテストしていきます。繰り返しになりますが、「状態」と「イベント」を網羅して検討することにより、設計段階では意図しないような挙動も確認することができ、仕様の検討漏れやテストケースの抜け漏れを防ぐことができます。

ソフトウェアテスト入門動画

テスト工程における状態遷移図と状態遷移表の効果的な使い方

状態遷移図を書く際のポイント

仕様書がある場合には、仕様書から状態やイベントを列挙していけばよいので、あまり困らないとは思います。
ただし、実際の現場では十分なインプットを得られない場合や 、リリースや開発を優先するあまり、仕様をドキュメント化していない(あるいは更新が漏れている)場面に遭遇することが多いため、今回はテスト工程において、少ないインプットで状態遷移図を書き起こす場合のポイントを紹介します。

イベントを洗い出す

テスト設計段階でのインプットが、「動くもの」や「現物」(開発途中のものも含む)である場合、状態を変化させるイベントを洗い出します。GUI画面であればリンクやボタンの押下や、フォームへの入力など、状態を遷移させるイベントをすべてチェックし、遷移先の状態に矢印で結び、矢印のそばにイベントを記載するようにします。図Dのように、「状態A」でイベントa,bを洗い出します。同様に、状態B、状態Cでもイベントを洗い出します。

図D:状態遷移図の書き方

状態遷移図の書き方のイメージ図

それぞれの状態の遷移パターンに過不足を検討する

状態遷移図がある程度完成したら、遷移パターンに過不足がないかを確認します。図Eでは、状態Cから状態Bへの遷移パターン(イベントfの存在)がないか確認します。

図E

状態遷移図:遷移パターンに過不足確認のイメージ図

ここで遷移図から現物を書き起こす際に、注意しなければならないポイントがあります。それは、現物からイベントや状態を洗い出しているため、そもそもイベントが正しいのか、遷移が正しいのか、遷移後の状態が正しいのか、テスト担当としては判断できないということです。そのため、状態遷移図が完成したら、必ず仕様の責任者へ確認し、状態やイベントが正しいか(仕様どおりか)確認するよう心がけましょう。

状態遷移表を書く際のポイント

状態遷移表は、状態、イベントを網羅的に洗い出すことが大切です。各状態やイベントを網羅的に検討し、遷移できない、仕様として起こりえないことについては「-」や「N/A(Not Applicable)」を入力していきます。
状態遷移表についても、そもそもイベントが網羅できているかの確認が必要です。図Fで状態Cの行に注目すると、状態Aへの遷移はあっても状態Bへの遷移イベントがないことがわかるため、ここでもイベントfの可能性を検討することができます。

図F:状態遷移表

状態遷移表:イベントが網羅できているかの確認のイメージ図

複雑なソフトウェアやシステムの場合は状態の数も多いので、テスト工程から仕様や全体像を把握するためにも、まずは状態遷移図を作成し、イベントや条件の組み合わせの検討に状態遷移表を作成するなど、相互に補完しながら使い分けするのがよいでしょう。

ソフトウェアテスト入門動画

まとめ

以上、状態遷移図と状態遷移表の違いと、特徴について確認してきました。それぞれで「できること」「できないこと」が異なるため、目的によって使い分け、場合によっては相互補完的に利用していくのが効果的です。今回はテスト工程での利用という点に着目しましたが、仕様を検討する際にも有効なツールであるため、ソフトウェアテスト設計段階だけではなく、上流工程での設計にも取り入れてみるのも一つの手といえるでしょう。

資料ダウンロード/動画視聴

ソフトウェアテスト入門動画

テスト計画入門動画

SHIFTサービス資料

テストサービス導入事例集

関連サービス