組合せテストで取り上げる要因をどのように決めるか
妥当な要因を決める方法にはこれが正しい方法だというものがあるというものではないと思います。関係する要因の異なるさまざまなテスト対象が無数にある中で、どのような場合でも適用できる決定的な正しい方法というものは存在しないと考えるべきでしょう。その上で、できるだけベターな方法を採用することになります。
組合せテストの要因の洗い出しはテスト対象の仕様を記述した機能仕様書をベースとします。機能仕様書の記述内容で出てくる要因を採用することになります（実際には機能仕様書に書かれていないことも採用することがあります)。このときに機能仕様書のなかである機能についての記述にはその機能の動作に影響を与える他の機能についても記述されているものです。組合せテストでは、こうした他の機能も要因に含めることになります。その意味では、組合せテストは「複合機能テスト」の意味合いを持つものになります。
ある機能について組合せテストのテスト項目を作成すると、同じ機能の別のテスト項目も組合せテストにしてしまい、組合せテストだらけになる場合があります。組合せテストはテストケース数が多い傾向があるため、すべてを組合せテストにしてしまうとテストケース数が膨大となり、テスト工数が足りなくなってしまいます。テスト項目の作成では、組合せテスト技法を採用する項目と組合せは行なわずに要因を列挙するだけの要因列挙テストを採用する項目とに分け、テストにメリハリをつける必要があります。
実際上、すべてのテスト項目を組合せテストにしなければならない必然性はありません。ある項目で組合せテストとしているのなら、次の項目は要因列挙テストとしてテスト工数の増加を防ぐ工夫が必要です。
また値のうちのいくつかはエイリアス化できるものがあり得ます。これはテストチームだけでなく開発側の人も含めてエイリアス化できる値がないか検討すべきです。またテスト結果に影響を与えることのない不要な要因がないかどうかについても開発チームからの助言が必要です。
テスト分野によっては基本的な要因のセットが存在する場合があります。たとえばビジネスホンシステムの場合は、基本的な要因のセットとは、回線種別と端末種別となります。最近のビジネスホンシステムでは多種多様な回線種別、端末種別が存在するようになってきており、組合せテストを実施する上で大きな問題になっています。基本的な要因のセットは多くの機能のテストで組合せテストに採用されることから、その組合せ数は全体のテストケース数に大きな影響を及ぼします。
エイリアス化が不十分であると全体のテストケース数は膨大なものとなってしまいます。そこで適切なエイリアス化が重要となってきます。このことについては開発チームとテストチームとの間で充分話し合いを行なって決定する必要があります。こうしたことは他のテスト分野でも当てはまるのではないかと思います。
組合せテストはその性質上、逆説的ではありますがテストケース数が増加しがちです。テストにメリハリをつけテストケース数を妥当な範囲内に収めることが重要でしょう。
市場障害発生条件に出現するキーワードの件数を調べる
製品を市場に出荷した後で発生する市場障害の内容を分析することで多くの有益なデータを得ることができます。今回は市場障害の内容を記述した「障害レポート」に登場する機能名称や端末名称などの「キーワード」について、どれがどのくらい出現するかを調べてみました。
調査した対象はビジネスホンシステムで、市場出荷後３年間で発生した市場障害についてです。この「障害レポート」に登場するキーワードを調べてみたところ、６個のキーワードが全障害レポートの７０％に出現していることが分かりました。わずか６個のキーワードが全障害の７割に出現しているという結果は驚きでした。「バグは偏在する」ともいわれますが、まさにそれが当てはまる結果でした。
障害レポートには障害が発生する条件が記述されていますが、この市場障害発生条件に出現するキーワードの出現割合を以下に示します。
この結果から、キーワードＡが関係する障害が全市場障害の２６％を占めていることが分かります。その他にキーワードＢとキーワードＣがそれぞれ１２％を占めています。
以上のことから、今後のテスト（現在の製品をベースにした新製品についてのテスト）においてはキーワードＡとキーワードＢおよびキーワードＣが関係するテストを重点的に実施する必要のあることが分かります。
みなさんも市場障害をキーワードで調べてみてはいかがでしょうか。
探索的テストはいつ行なうか
テスト技法のひとつに「探索的テスト」があります。探索的テストにおいてはテスト設計とテスト実行を同時並行的に行ないます。テストを行なった結果を考察し、バグを見つけるために有効と思われる次のテスト方法を頭の中でテスト設計し、それをもとにテストを行ないます。これを繰り返すことでバグを見つけようとするものです。
ほとんどのテスト技法は何らかのテストドキュメントをもとに行なう「スクリプトテスト」というカテゴリに属しますが、探索的テストではテスト担当者が即興で頭の中でテスト設計を行なうのでテストドキュメントは用いません。テスト技法を解説した書籍では、探索的テストがどのような場面で用いられるかについては特段説明されていないようです。
探索的テストはバグを発見したときに、どのような条件でバグが発生するのかを明確にするために必要となります。バグを発見すると不具合レポートを作成することになりますが、テストで見つかったバグがどのような条件の場合に発生するのかを明確にするためには探索的テストが欠かせません。テストで偶然見つかったバグ発生条件だけでなく、それ以外の条件ではどうなのかも明確にした不具合レポートを作成した方が、バグを解析する開発担当者にとってありがたいことになります。
ある条件でバグが発生するとき、条件の一部を変更してテストを行ない同じようにバグが発生するかをテストします。この作業を繰り返し、バグが発生する必要充分条件を突き止めます。この一連の作業が探索的テストにあたります。同時にバグ発生時のタスク間のメッセージ通信などのログ情報も収集し、不具合レポートに添付します。
開発担当者が不具合レポートに書かれたバグ発生条件を参考にすることはもちろんですが、多くの場合、ログ情報を読んだだけでバグ発生箇所が特定できるようです。
バグの発生条件を明確にする以外に、通常のテストの一環として探索的テストを行なうとしたら、あまり有効でないように思われます。なぜならどこをどのようにテストするのか見極めに必要な情報がそれほどないからです。そのような場合は「エラー推測テスト」が適しているとおもいます。
テスト対象が優先度を持つ場合はデシジョンテーブルでテストする
テスト対象の性質として優先度が関係する場合があります。例えばパラメータ A、B、C があり、それぞれが True と False の値を持つとします。パラメータには優先度があり、パラメータAの優先度が最も高く、パラメータCの優先度が最も低いものとします。各パラメータの値が True の場合にそのパラメータが有効となるものとします。
以上のテスト対象をテストする場合はデシジョンテーブルが最適なテスト技法となります。仮に組み合わせテスト技法を採用すると、そのテストケースは以下のようになります。
このテストケースでは、各パラメータの優先度をテストすることができません。なぜならパラメータ A、B、C の順に True と False の値が適切に組み合わされていないからです。
デシジョンテーブルでテストケースを作成すると以下の通りとなります。
このテストケースでは優先度の高いパラメータから順に値を True → False に変化させ、優先度の高いパラメータの値が False のときに、次に優先度の高いパラメータの値が True となるにようにしています。こうすることで、各パラメータの優先度どおりに正しい結果が得られるかテストすることができます。
なお、PictMasterの制約表を使用して今回のデシジョンテーブルと同じ組み合わせを作成することも不可能ではありませんが、それだけの手間をかけるなら最初からデシジョンテーブルを作成したほうが速いでしょうし、より複雑な優先度を持つ場合は制約表では指定できません。
テスト対象によっては、デシジョンテーブルテストと組み合わせテストが必要なものもあり得ます。そのような場合は、デシジョンテーブルのパラメータを１つのパラメータと見なし、各テストケースをそのパラメータの値とし、他のパラメータとの組み合わせテストを行なうことになります。
PictMaster v4.2.1 をリリースしました。
組み合わせテストケース生成ツール PictMaster 4.2.1 をリリースしました。
4.2 からの変更点は以下の通りです。
【バグ修正】
・セル内の値が一つの数値の場合、セルにExcelのエラーマークが表示される場合があるバグを修正した。
【その他】
・ユーザーズマニュアルの「６．より有効な使い方」の章にいくつかの記述を追記した。
PictMaster 4.2.1 は以下のサイトからダウンロードすることができます。