テストパターンとは？効率的な洗い出しの方法も解説

開発工程においてテストは品質確保のために絶対に欠かせないものです。いかに漏れなくテストしたかでシステムの品質は決まる、といっても良いでしょう。しかし「漏れなくテストする」ことは予想以上に難しいことです。システムというのは人間が使う道具である以上、どう使われるかを、前もって全て洗い出すのは至難なことだからです。これをテストパターンの洗い出し、と言いますが、これを効率的かつ網羅的に作る事ができれば良いのですが、実際にやってみると、そう簡単にはいかないものです。そこで今回はテストパターンの洗い出しの方法を考えてみましょう。これさえ、うまくできれば、必ず自信をもって納品できるだけの品質を確保できるのですから。

テストパターンとは
テストパターンを効率的に洗い出すには
　直交表を作った方が良いケース
　直交表を成立させる経験則とは
　デシジョンケースを作った方が良いケース
直交表・デシジョンテーブルの作り方と具体例
　直交表の具体的な作成例
　直交表を作る時の注意点
　デシジョンテーブルの具体的な作成例
まとめ

テストパターンとは

テストパターンには、大きく分けて以下の2つの種類があります。
1：どんな条件のもとでどんなテストをするか、を洗い出してまとめたものです。
　これは別名「テストケース」とも呼ばれています。
2：テストでやることを条件によって1つずつ場合分けしたもののことです。
　これは「テストパターン」と呼ぶしかないものです。

1については当コラムで別途に解説しておりますので、こちらをご参照下さい。
https://wa3.i-3-i.info/word16090.html

ここでは2の「条件によって1つずつ場合分けした」ものをテストパターンと呼び、ご説明致します。

テストパターンを効率的に洗い出すには

「条件によって1つずつ場合分けしたもの」を効率的、かつ網羅的に作るには適切な方法は2つあります。1つは「直交表」と呼ばれるもの。もう1つは「デシジョンテーブル」と呼ばれるものです。それぞれをご紹介しましょう。

直交表を作った方が良いケース

分かりやすい例として「スキャナーをテストする場合」を考えてみましょう。スキャナーには「用紙」「解像度」「色」という3つのテスト要素が存在します。もし「用紙=A4とB5」、「解像度=普通と高解像」「色=カラーかモノクロ」と言う具合に各要素が取り得る値が2つしかないのであれば2×2×2=8ですので8パターンをテストすれば良い訳です。
これは、そんなに大変な作業ではないでしょう。しかし用紙がA3、A4、B5、B6の4種類になり、解像度が普通、中解像度、高解像度の3種類となると4×3×2=24パターンとなり先ほどの3倍になります。つまりテストパターンというのはテスト要素が取り得る値が多くなればなるほど飛躍的に増えていくのです。現実のテストでもテスト要素が取り得る値は多いことが多く「全てのパターンをテストすること」は物凄く大変な時間と手間がかかりテストに使うことができる工数では、とても全ては実施できないということがほとんどです。そこで「ある経験則」に基づいて「テストする価値のある最小限の組み合わせ」を割り出すのが「直交表」と呼ばれる手法です。

直交表を成立させる経験則とは

その「ある経験則」とは以下のようなものです。
「バグは2つの要素の組み合わせで発生することが、ほとんどである」
先に例で挙げたスキャナーで言いますと「用紙」「解像度」「色」という3つの要素がありますが、3つの要素の組み合わせにより起こるバグ、というのは滅多にないのです。
ということは、「用紙」「解像度」の組み合わせ、「解像度」「色」の組み合わせ、「用紙」「色」の組み合わせだけに着目すれば良い訳です。するとテストすべき組み合わせは相当に少なくなるのです。現実に「8パターンだけだから」といって全てのテストをしてみると「同じ内容のテストを繰り返している」ように感じてしまうはずです。つまり「やらなくても良いテストをしている」ことが実感として分かるはずです。直交表は、その「やらなくても良いテスト」をテストパターンから省略させることができる、非常に合理的な手法なのです。

