間が空いてしまいましたが、その2です。「その1」と書いて放置しているエントリー、多そうだな・・・。
「テストシナリオ」という言葉はオレオレ定義していますので、その1のエントリーから読んでいただけると幸い。たこはちさんからコメントいただきました通り、JSTQB（元はIEEE 829）の定義とはズレています。
シナリオテストの単位
検証すべきアウトプット
シナリオテストではシナリオが単位になるのだから、検証すべきはシナリオが終わった時点でのアウトプットのみ、という考えもあるでしょう。が、ぼくは、シナリオを構成するそれぞれのテストケースのアウトプットを確認すべきと思います。途中にしか現れないアウトプットもありますし。
シナリオを、テストケースの順序付き集合と捉えているのはその意味もありまして、統合テストのテストケースで規定したケースを、ある程度そのまま使えるのは嬉しい。
テストシナリオが失敗した場合
20個のテストケースから構成されるテストシナリオが、19個目のテストケースでコケたとしましょう。プログラムの欠陥とわかれば、改修して再テストとなります。
この欠陥が、成功した18個のテストケースとは何の関係もない（ように思われる）ものだった場合、成功した18個目までのテストもやりなおすのでしょうか。
プロジェクトの状況にもよるでしょうが、原則としてシナリオの最初からやり直すべきだと思います。シナリオは、前までの事後条件を事前条件としているので、単独でのやり直しはシナリオテストをやったことにならないかと。
そもそも、「他のテストケースと何の関係もない」欠陥がシナリオテストで出たのであれば、それは統合テスト以前のテストの見直しが必要でしょう。
シナリオテストの意義
ところで、そもそもどうしてシナリオテストが必要なんでしょう。ここでも、完全に自分コンテキストで語りますね。
オレオレ定義での「シナリオ」は、機能ごとのユースケースを結合するイメージです。で、この「機能」というのは、それぞれ別の人が設計し、別の人が実装したかも知れない。プロジェクトにおいて、すべての機能を広く浅く知っている人よりも、一部の機能を狭く深く知っている人が多数になっていると、機能の間の矛盾って気づきづらくなりますよね。
そのインタフェースを確認しつつ、一連の業務が滞りなく流れるかをチェックするのが、シナリオテストの目的だと思います。機能をちゃんと知っている人でも、「最初から最後まで」がどうなっているかピンと来ないってこともあるでしょう。
「最初から最後まで」ってのは、システムで取り扱う「対象」のライフサイクルを考えることです。
図書館の例でいえば、まず「蔵書」ですよね。入荷され、登録され、貸し出し可能な状態になってから、予約され、貸し出され、延滞され、返却され、また予約され、いつか廃棄される。これをシナリオにしたい。
「利用者」にもライフサイクルがあるでしょう。「図書館員」にもあるかも知れません。そういうライフサイクルをもつデータって何かな、と考えることが、シナリオ作りの1つの観点になると思います。
免責
自分勝手に考えたことを書いているので、「完全にあさってのことを語っている」のか、「あまりに当たり前のことを述べている」のか、自分の立ち位置がよくわかりません。これは次回のSTE研究会でボコられることに期待。 「その1」を書いたときに、鈴木三紀夫さんからいただいたご指摘も気になっております。
. @kz_suzuki の記事を読むと、テストの目的はシステムの欠陥を除去するためのようであり、視点または立ち位置としてシステム側になっている。まぁ、「業務」という言葉は使われてなく、一貫して「シナリオテスト」と呼んでいるので、そういうニュアンスを持たせているのかもしれない。
— 鈴木三紀夫 (@mkoszk) 2012年10月15日
なお、勉強不足のユースケースについても、三紀夫さんのブログで勉強中でーす・・・。ありがとうございます！
