設計工程にもテスト工程にも使えるデシジョンテーブル

テスト技法の１つにデシジョンテーブルテストがありますが、テスト対象の仕様が複雑だったり、優先順位が関係する場合、デシジョンテーブルが最適なテスト技法です。

テスト技法を解説した書籍では、わたしの知る限り、条件とアクションが行ごとに、ルール（Yes/Noなど）が列ごとに書かれたものばかりでした。おそらく、１ページの幅に収めるためにはこの書き方しかないからでしょう。この形式だと作成したデシジョンテーブルをテスト仕様書のチェックシートに転記する際に、行と列を入れ替える必要があります。つまり行ごとに１つのテストケースとしなければならないからです。テスト仕様書にExcelを使用している場合は、一旦、最初の形式で作成し、その後でチェックシートに貼り付ける際に「形式を選択して貼り付け」を選択し、「行列を入れ替える」にチェックを入れて貼り付ければ行と列を入れ替えることができます。

それよりも最初から条件とアクションを列ごとに、ルールを行ごとに記述したほうがよいと思います。書籍の記述上の都合で決まった形式にとらわれる必要はありません。

このデシジョンテーブルは、ソフト設計工程でも使用することができます。ソフト設計の際に、条件の組み合わせにより異なる処理となるようなソフトの場合に、表形式で各条件と処理内容をまとめたものを作成し、それをもとに設計や実装を行なうことはよくあると思います。本人は認識していないかもしれませんが、この表がデシジョンテーブルに相当します。

ソフト設計の際のデシジョンテーブルでは、結果に影響を及ぼさない条件はDon't Careとしてかまいませんが、テスト工程では、この部分を丸めてテストケース数を少なくすることにはリスクが伴います。特に重要な部分のテストではすべてのルールについてテストを実施する必要があります。

※ デシジョンテーブルをPictMasterで自動的に生成する方法を2009年3月8日の記事 で解説しています。参考にしてみてください。

テストプロセスの改善

共立出版から発売されている書籍にその名もずばり「テストプロセス改善」があります。本書はソフトウェア開発のプロセス改善について規定されているCMMIに似た概念を、テストプロセスに特化して記述したものです。

本書のユニークな点は、テストプロセスの各側面を「キーエリア」として明確化し、それぞれのプロセス改善の度合いに応じてレベルを設け、キーエリアごとに自分たちのテストプロセスがどのレベルにあるかが視覚的に捉えられる点です。

本書ではこれを「TPIモデル」と呼んでいます。キーエリアのレベルごとに、具体的に基準が明確化されており、レベルを上げるためにはどのようにすればよいか対策例も示されています。とにかく記述が具体的で豊富な例も記述されており、TPIモデルを読者が利用する上でとても参考になります。

TPIモデルは、固定したものではなく、テスト現場のニーズに応じて不要と思われるキーエリアを削除してもかまいません。

テストプロセスの改善が進むと、TPIモデルで表されたキーエリアごとのレベルが上がり、それは棒グラフの形で目に見えるものとして把握できます。

テストプロセスの改善について書かれた書籍は数多くありますが、その中でも本書は改善の各レベルについて具体的に定義されており、最も適用しやすく、改善の度合いが各レベルの上位レベルへの移行という形で明確に把握できる点で優れたものだと思います。

実際にテスト現場に適用する上で、上司、同僚などの理解の上での同意が必要ですが、これが最大の難関かもしれません。
　

出荷後の障害で最も多いのは２要因間の組み合わせに起因している

これはわたしのテストチームでの話ですが、総合テストの初期には、原因が１つの要因による障害がほとんどですが、テストを繰り返すうちに２つの要因の組み合わせに起因する障害が増えてきます。少数ですが、３つの要因の組み合わせに起因する障害も検出されるようになります。ある製品の総合テストにおいて、いくつの要因の組み合わせが障害となっているかの割合を以下に示します。

１つの要因　63.7%
２つの要因　32.6%
３つの要因　3.7%

