ソフトウェアの品質を学びまくる2.0

旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

「シナリオテスト」とは一体何なのか - その2


スポンサードリンク

 間が空いてしまいましたが、その2です。「その1」と書いて放置しているエントリー、多そうだな・・・。
 「テストシナリオ」という言葉はオレオレ定義していますので、その1のエントリーから読んでいただけると幸い。たこはちさんからコメントいただきました通り、JSTQB(元はIEEE 829)の定義とはズレています。

kzsuzuki.hatenablog.com

シナリオテストの単位

検証すべきアウトプット

 シナリオテストではシナリオが単位になるのだから、検証すべきはシナリオが終わった時点でのアウトプットのみ、という考えもあるでしょう。が、ぼくは、シナリオを構成するそれぞれのテストケースのアウトプットを確認すべきと思います。途中にしか現れないアウトプットもありますし。
 シナリオを、テストケースの順序付き集合と捉えているのはその意味もありまして、統合テストのテストケースで規定したケースを、ある程度そのまま使えるのは嬉しい。

テストシナリオが失敗した場合

 20個のテストケースから構成されるテストシナリオが、19個目のテストケースでコケたとしましょう。プログラムの欠陥とわかれば、改修して再テストとなります。
 この欠陥が、成功した18個のテストケースとは何の関係もない(ように思われる)ものだった場合、成功した18個目までのテストもやりなおすのでしょうか。

 プロジェクトの状況にもよるでしょうが、原則としてシナリオの最初からやり直すべきだと思います。シナリオは、前までの事後条件を事前条件としているので、単独でのやり直しはシナリオテストをやったことにならないかと。
 そもそも、「他のテストケースと何の関係もない」欠陥がシナリオテストで出たのであれば、それは統合テスト以前のテストの見直しが必要でしょう。

シナリオテストの意義

 ところで、そもそもどうしてシナリオテストが必要なんでしょう。ここでも、完全に自分コンテキストで語りますね。

 オレオレ定義での「シナリオ」は、機能ごとのユースケースを結合するイメージです。で、この「機能」というのは、それぞれ別の人が設計し、別の人が実装したかも知れない。プロジェクトにおいて、すべての機能を広く浅く知っている人よりも、一部の機能を狭く深く知っている人が多数になっていると、機能の間の矛盾って気づきづらくなりますよね。
 そのインタフェースを確認しつつ、一連の業務が滞りなく流れるかをチェックするのが、シナリオテストの目的だと思います。機能をちゃんと知っている人でも、「最初から最後まで」がどうなっているかピンと来ないってこともあるでしょう。

 「最初から最後まで」ってのは、システムで取り扱う「対象」のライフサイクルを考えることです。
 図書館の例でいえば、まず「蔵書」ですよね。入荷され、登録され、貸し出し可能な状態になってから、予約され、貸し出され、延滞され、返却され、また予約され、いつか廃棄される。これをシナリオにしたい。
 「利用者」にもライフサイクルがあるでしょう。図書館員」にもあるかも知れません。そういうライフサイクルをもつデータって何かな、と考えることが、シナリオ作りの1つの観点になると思います。

免責

 自分勝手に考えたことを書いているので、「完全にあさってのことを語っている」のか、「あまりに当たり前のことを述べている」のか、自分の立ち位置がよくわかりません。これは次回のSTE研究会でボコられることに期待。  「その1」を書いたときに、鈴木三紀夫さんからいただいたご指摘も気になっております。

 なお、勉強不足のユースケースについても、三紀夫さんのブログで勉強中でーす・・・。ありがとうございます!