はじめに

テスト担当者と開発担当者との会話。

• テスト担当者：「この状態の時にこの動作を行うと、結果としてどういう状態に遷移すれば仕様として正しいんでしょうか。仕様書に記載がないので…」
• 開発担当者：「どれどれ、うーん、本当だ。記載がないね…。俺もわからないや。テストした結果を仕様書に記入しておいてよ。それが仕様だから」
• テスト担当者：「…」

この話が「あり得ない話」なのか「よくある話」なのかはさておき。今回の話題は、「⁠状態遷移テスト」です。

状態遷移テストとは

「状態遷移テスト」とは、状態遷移図と状態遷移表をもとに行うテストの総称です。私たちテスト担当者は、機能テストやシステムテストにおいて状態遷移図や状態遷移表を作成して、ソフトウェアが「正しく」設計仕様どおりに動くかどうかをテストします。

ですが、この「設計仕様書通りに動く」というところがなかなか難しいところです。冒頭の会話にもありましたが、テストしようとする対象の期待値が仕様書にすべて書いてあることを求めるのは非現実的だからです。

とはいえ、テストをしていると、もう少し設計段階で、意識的に状態遷移図や状態遷移表を作っておいたら、テスト以前にもっと多くの不具合を防げるのに、と思うことが少なくありません。仕様記述抜け、実装抜けしていることがテストで発見されると、手戻りのコストは大きいからです。

「ソフトウェアを作る」のに必要な仕様と、「⁠ソフトウェアをテストする」のに必要な仕様には、隔たりがあるように感じます。今回話をしたいのは、テストで必要な仕様を設計段階で意識することで、効果的に手戻りを減らそう、というものです。

なぜ「状態遷移図」「状態遷移表」を作るのか

開発設計担当の方に「状態遷移図や状態遷移表を設計段階で作りますか？」という質問をすると、「⁠いつも作る」という方はむしろ少数派のようです。「⁠時間があれば作る」「⁠作ったり作らなかったり」と返事はまちまちです。「⁠作ったほうがいいとは思うんだけど、時間がなくてね」というのが正直なところなようです。

では、実際に作るとどのようなメリットがあるのか。「⁠なんとなく良い」ではなく、「⁠こういうメリットがあるから、ここで時間をかけて作るんだ⁠」⁠、というふうに、目的を明確にしているでしょうか。そこがあいまいであれば、優先順位は下がらざるを得ません。その時に参考にしていただきたいのが、テスト担当者が状態遷移図・表を作るときの意図や目的です。

状態遷移図と状態遷移表ではそもそも「見えるもの」が違います。作成に当たっては、「⁠何が見たいのか」「⁠何を明らかにしたいのか」という目的・意図を明確にしておくと有効です。

状態遷移図を使うことで見えるもの

では、実際に状態遷移図、状態遷移表を使うと何が、どのように見えてくるのでしょうか。一緒に考えてみましょう。

シンプルな仕様です。ソフトウェアを「作る」には、これで差し支えないかもしれません。ですが、テストするとすれば、この箇条書きを逐次テストするだけでは、十分とは言えません。そこで使用・作成するのが状態遷移図です。状態遷移図を使うと、そのソフトウェアが「できること」の全体像を視覚的、直感的に把握しやすくなります。

先ほどの文字による仕様から状態遷移図を作るとこうなります。

図1では「状態」を丸、「⁠遷移」を矢印で表しています。矢印のそばに書いてある文字は、遷移のきっかけとなる「イベント（入力⁠）⁠／アクション（出力⁠）⁠」です（作画方法の細かいルールは本稿では省略いたします⁠）⁠。

状態遷移図によるテストは、まず状態遷移図を作成し、図に描かれた矢印、すなわち遷移の経路をその通りに動くかどうか1つ1つ確認していきます。また、そのソフトウェアがとりうる、いろいろな経路の通り方のパターンをこの状態遷移図から作り出して、テストを行うこともあります。状態遷移図があれば、そのパターンを導くことも容易です。

いかがでしょうか。先ほどの文字の仕様を図で表現することで、ソフトウェアの挙動の全体像が、随分わかりやすくなりました。こうすることで文章だけの仕様では気付かなかった仕様の不十分な点にも気付きやすくなります。

状態遷移表を使うことで見えるもの

次に「状態遷移表」を見てみましょう。状態遷移図があるのだから、必要ないんじゃないの？と考える方もいるかもしれません。ですが状態遷移図と状態遷移表では「見えてくるもの」が違います。

実際に状態遷移表を見てみましょう。先ほどの文章による仕様と、状態遷移図をもとに状態遷移表を作ってみました。

視覚的、直感的には図1の状態遷移図のほうがわかりやすかったですが、表1のように状態遷移表にすると、9つあるセルのうち、先ほどの図1の例では4つのセルしか表現できておらず、残り5つのセルは状態遷移図では表現されていないことに気が付きます。概してこの部分は「遷移しない」「⁠組み合わせとしてあり得ない」が多くを占めます（表1の「－」は「遷移しない」を示します⁠）⁠。

この「表現されていない部分」が見えやすくなるのが状態遷移表の大きな特徴です。この部分は文字の仕様や、状態遷移図だけでは見えにくい部分です。

状態遷移図を用いることで「遷移できること」を明らかにできるのに対し、状態遷移表は、いわばそのソフトウェアが「できないこと」「⁠してはいけないこと」を可視化できることが、利用に際しての大きなメリットです。

仕様書には「遷移できること」は記述してありますが、「⁠遷移できないこと」はあいまいであったり、そもそも記載されていないことが少なくありません。状態遷移表を作成すると、その作成の過程で、仕様には記載されていない事項や、あいまいな事項に気付きやすくなります。

とりわけ「遷移しないこと」は、設計段階で可能な限り明確に定義しておくことをお勧めします。テストの段階で、本来遷移してはいけないものが遷移してしまうとわかった場合には、手戻りを余儀なくされるからです。設計の段階で、状態遷移表を作成していれば、このような、修正コストは少なくて済みます。

また状態遷移表を作成したら、もう一度、仕様や状態遷移図を見直すことで、不十分な点や、誤りに気付くこともあります。状態遷移図と状態遷移表は、相補い合う関係にあるといえます。

さいごに

状態遷移図や表の書き方は、いろんな本やネット情報で手に入りますし、知らない人のほうが少数ですが、「⁠なぜ書くのか」「⁠書けばどういうメリットがあるのか」に関して自覚的な方は、意外と少数派です。

繰り返しになりますが、「⁠図」と「表」では、それぞれ見えてくるものが違います。

• 状態遷移図：「そのソフトウェアができること」が見えやすくなる
• 状態遷移表：「そのソフトウェアができないこと／してはいけないこと」が見えやすくなる

もちろんこれが全てではありませんが、ひとつの「見方」「⁠切り口」として、ご参考にしていただければと思います。

上流工程の設計、仕様書作成の際のヒントにしていただき、少しでも手戻りが減る手助けになれば幸いです。