この製品が出荷後に市場で見つかった障害が、いくつの要因の組み合わせで発生しているかを分析した結果は以下のとおりでした。

１つの要因　13.3%
２つの要因　73.3%
３つの要因　13.3%

この結果から、少なくともわたしのテストチームが担当した製品については、市場で発見された障害のうち２要因間の組み合わせに起因している障害が最も多くを占めていることがわかりました。なお、この製品では組み合わせテストでオールペア法を用いたのは全体のごく一部でした。

３要因間の組み合わせに起因する障害もありますが、２要因間ほどではありません。このことから、組み合わせテストにオールペア法を適用することにより、市場障害の発生件数を低減させることが期待できます。
　

クラッシャー○○

ソフトウェアテスト、特にブラックボックステストである総合テストでは、バグを見つけるのがうまい人がいます。これはもって生まれた素質が関係しているのかもしれません。ソフトウェア開発では、人によって開発効率に数倍以上の差があることはよく知られた事実ですが、テスト分野でも、バグを見つけることにかけては人によって差があるように感じます。

通常、テストはテスト仕様書に基づいて行いますが、私が関係したあるプロジェクトで、バグを発見した場合、テスト仕様書の確認内容との違いで発見したのか、それ以外の理由で発見したのかをバグ発見者に記録してもらったことがあります。その結果はそれぞれほぼ50%づつでした。もとよりテスト仕様書の記述でそのテスト項目におけるすべての確認内容を記述することは無理ですし、テスト実施の過程でテスト仕様書の確認事項を確かめる以前に他の機能のバグを見つけるということもあり得ます。

こうしたことに気づけるかどうかがバグの発見数の差となって現れるのかもしれません。

わたしのチームには、「クラッシャー○○」と呼ばれる人がいて、システムがフリーズするような重大なバグを見つけるのが飛び抜けてうまい人がいます。その人は女性でソフトウェアの専門知識はありません。勘が鋭いということでしょうか。属人的要素を排してどのような人が行なっても同じようにバグを見つける、ということが理想的なことでしょうが、理想と現実のギャップはあります。

あなたのチームにも「クラッシャー○○」と呼ばれるような人はいませんか？


※ PictMasterを使ってみて、これはバグじゃないの？ とか こうしたことができればもっと便利になる！ などありましたらメッセージをください。可能な範囲で対応させていただきます。

テストできない組み合わせを防ぐには

組み合わせテストでは、制約を正しく指定しなかったために、テストできない組み合わせが生成されてしまう可能性があります。こうした組み合わせが含まれているテストケースは、そのままではテストを実施して初めて実施不可能な組み合わせであることが分かります。そのため、制約を修正してテストケースを再度生成すると、前回とはまったく異なる組み合わせが生成され、それまで行なったテストが無駄になることになります。

PictMasterでは、原型シートの機能を使って、テスト途中でのテストケースの修正が可能であり、それまでのテストが無駄になるということはありませんが、できればテスト実施中のテストケースの修正は避けたいものです。

テスト仕様書作成の工程で、テストできない組み合わせが含まれてしまうことを防ぐには、テスト仕様書のレビューも有効ですが、もっと手軽にできる方法があります。

制約を含むテストケースを生成したら、生成結果のパラメータにExcelのオートフィルタをかけます。そして制約条件または制約対象となっているパラメータの値を指定し、フィルタ表示を行います。そうすると、指定した値と組み合わせられている他のパラメータの値を確認することができます。こうすることで、指定できないパラメータの値と組み合わせられていないかがすぐに分かります。また、組み合わせに含まれるべき値が含まれていないこともすぐに分かります。

Excelにはフィルタに2つまでのANDまたはOR条件を指定できるオプションがありますので、複雑な制約の確認にも使うことができます。

テストケース数が、数十件を超えるような場合は、生成された組み合わせに誤りがないか、Excelのフィルタ機能で確認しましょう。