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

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

「シナリオテスト」とは一体、何なのか - その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:組み合わせテスト技法を、そういう風に使っていいのかわかりませんが・・・。