セルに１個の数値のみを入力するとエラーマークが表示される
Excel2003以降のExcelでPictMasterを使用した場合、セルに１個の数値のみを入力するとエラーマークが表示される不具合があります。
これはExcelのデフォルトのオプション設定では、セルの形式が文字列のセルに数値を入力するとエラーとみなすようになっているためです。PictMasterでは先頭が０で始まる値も入力可能とするためにセルの表示形式を文字列としています。
エラーマークが表示される問題は、Excelのオプション設定で、エラーチェックルールの「文字列形式の数値」のチェックを外すことで解決します。Excel2007ではオプションの「数式タブ」をクリックすることでエラーチェックルールの設定が表示されます。
近いうちにこの不具合を解消したバージョンをリリースする予定です。すでにPictMasterを使用されている方は、Excelのオプション設定で、エラーチェックルールの「文字列形式の数値」のチェックを外すことを推奨いたします。
テスト対象にふさわしいテスト技法を選択する デシジョンテーブルテストの場合
組み合わせテスト技法を使い慣れてくるにしたがい、ややもするとテスト対象の性質を見極めずにテスト技法として組み合わせテスト技法を適用してしまう間違いをおかす場合がでてくるようです。
テスト対象の中には複雑な論理を含むものがあります。例えば５つの要因があり、それらの値の組み合わせに応じて異なる結果となるような場合です。この場合は、５つの要因の全数組み合わせテストが必要となります。この場合の全数組み合わせテストとは言い換えればデシジョンテーブルテストということです。
５つの要因の全数組み合わせとなると、要因の値の数にもよりますが、テストケース数がかなり多くなります。たいていの場合は、同じ結果となる組み合わせは１つを残して他は削除することでデシジョンテーブルを「圧縮」することになります。ただし、テスト対象が人命や金銭に関わるような場合はデシジョンテーブルの圧縮は大きなリスクを伴います。
テスト対象がどのような性質を持っているかの見極めが不完全だと、デシジョンテーブルテストが必要なのに組み合わせテストを適用してしまう間違いをおかしてしまいます。この場合、組み合わせテストでは通常の場合、２つの要因の組み合わせしか網羅することが保障されないため、本来５つの要因の全数組み合わせが必要なのに部分的な組み合わせしか網羅されず、テスト漏れが起きてしまうことになります。
テスト設計を行なう場合は、まずテスト対象の性質を分析することからはじめ、テスト対象の性質を見極めたうえでそれに応じた適用すべきテスト技法を選択する必要があります。
テスト対象によっては組み合わせテストとデシジョンテーブルテストの両方が必要となるケースもあります。こうした場合は、デシジョンテーブル全体を１つのパラメータと見なし、デシジョンテーブルの１つづつのテストケースをその要因の値として組み合わせテストに統合することがよいでしょう。
２つのパラメータのみ３パラメータ間の組み合わせとする方法
すべてのパラメータを３パラメータ間の組み合わせとすると、生成されるテストケース数が多くなりすぎる場合があります。こうした場合は特に重要と考えるパラメータに限定して３パラメータ間の組み合わせを網羅するという方法をとることができます。
今回は特に重要と考える２つのパラメータに限定して、そのパラメータのみ３パラメータ間の組み合わせを網羅したテストケースを生成する方法を説明します。
例として図１のモデルがあり、パラメータAとBについて３パラメータの組み合わせを網羅するものとします。
このモデルでサブモデルの機能を使用して、パラメータAとBとの組み合わせ数に２を指定します。（図２）
このときの環境設定フォームでのパラメータの組み合わせ数はデフォルトの２のままとします。
サブモデルを使用してパラメータAとBの組み合わせ数に２を指定します。こうすると、パラメータAとBの組み合わせは、サブモデルで指定されなかったパラメータと２パラメータ間の組み合わせが生成され、最終的にパラメータAとBのみ、３パラメータ間の組み合わせが生成されることになります。（図３）
図３．パラメータAとBのみが３パラメータ間の組み合わせとなる生成結果
この例でのテストケース数は２７個でした。すべてのパラメータについて組み合わせ数を３とした場合に生成されるテストケース数は３８個となります。組み合わせ数を２とした場合の１２個より、今回の２７個は２倍以上の個数となりますが、すべての組み合わせ数を３個とした場合より、３割ほどテストケース数を削減することができます。また、テストケース数が組み合わせ数を２とした場合よりも多くなるため、その他のパラメータについては１００％とはなりませんが３パラメータ間の網羅率が向上します。
今回説明した方法は、３パラメータの組み合わせとする２つのパラメータの値の個数が、他のパラメータの値の個数より多くない場合に有効な方法です。逆に３パラメータの組み合わせとする２つのパラメータの値の個数が、他のパラメータの値の個数より多い場合はかえってテストケース数がすべてを３パラメータの組み合わせとした場合よりも増加してしまいます。こうした点に注意して使用すれば有効な方法です。
市場障害はいくつの要因の組み合わせで発生しているか 【7月13日更新】
製品出荷後に市場で発生した障害はいくつの要因の組み合わせで発生しているでしょうか。わたしたちが担当したシステムの例をあげてみたいと思います。担当しているシステムは内線電話機と外線数の合計が1000ポート規模の大型ビジネスホンシステムでの例です。このシステムでは市場への投入後、過去３年にわたって新機能を追加してきたものです。
以下に市場障害がいくつの要因の組み合わせで発生しているかをグラフで示します。このグラフでは発生率が非常に少ない要因数については示していません。
図１．市場障害がいくつの要因で発生しているか
このグラフで特徴的なことは２つの要因の組み合わせで発生する障害が５０％近くで最も多くなっています。次に１つの要因の組み合わせで発生する障害が約２３％で続いています。約１８％で組み合わせ数が３の障害が発生しています。割合は６％とかなり少ないですが、組み合わせ数が５という値もあります。
ここで要因の組合せ数の数え方を明確にしておきたいと思います。ある機能がどのような条件でも正常に動作しない場合、要因の組合せ数は１です。ある機能が特定の条件のときのみ正常に動作しない場合も要因の組合せ数は１と数えます。２ではありません。ある機能が特定の２つの条件の組み合わせとなるときのみ正常に動作しない場合の要因の組み合わせ数は２と数えます。機能それ自体は要因に含めることはできません。この記事を最初に掲載したときに、この要因の数え方が間違っていたため、修正して再掲載しました。
総合テストの段階では、組み合わせ数が１の障害が最も多いものですが、総合テストが進行していくに従って、組み合わせ数が２の障害が増えていき、総合テスト完了時点では、組み合わせ数２の障害件数が最も多くなることがこれまでの私たちの経験から明らかとなっています。
市場障害の傾向も、組み合わせ数２の障害が最も多いことで、総合テスト完了時点の傾向と同様となっています。
組み合わせテスト技法を採用すれば、２要因の組み合わせで発生する障害をテストの段階で効率よく発見することができます。ただし、すべてを発見するということは不可能です。まず、適切な要因を決定することの難しさがあります。テストすべき要因を決定するに当たり、できるだけ妥当な要因を取り上げるようにしていますが、どうしてもテスト段階では発見できない障害が残ることになります。
市場で発生した障害の要因を調べてみると、テスト段階ではまったく想像もできない要因が原因となって障害が発生していることがよくあります。こうしたことは組み合わせテスト技法の限界を示すものと言えます。総合テストの段階で見逃され、市場で障害となる事例ではイリーガルな要因が関係していることが多く、事前に想定できなくても無理もない事例が大半を占めています。こうした性質の障害はどうしても見逃してしまうことになります。組み合わせテストといえども「銀の弾丸」ではないということです。
こうした障害を事前に見つけるには、エラー推測テストがある程度有効であるように感じています。意地悪テストに似ていますが、システムに通常では考えられないような負荷をかけて不具合を見つけ出そうとしたりするものです。
市場障害では組み合わせ数が３の障害が約２０％近くを占めています。このことから３要因間の組み合わせ網羅率を高くしたテストを行なえばこれらの市場障害のいくらかは総合テストの段階で発見できると考えられます。ただし、テスト工数が増える割には発見できる障害は少ないでしょう。
皆さんのプロジェクトでも、市場での障害がいくつの要因の組み合わせで発生しているかメトリクスをとってみてはいかがでしょうか。きっと有意義なデータが得られるものと思います。
リスクに応じて網羅度の異なるテストを実施する
組み合わせテストでは、最も多くの数の値を持つパラメータと次に多くの値を持つパラメータの、それぞれの値の数を積算した値がテストケース数の最少の数となります。例えば１０個の値を持つパラメータを２つ含む場合、Pairwise（All-Pairs）法でのテストケース数は少なくとも１００件以上となります。このことから、組み合わせテストのテストケース数は、どうしても件数が多くなる傾向があります。
実際のテストにおいては限られた工数の枠内で実施できるテストケース数には限界があります。すでにテストを実施したことがあれば、１日当たり、１人がおおよそ何件のテストケースを実施できるかは分かります。工数が決まり、テスト担当者の人数が決まれば、全体として実施できるテスト件数が決まります。
実施できるテスト件数に合わせて全体のテストケース数が収まるように、テスト仕様書を作成する必要があります。テスト対象のすべてで２パラメータ間の組み合わせを網羅するとした場合、テストケース数が実施できるテスト件数をオーバーしてしまう場合が往々にしてあります。こうした場合は、テスト対象ごとにテストの重要度を決定し、重要度に応じてテストの網羅度を変える方法をとることになります。
テストの重要度とは、テスト対象で障害の見逃しがあり、製品出荷後に市場で障害が発生した場合に被るコストの大きさと障害発生の可能性の大きさで表わすことができます。コストが大きく可能性が高いと予想されるテスト対象については網羅度の高い徹底したテストを行ない、コストが小さく可能性が低いと予想されるテスト対象につては網羅度の低いテストを行なうことになります。
このように障害発生時のコストの大小と、障害発生の可能性の高低に応じてテストの網羅度を変化させるテスト実施方法を「リスクベースドテスト」といいます。リスクの大きいテスト対象には網羅度の高いテストが必要とされ、リスクの小さいテスト対象には網羅度の低いテストを割り当てます。
リスクベースドテストにおけるリスクの分類には様々な方法が考えられますが、分類方法の一例を次に示します。
機能が新規の機能か既存の機能か、機能が基本的な機能か個別的な機能か、といった２つの側面からテスト対象を分類することで、４つのゾーンのいずれかにテスト対象を割り振ります。（図１）
リスクは以下の４つに分けることができます。
①．新規・基本機能
新規の機能でかつほとんどのユーザが使用する機能
②．新規・個別機能
新規の機能だが使用するユーザが限定される機能
③．既存・基本機能
仕様変更のない既存機能だがほとんどのユーザが使用する機能
④．既存・個別機能
仕様変更のない既存機能で使用するユーザが限定される機能
以上の分類で、①は障害の発生する可能性が高く、かつ障害が発生した場合の影響が広範に及ぶもので、最もリスクが大きいものです。④は障害の発生する可能性が低く、かつ障害が発生した場合の影響が限定的であり、最もリスクが小さいものです。
新規の機能かそうでないか、基本的な機能かそうでないかを考慮したリスクの大きさは以下の通りとなります。
① > ② > ③ > ④
リスクの大きさに応じて異なる網羅度のテストを行ないます。
①．２パラメータ間の組み合わせを基本とし、より網羅度の高いテストも含む
②．２パラメータ間の組み合わせ網羅テストを行なう
③．２パラメータ間の組み合わせを基本とし、網羅度の低いテストも含む
④．要因を列挙したテストを基本とし、２パラメータ間の網羅度の低いテストも含む
網羅度による組み合わせテストの分類は以下の通りとなります。
１．３パラメータ間の組み合わせテスト
２．３パラメータ間の網羅度が５０％の組み合わせテスト
３．２パラメータ間の組み合わせテスト
４．２パラメータ間の網羅度が５０％の組み合わせテスト
５．各パラメータの値を列挙した要因列挙テスト
以上の１～５のテストの割合を調整して、テストケース数が全体として実施できるテスト件数に収まるようにします。