デシジョンケースを作った方が良いケース

先のスキャナーのケースではテストパターンの割り出しに使う要素の内容が、何であっても必ずシステムは動作し結果を出します。しかしシステムの中には「ある一定条件の場合にのみ動作し結果を出す。条件に合わない場合は動作しない」というシステムもあります。このようなシステムの場合は、デシジョンテーブルと呼ばれる手法の方が有効です。
デシジョンテーブルでは動作する条件となる項目を列挙し、それらの項目が取り得る値を並べて論理的に考えられる全ての組み合わせを作り全パターンを表にします。次に動作する条件に合致するものを表の中から特定していくのです。分かりやすい例として「ある会社における今年の夏のボーナスの支給額を決めるシステム」を考えてみましょう。ある会社の今年の夏のボーナスの支給額が以下のように決められているとします。

・勤務年数が5年未満の社員には支給しない
・但し勤務年数が5年未満でも管理職である場合は10万円を支給する。
・勤務年数が5年以上の者は30万円を支給する。
・但し勤務年数が5年以上の者でも管理職である場合は50万円を支給する。

この内容を分析してみると「勤務年数が5年未満か否か」と「管理職であるか否か」の
2つの要素があることが分かります。そしてボーナスを支給しないケースは「動作しない」と考えてみるのです。そして動作する場合は「いくら支給するのか」という結果が出る、と考えるのです。そして「全ての組みあわせ」を1つずつ検証し「動作すべきケース」と「動作してはならないケース」のマークを付けていくのです。
すると「システムの正解表」が出来上がります。そして「動作すべきケース」は必ずテストしなければいけないケースとなるのですが、そのケースは全ての組み合わせの中の一部分でしかありません。つまり「必ずテストしなければいけないケース」が、この表から特定できるのです。そして、それは必ず「全ての組み合わせより圧倒的に少ない数」になります。残りの「動作してはいけないケース」は時間の許す限りテストしても良いのですが、先に述べました「直交表」の考え方を適用しテストケースを絞り込めば、最も適切で効率的なテストパターンが出来上がります。

直交表・デシジョンテーブルの作り方と具体例

直交表とデシジョンテーブルの作り方を具体的にご説明しましょう。まず直交表の作り方をご説明します。

直交表の具体的な作成例

先に例で挙げたスキャナーの例で言いますと「用紙」「解像度」「色」という3つの要素がありましたが、これを「用紙」「解像度」の組み合わせ、「解像度」「色」の組み合わせ、「用紙」「色」の組み合わせに着目し、パターンを作ってみましょう。まず「用紙」「解像度」の組み合わせです。これを図にしてみると以下のようになります。

用紙	解像度
A4	普通
A4	高像度
B5	普通
B5	高像度

次に同じように「解像度」「色」の組み合わせを作ってみます。

解像度	色
普通	カラー
高像度	モノクロ
普通	カラー
高像度	モノクロ

すると、2つの表の解像度の並び方が全く一致することが分かると思います。ですので、2つの表を合わせてみます。すると以下のようになります。

用紙	解像度	色
A4	普通	カラー
A4	高像度	モノクロ
B5	普通	カラー
B5	高像度	モノクロ

次に「用紙」「色」の組み合わせを作ってみると、以下のようになります。

用紙	色
A4	カラー
A4	モノクロ
B5	カラー
B5	モノクロ

先の表を見ると、この「用紙」「色」の組み合わせは、もう入っていることが分かります。
つまり「２つの要素の組み合わせ」に着目して見てみると3番目の表で組み合わせは全て網羅されているのです。3項目全てを網羅すると2×2×2=8パターンですが2項目の組み合わせに着目して整理すると、半分の4パターンだけやれば良い、ということが分かります。実際、この4パターンだけをテストすれば、ほとんどのバグは洗い出すことができるのです。このように各要素を2つずつの組み合わせにしてパターンを洗い出し、その結果を併せることにより直交表を作ることができるのです。

