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

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

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


スポンサードリンク

 NPO法人ソフトウェアテスト技術振興協会(ASTER)の研究事業として、STE(Software Testing for Enterprise systems)という活動があります。エンタープライズ向けシステム開発におけるテストについての議論を行うもので、ぼくはその交流会に参加しています。

 STE研究交流会として、広くユーザやベンダ、学術の方を集め、上記課題に対する情報や意見交換を行ないます。また、海外におけるエンタープライズシステム向けのソフトウェアテスト事例などの紹介も行なう予定です。(公式サイトより)

 先日、第2回が催されました。
 メインとなるトピックは、「シナリオテスト」です。人によって意味合い・位置づけの違うシナリオテストを、JSTQBやISO29119の言葉を借りて定義しつつ、その方法論を考えていこうというものです。

 2時間半ほどの時間がありましたが、シナリオテストに対するメンバーの理解は多様。個々人の考えを交換するだけで、ほぼタイムアップとなってしまいました。
 次回はもっと議論したいと思ったため、シナリオテストに対する自分の考えを、ちょっと整理してみようと思います。お約束ですが、会社の見解じゃないです。STEの見解でもありません。

「テストシナリオ」のイメージ

 「シナリオテスト」で実行される対象を「テストシナリオ」と呼ぶとして、テストシナリオとは何か。図書館において、本の貸し出し・返却や予約などを行うシステムを例にとってみます。
 このシステムのユースケースシナリオとしては、「本を予約する」「本を予約するけど取り消す」「本を借りる」「本の返却を延滞する」といったものが書かれると思います。

 ぼくのイメージでは、テストシナリオとは機能ごとに分かれたユースケースシナリオをつなげたものです。場合によっては、市民が図書館の利用者登録をするところから始めて、インターネットでの予約・貸し出し・返却、そして最終的に利用者登録を削除する、という流れになります。よって、長い時間軸を意識します。*1

 ただディスカッションの中でうすうす、別の「シナリオ」がありうるということに気づきました。以下は、コチラからの引用です。

■Bさん(月給+賞与 月給60万円、賞与90万円×2)
毎月の保険料4万9460円、ボーナス時7万5447円
(4万9460円×12+7万5447円×2=年間74万4414円)

 「年金制度が変わるとこうなる!」みたいな特集に出てくる、モデルケース的なもの。これを「シナリオ」と呼ぶこともあるように思えてきました。これだとまったく話が違ってきますが、とりあえず以降の話は前者のシナリオ、つまり「ユースケースをつなげたもの」という意味で書きます。

「シナリオ」のオレオレ定義

 第2回の場では、シナリオテストに関係しそうな用語について再確認しようということで、HPの湯本剛さんが、ISO/IEC 29119の記述を図として独自に整理したものを紹介してくださいました。その関係図の中で、「シナリオテスト」をどう位置づけよう、というお話です。

 そこでのディスカッションを聞いたうえで、ぼくは「テストシナリオ」を以下の通り定義してみました。

 テストシナリオとは、「テストケースの部分集合に順序をもたせたもの」である。

 つまり、既存のテストセットの中から、1個以上のテストケースを選択して、順序付けしたもの。
 なお、テストシナリオに含まれる個々のテストケースは、統合テストで検証済みであるべき。なので、シナリオテストは統合テストに後に行うものと考えています。

テストシナリオの数え方

 では、シナリオテストは、テストシナリオとテストケース、どちらで測るべきでしょう。*2

 基本は、シナリオで数えるってことでいいでしょう。たとえば、「シナリオテストでは、全部で80本のシナリオを消化します」
 シナリオの本数で数えることのメリットは、以下の2つです。

  1. テストシナリオは業務そのもののストーリーであり、とてもお客様に近いものなので、その数を数える方がイメージしていただきやすい。
  2. 上述の定義上、複数のシナリオが同じテストケースを含むことがある。よって、テストケースの件数を、統合テストの件数と単純比較されたりすると困ってしまう。

 一方、テストケースの件数で数えることのメリットは、以下。

  1. 進捗の管理がしやすい。「残り10シナリオ」といったとき、それが短い10シナリオか、長い10シナリオかで、意味がまったく違う。シナリオに比べて、テストケースはそれぞれの粒度が近く、進捗が見えやすい。
  2. 各シナリオのどこまで進んでいるかがわかりやすい。

 場合によって使い分ければいいと思います。
 まあこのあたりは、それほど本質的な話じゃないのかも知れませんが、基本的な考え方みたいなものは、一致している方がよいですよね。

 書こうと思ってることの半分も書けなかったので、多分その2があります。期待は乞わない。

*1:この時点で、「いや、ユースケースシナリオって別に機能ごとに分かれてないよ」ってことならスミマセン、勉強不足です。。

*2:シナリオを数える単位は、アプリオリに「本」でお願いしますw。