その1、その2の続きです。
kzsuzuki.hatenablog.com kzsuzuki.hatenablog.com
今回の話はだいぶ机上の空論感が漂いますので、聞き流してくださいね。なお、「テストシナリオ」という言葉については、その1からオレオレ定義しており、ユースケースの結合的な意味で捉えております。
さてそれでは、シナリオとはどう作るものなのでしょう。ユースケースをどう組み合わせればいい？
ここでは、トップダウンとボトムアップの2つに分けて、考えてみましょう。こういうと、何となくカッコいいですよね。すごくいいことを言ってる感じがします。
トップダウン・アプローチ (・∀・)ｶｯｺｲｲ!!
トップダウンというのは、「システムが提供する機能群の使われる順番が、ほぼ限られる」もの。太いメインルートが数本あって、あとはその中で戻ってみたり、途中で終わったりといった派生ルートがあります。
イメージですが、こんな感じ。
step1・2・3の前後関係は、通常変わらない。それぞれのstepの中で選択肢はあるものの、1A→2A→3Aって行くのが王道。だけど、1Bや2Bのルートがあったり、step3を飛ばす（点線の丸四角がそれを示しています）こともできる。といったものです。
この場合、お客様がすでにシナリオのイメージを持っていることが多いと思います。トリッキーなルートの開拓に力を入れるよりは、絞ったルートの中で、各ユースケースの中のバリエーションを増やしてつなげてみるのがよさそうです。
上の例では、全ルートを通そうとすると、単純には2*3*3=18ルートになりますね。組み合わせ爆発が起きてしまう状況では、各stepのユースケースを因子と考えて、因子間の網羅を考えることができるのではないかと思っています。Pictmasterで試してみると*1、この例では10ルートで2因子間網羅ができるようです。
ボトムアップ・アプローチ (・∀・)ｶｯｺｲｲ!!
与えられたメインルートがなく、下から順番を積み上げていくことになります。となるとパターンが無限になりそうですね。
とはいえ、各ユースケースの間には、前後の制約があるはず。たとえば図書館の例でいうと、「本Aを借りる」前に「本Aを返す」ことはできない。とか。
この制約は、状態遷移表（wikipediaの記述でいう、2つ目の形式）イメージで、「あるユースケースと別のユースケースが連続して発生しうるか」のように表現できる。すると状態遷移表のスイッチ網羅（以下参照）のアナロジーで、2スイッチから順にシナリオを積み上げていけそうな・・・いけなさそうな・・・。
などなど色々考えてはみたものの。
「本Aを借りる」前に「本Aを返す」ことはできないけど、「別の本Bを返す」ことはできるわけで。色んなものが並行して走ることや、状態遷移表の「状態」に対応するものは何か、などと考えだすと、手に負えない感じが色濃いんですよね。
以上2つのアプローチはかなり机上の空論に近いのですが、「シナリオの網羅性はどうなってるの！？」という危険な問いかけに少しでも応えるために、何でも試してみたいなと。
補足
あやしげなことを色々書いてきましたが、シナリオテストでとても大事なことを漏らしていました。
それは、ユースケースとユースケースの間に、ユーザがシステムの外側で（「いわゆる「人間系」で）で行う作業もありうるということです。たとえば図書館システムの例でいえば、閲覧室に保管されていた本を書庫に移す、とか。
システムの機能そのものとは関係ないので、各機能のテストでは無視されそうですが、シナリオテストとしては、そのあたりの「人の動き」を意識してユースケースを接続してやることが、驚きの外部仕様不良の発見につながるかも・・・と思います。
その1からその3に向けて、だいぶ話がおぼつかない感じになって申し訳ありません。シナリオを考える人それぞれに、色々な考え方やテクニックがあると思いますので、どんどん吸収していきたいです。次回のSTE研究交流会で、傾聴しまくってきますね。
みなさんはどうやってシナリオを作っているのですか？アドバイスくださいませ。
*1:組み合わせテスト技法を、そういう風に使っていいのかわかりませんが・・・。