直交表を作る時の注意点

しかし直交表を作る時に注意すべき点が1つあります。それは「最も高負荷となるケースが入っているかどうか」です。例に取り上げたケースで最も高負荷となるのは用紙＝A4、解像度=高解像、色=カラーです。これが入っているかどうかを確認します。すると例に挙げたケースでは入っていません。

用紙	解像度	色
A4	普通	カラー
A4	高像度	モノクロ
B5	普通	カラー
B5	高像度	モノクロ

「最も高負荷となるケース」は「最も危険なケース」と言えますので、必ずテストすべきパターンです。ですので、それを追加します。

用紙	解像度	色
A4	普通	カラー
A4	高像度	モノクロ
B5	普通	カラー
B5	高像度	モノクロ
A4	高像度	カラー

これで「より強固なテストパターン」の完成です。

デシジョンテーブルの具体的な作成例

次は先に例として挙げた「ある会社における今年の夏のボーナスの支給額を決めるシステム」を元にデシジョンテーブルを作ってみましょう。支給規則は以下の通りです。

・勤務年数が5年未満の社員は支給しない
・但し勤務年数が5年未満でも管理職である場合は10万円を支給する。
・勤務年数が5年以上の者は30万円を支給する。
・但し勤務年数が5年以上の者でも管理職である場合は50万円を支給する。

動作条件となる項目は「勤務年数が5年未満か否か」と「管理職であるか否か」の2つです。まず、この2項目を縦に並べ、その横にY（YES）とN（NO）の全組み合わせを入れてみます。すると以下のようになります。

勤続年数が5年未満	Y	Y	N	N
管理職である	Y	N	Y	N

次に動作結果である賞与金額の10万円、30万円、50万円を行追加します。

勤続年数が5年未満	Y	Y	N	N
管理職である	Y	N	Y	N
賞与10万円
賞与30万円
賞与50万円

そして、規則を見ながら動作すべきケースには〇、動作してはいけないケースに×を入れていきます。

勤続年数が5年未満	Y	Y	N	N
管理職である	Y	N	Y	N
賞与10万円	〇	×	×	×
賞与30万円	×	×	×	〇
賞与50万円	×	×	〇	×

すると全部で3か所に〇が付きます。この〇のケースは必ずテストしなければいけないケース、となります。また先の直交表の論理的裏づけである「バグは2つの要素の組み合わせで発生することが、ほとんどである」という考え方を適用すると×については各列において×になっているケースを1つだけテストすれば良い、ということになります。つまり〇の3ケースと×を4ケースの合計で7ケースをテストすれば大丈夫ということになるのです。

まとめ

システム開発というのは大きな金額になることが多いものです。ですので、注文した側である顧客も「ちゃんとしたシステムができあがるのか。十分なテストが行われるのか」を心配しています。従ってテスト結果を提示する前にテスト計画として以上のような方法でケースを抽出しテストを行うことを説明しておけば、顧客も安心できます。また、どういうテストが行われるのかを事前に知らせておけば、テストの結果を見てもらう時に理解が得やすくなり、それは開発者に対する信頼性の向上に大きく寄与します。非常にレアケースのバグが発生した場合にも「それがレアケースである」ことを論理的に説明できる基礎ともなってくれます。システム開発というのは現実問題として顧客と開発者の共同作業ですので、顧客の信頼性を得ておくことは重要であり、システム開発を無事に終わらせる必須条件とも言えます。そして顧客の信頼を得られるかどうかは「しっかりとした論理的な内容の事前説明」が有るか無いかで大きく変わるのです。つまりテストパターンの作成方法をしっかりと身に付けておくことはシステムエンジニアにとって非常に重要なことなのです。覚えてしまえば簡単なことですが、知らなければ良いテストパターンが作れずバグを見逃してしまうことにつながってしまいます。すると顧客から「ちゃんとテストはしたのか」という、お叱りを受けることにもなりかねません。ですので、しっかりと覚えておいて下さい。必ず、役に立ちます。