読者です 読者をやめる 読者になる 読者になる

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

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

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

 その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スイッチから順にシナリオを積み上げていけそうな・・・いけなさそうな・・・。

softest.cocolog-nifty.com

 などなど色々考えてはみたものの。
 「本Aを借りる」前に「本Aを返す」ことはできないけど、「別の本Bを返す」ことはできるわけで。色んなものが並行して走ることや、状態遷移表の「状態」に対応するものは何か、などと考えだすと、手に負えない感じが色濃いんですよね。

 以上2つのアプローチはかなり机上の空論に近いのですが、「シナリオの網羅性はどうなってるの!?」という危険な問いかけに少しでも応えるために、何でも試してみたいなと。

補足

 あやしげなことを色々書いてきましたが、シナリオテストでとても大事なことを漏らしていました。
 それは、ユースケースユースケースの間に、ユーザがシステムの外側で(「いわゆる「人間系」で)で行う作業もありうるということです。たとえば図書館システムの例でいえば、閲覧室に保管されていた本を書庫に移す、とか。

 システムの機能そのものとは関係ないので、各機能のテストでは無視されそうですが、シナリオテストとしては、そのあたりの「人の動き」を意識してユースケースを接続してやることが、驚きの外部仕様不良の発見につながるかも・・・と思います。

 その1からその3に向けて、だいぶ話がおぼつかない感じになって申し訳ありません。シナリオを考える人それぞれに、色々な考え方やテクニックがあると思いますので、どんどん吸収していきたいです。次回のSTE研究交流会で、傾聴しまくってきますね。
 みなさんはどうやってシナリオを作っているのですか?アドバイスくださいませ。

*1:組み合わせテスト技法を、そういう風に使っていいのかわかりませんが・・・。