コラム
TOP >  コラム >  コラム詳細

上流工程で効く、 「テストの考え方」  第4回 : 「状態遷移図」と「状態遷移表」で見えるもの
はじめに


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

テスト担当者:「この状態の時にこの動作を行うと、結果としてどういう状態に遷移すれば仕様として正しいんでしょうか。仕様書に記載がないので…」

開発担当者:「どれどれ、うーん、本当だ。記載がないね…。俺もわからないや。テストした結果を仕様書に記入しておいてよ。それが仕様だから」

テスト担当者:「…」

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


著者:石原 一宏
バルテス株式会社 R&D部 部長兼上席研究員。ソフトウェアテスト・品質の研究開発を行う傍ら、社内外のセミナー講師およびコンサルティングを行う。『ソフトウェアテストの教科書』(共著、ソフトバンク クリエイティブ社、2012年)、『いちばんやさしいソフトウェアテストの本』(共著、技術評論社、2009年)を執筆。
状態遷移テストとは


「状態遷移テスト」とは、状態遷移図と状態遷移表をもとに行うテストの総称です。

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


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


とはいえ、テストをしていると、もう少し設計段階で、意識的に状態遷移図や状態遷移表を作っておいたら、テスト以前にもっと多くの不具合を防げるのに、と思うことが少なくありません。

仕様記述抜け、実装抜けしていることがテストで発見されると、手戻りのコストは大きいからです。


「ソフトウェアを作る」のに必要な仕様と、「ソフトウェアをテストする」のに必要な仕様には、隔たりがあるように感じます。

今回話をしたいのは、テストで必要な仕様を設計段階で意識することで、効果的に手戻りを減らそう、というものです。


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


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

では、実際に作るとどのようなメリットがあるのか。「なんとなく良い」ではなく、「こういうメリットがあるから、ここで時間をかけて作るんだ」、というふうに、目的を明確にしているでしょうか。

そこがあいまいであれば、優先順位は下がらざるを得ません。

その時に参考にしていただきたいのが、テスト担当者が状態遷移図・表を作るときの意図や目的です。 状態遷移図と状態遷移表ではそもそも「見えるもの」が違います。作成に当たっては、「何が見たいのか」「何を明らかにしたいのか」という目的・意図を明確にしておくと有効です。


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


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

              
文章による仕様(ストップウォッチ)

*ストップウォッチには「スタート」「ストップ」「リセット」の3つのボタンがある

*「スタート」ボタンを押下すると計測を開始する

*「ストップ」ボタンを押下すると計測を一時停止し、計測結果時間を表示する

*結果表示中に「スタート」ボタンを押下すると計測を再開する *結果表示中に「リセット」ボタンを押下すると計測結果時間をリセットする
              


シンプルな仕様です。

ソフトウェアを「作る」には、これで差し支えないかもしれません。

ですが、テストするとすれば、この箇条書きを逐次テストするだけでは、十分とは言えません。

そこで使用・作成するのが状態遷移図です。

状態遷移図を使うと、そのソフトウェアが「できること」の全体像を視覚的、直感的に把握しやすくなります。


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

1| 2

>

>>



第3回 第5回


連載一覧

1