国内と全世界におけるPairwise系と直交表系への関心度を比較（2013年版）
2008年12月8日と2010年06月17日の記事で、ソフトウェアテストに関する国内と全世界におけるPairwise法（All-Pairs法）と直交表への関心度をgoogleの検索ヒット数で比較してみました。今回は前回の調査から2年半が経過した時点での関心度を調査してみたいと思います。
Googleの検索アルゴリズムが今年の半ばに大きく変更されたようで、前回とまったく同じ語句を用いて検索するとヒット件数が前回より激減してしまうというあり得ない結果となってしまいます。また複数の検索語句を指定した場合に語句の並び順を替えただけでヒット件数が大きく変化してしまいます。その意味で関心度を調査する上でヒット件数そのものはあまり信頼できないのですが、各ヒット件数の割合の比較ではそれなりに意味のある結果が得られるでしょう。
参考のためこれまでの調査結果を以下に示します。
2008年末時点でのデータ
全世界（すべての言語）での各用語のGoogleヒット件数 （厳密に言えば英語圏に限定しています）
Orthogonal Software test 187,000件（直交表）
----------------------------------
合計： 187,000件
比率： 46.6%
"All-Pairs" software test 33,900件
Pairwise software test 180,000件
-----------------------------------
合計： 213,900件
比率： 53.4%
国内（日本語）での各用語のGoogleヒット件数
"直交表" ソフト テスト 10,500件
"HAYST法" 10,100件
----------------------------------
合計： 20,600件
比率： 98.9%
"All-Pair法" 72件
"All-Pairs法" 9件
"オールペア法" 88件
"Pairwaise法" 30件
"ペアワイズ法" 40件
-----------------------------------
合計： 239件
比率： 1.1%
2010年6月時点でのデータ
全世界（すべての言語）での各用語のGoogleヒット件数
Orthogonal Software test 208,000件（直交表）
----------------------------------
合計： 208,000件
比率： 43.6%
"All-Pairs" software test 54,200件
Pairwise software test 215,000件
-----------------------------------
合計： 269,200件
比率： 56.4%
国内（日本語）での各用語のGoogleヒット件数
"直交表" ソフト テスト 40,000件
"HAYST法" 20,800件
----------------------------------
合計： 60,800件
比率： 74.1%
"All-Pair法" 16,200件
"All-Pairs法" 54件
"オールペア法" 4,930件
"Pairwaise法" 37件
"ペアワイズ法" 75件
-----------------------------------
合計： 21,296件
比率： 25.9%
これまでの調査では似た語句を複数用いてそれぞれのヒット件数の合計を最終結果としていました。前にも書きましたがGoogleの検索アルゴリズムが大きく変更されたらしく前回と同じ語句で検索すると例えば "直交表" ソフト テスト のヒット件数が前回の５０分の１になったりしてしまい、前回と同じ語句が使えませんでした。そこでなるべくこれまでの検索結果の傾向に近い結果となるように語句を選びました。また今回は検索にOR演算子を用いてどれかの検索語句が含まれていればヒットするようにしました。例えば次のように指定します。
"オールペア" OR "all-pair" OR "ペアワイズ" OR "pairwise" ソフト テスト
これは検索したページに"オールペア"または"all-pair"または"ペアワイズ"または"pairwise"のいずれかが含まれていて、かつ"ソフト"と"テスト"が同時に含まれているページがヒット件数としてカウントされます。
今回の検索語句とヒット件数と直交表系とPairwise系の比率の結果は次の通りとなりました。
2013年末時点でのデータ
全世界（すべての言語）での各用語のGoogleヒット件数
"Orthogonal" Software test（直交表）
----------------------------------
約2,430,000件
比率： 49.9%
"pairwise" OR "all-pair" software test
-----------------------------------
約2,440,000件
比率： 50.1%
国内（日本語）での各用語のGoogleヒット件数
"直交表" OR "HAYST" ソフト テスト
----------------------------------
約11,200件
比率： 52.3%
"オールペア" OR "all-pair" OR "ペアワイズ" OR "pairwise" ソフト テスト
-----------------------------------
約10,200件
比率： 47.7%
Googleのヒット件数は今年検索アルゴリズムの変更が行なわれたせいで前回以前との比較ができなくなっています。そこで今回はヒット件数そのものの比較ではなく、直交表系とPairwise系のヒット件数の割合を比較することにしました。こうすることでこれまでの調査との連続性が確保できようになります。
以上の結果をグラフにまとめました。
(1) 全世界では2008年からこれまでに直交表系とPairwise系の関心度はほぼ拮抗しており、大きな変化は見られない。
(2) 国内では2008年にはほぼ皆無だったPairwise系への関心が年を追うごとに増加し、2013年時点では直交表系とほとんど同じ関心度まで高まった。
(3) 2013年になって国内における直交表系とPairwise系の関心度は全世界における関心度と同じ傾向を示すようになった。
特に目を引くのが国内におけるPairwise系への関心の高まりです。2008年時点ではPairwise系への関心はほとんど皆無と言える状況でした。同じとき、全世界では直交表系とPairwise系の関心度はほぼ拮抗しており、国内の状況は直交表系に著しく偏ったいわゆる「ガラパゴス状態」でした。どうしてそうした状況だったのか。それにはいろいろな理由が考えられますが、そのひとつに品質管理の優れた手法として田口玄一博士があみだした「タグチメソッド」が広く知られていたことが関係しているようです。直交表は少ない実験回数で結果に最も大きな影響を与える因子を見つけ出す方法としてタグチメソッドを取り入れることでより使いやすいものになりました。直交表を品質管理の手段として利用することにおいて日本は本家本元であり、そのことが国内のソフトウェアテストにおける直交表系への関心の高まりに大きく影響していたと考えられます。
そうした日本特有の状況もPICTという実用的なPairwise系のフリーソフトの出現で大きく変わりました。PICTの存在抜きには国内における近年のPairwise系への関心の高まりは考えられないでしょう。直交表系にも多くの関心がありますが、実際のテストにおいて実用的に使えているかといえば疑問を抱かざるを得ません。直交表をソフトウェアテストで実用的に使用するにはツールの利用が欠かせませんが、フリーのツールはもちろん、有償のツールでも実用的に使えるツールはほとんど皆無という状況が続いています。それは直交表で実用的なツールを開発しようとするには莫大な開発費がかかるからです。特に直交表系のツールでは制約の扱いが非常に難しいというハードルがあります。これは直交表が持つ性質自体に根ざしているため、将来的にも解決できる問題ではありません。
それにもかかわらず、なぜ多くの人々が直交表に関心を抱いているのでしょうか。それは直交表が持つ「なんとなく高度なイメージ」のせいかもしれません。直交表では特殊な専門用語が頻繁に出現します。それが極めて難解なものであれば多くの人々の関心を引くことはありませんが、ある程度難解ですが理解できないほどではない、というレベルであるためにそれほど障害とはならないのでしょう。また直交表には３因子間網羅率が高い、３因子間の組み合わせが均等に出現するというPairwise系にはない利点があります。そのことも直交表系への関心を高めているものと思われます。
組み合わせテストに関心を持ち始めた人の多くはまず直交表に関心を持つようです。それは先ほどあげた理由からですが、やがてその限界を知り、より実用的にテストに利用できるPairwise系に関心を持つようになるのではないかと思います。
Googleの検索アルゴリズムが今年の半ばに大きく変更されたようで、前回とまったく同じ語句を用いて検索するとヒット件数が前回より激減してしまうというあり得ない結果となってしまいます。また複数の検索語句を指定した場合に語句の並び順を替えただけでヒット件数が大きく変化してしまいます。その意味で関心度を調査する上でヒット件数そのものはあまり信頼できないのですが、各ヒット件数の割合の比較ではそれなりに意味のある結果が得られるでしょう。
参考のためこれまでの調査結果を以下に示します。
2008年末時点でのデータ
全世界（すべての言語）での各用語のGoogleヒット件数 （厳密に言えば英語圏に限定しています）
Orthogonal Software test 187,000件（直交表）
----------------------------------
合計： 187,000件
比率： 46.6%
"All-Pairs" software test 33,900件
Pairwise software test 180,000件
-----------------------------------
合計： 213,900件
比率： 53.4%
国内（日本語）での各用語のGoogleヒット件数
"直交表" ソフト テスト 10,500件
"HAYST法" 10,100件
----------------------------------
合計： 20,600件
比率： 98.9%
"All-Pair法" 72件
"All-Pairs法" 9件
"オールペア法" 88件
"Pairwaise法" 30件
"ペアワイズ法" 40件
-----------------------------------
合計： 239件
比率： 1.1%
2010年6月時点でのデータ
全世界（すべての言語）での各用語のGoogleヒット件数
Orthogonal Software test 208,000件（直交表）
----------------------------------
合計： 208,000件
比率： 43.6%
"All-Pairs" software test 54,200件
Pairwise software test 215,000件
-----------------------------------
合計： 269,200件
比率： 56.4%
国内（日本語）での各用語のGoogleヒット件数
"直交表" ソフト テスト 40,000件
"HAYST法" 20,800件
----------------------------------
合計： 60,800件
比率： 74.1%
"All-Pair法" 16,200件
"All-Pairs法" 54件
"オールペア法" 4,930件
"Pairwaise法" 37件
"ペアワイズ法" 75件
-----------------------------------
合計： 21,296件
比率： 25.9%
これまでの調査では似た語句を複数用いてそれぞれのヒット件数の合計を最終結果としていました。前にも書きましたがGoogleの検索アルゴリズムが大きく変更されたらしく前回と同じ語句で検索すると例えば "直交表" ソフト テスト のヒット件数が前回の５０分の１になったりしてしまい、前回と同じ語句が使えませんでした。そこでなるべくこれまでの検索結果の傾向に近い結果となるように語句を選びました。また今回は検索にOR演算子を用いてどれかの検索語句が含まれていればヒットするようにしました。例えば次のように指定します。
"オールペア" OR "all-pair" OR "ペアワイズ" OR "pairwise" ソフト テスト
これは検索したページに"オールペア"または"all-pair"または"ペアワイズ"または"pairwise"のいずれかが含まれていて、かつ"ソフト"と"テスト"が同時に含まれているページがヒット件数としてカウントされます。
今回の検索語句とヒット件数と直交表系とPairwise系の比率の結果は次の通りとなりました。
2013年末時点でのデータ
全世界（すべての言語）での各用語のGoogleヒット件数
"Orthogonal" Software test（直交表）
----------------------------------
約2,430,000件
比率： 49.9%
"pairwise" OR "all-pair" software test
-----------------------------------
約2,440,000件
比率： 50.1%
国内（日本語）での各用語のGoogleヒット件数
"直交表" OR "HAYST" ソフト テスト
----------------------------------
約11,200件
比率： 52.3%
"オールペア" OR "all-pair" OR "ペアワイズ" OR "pairwise" ソフト テスト
-----------------------------------
約10,200件
比率： 47.7%
Googleのヒット件数は今年検索アルゴリズムの変更が行なわれたせいで前回以前との比較ができなくなっています。そこで今回はヒット件数そのものの比較ではなく、直交表系とPairwise系のヒット件数の割合を比較することにしました。こうすることでこれまでの調査との連続性が確保できようになります。
以上の結果をグラフにまとめました。
(1) 全世界では2008年からこれまでに直交表系とPairwise系の関心度はほぼ拮抗しており、大きな変化は見られない。
(2) 国内では2008年にはほぼ皆無だったPairwise系への関心が年を追うごとに増加し、2013年時点では直交表系とほとんど同じ関心度まで高まった。
(3) 2013年になって国内における直交表系とPairwise系の関心度は全世界における関心度と同じ傾向を示すようになった。
特に目を引くのが国内におけるPairwise系への関心の高まりです。2008年時点ではPairwise系への関心はほとんど皆無と言える状況でした。同じとき、全世界では直交表系とPairwise系の関心度はほぼ拮抗しており、国内の状況は直交表系に著しく偏ったいわゆる「ガラパゴス状態」でした。どうしてそうした状況だったのか。それにはいろいろな理由が考えられますが、そのひとつに品質管理の優れた手法として田口玄一博士があみだした「タグチメソッド」が広く知られていたことが関係しているようです。直交表は少ない実験回数で結果に最も大きな影響を与える因子を見つけ出す方法としてタグチメソッドを取り入れることでより使いやすいものになりました。直交表を品質管理の手段として利用することにおいて日本は本家本元であり、そのことが国内のソフトウェアテストにおける直交表系への関心の高まりに大きく影響していたと考えられます。
そうした日本特有の状況もPICTという実用的なPairwise系のフリーソフトの出現で大きく変わりました。PICTの存在抜きには国内における近年のPairwise系への関心の高まりは考えられないでしょう。直交表系にも多くの関心がありますが、実際のテストにおいて実用的に使えているかといえば疑問を抱かざるを得ません。直交表をソフトウェアテストで実用的に使用するにはツールの利用が欠かせませんが、フリーのツールはもちろん、有償のツールでも実用的に使えるツールはほとんど皆無という状況が続いています。それは直交表で実用的なツールを開発しようとするには莫大な開発費がかかるからです。特に直交表系のツールでは制約の扱いが非常に難しいというハードルがあります。これは直交表が持つ性質自体に根ざしているため、将来的にも解決できる問題ではありません。
それにもかかわらず、なぜ多くの人々が直交表に関心を抱いているのでしょうか。それは直交表が持つ「なんとなく高度なイメージ」のせいかもしれません。直交表では特殊な専門用語が頻繁に出現します。それが極めて難解なものであれば多くの人々の関心を引くことはありませんが、ある程度難解ですが理解できないほどではない、というレベルであるためにそれほど障害とはならないのでしょう。また直交表には３因子間網羅率が高い、３因子間の組み合わせが均等に出現するというPairwise系にはない利点があります。そのことも直交表系への関心を高めているものと思われます。
組み合わせテストに関心を持ち始めた人の多くはまず直交表に関心を持つようです。それは先ほどあげた理由からですが、やがてその限界を知り、より実用的にテストに利用できるPairwise系に関心を持つようになるのではないかと思います。
原因結果グラフとCFD技法を比較する
原因結果グラフとCFD技法はともにデシジョンテーブルを作成するためのテスト技法であり、論理関係が複雑なテスト対象に適用することができます。今回は同じテスト対象に両者を適用してみて、その違いを比較してみることにします。テスト対象には単純な論理関係では違いが分かりにくいので少し込み入った例題を取り上げることにします。
例題の仕様
例題は、就業可能な最低就業年齢を判定する問題です。最低就業年齢は次の仕様で決定されます。
1. 使用者が、労働者として就業させることが可能な最低年齢は、満15歳に達した日以後の最初の3月31日が経過した者（義務教育終了者）である（労働基準法56条）。
2. 最低年齢に達しない者は労働基準法上「児童」と称され、原則として就業させることはできないが、例外として次の事業については行政官庁の許可を受けて使用することができる。
3. 行政官庁の許可を受けるには、児童の年齢証明書、児童の就学に差し支えがないことを証明する学校長の証明書、および親権者または後見人の同意書を様式第1号の使用許可申請書に添えて労働基準監督署に提出しなければならない（年少則1条）。
4. 使用者は、使用する満18歳未満の者について、その年齢を証明する戸籍証明書を事業所に備え付けなくてはならない。また、満15歳に達した以後の3月31が経過しない者を使用する場合、児童の就学に差し支えがないことを証する学校長の証明書および親権者または後見人の同意書を事業場に備え付けなくてはならない（労働基準法57条）。
この仕様をもとに就業可能な年齢であるかを判定する原因結果グラフとCFDを作成してみます。
原因結果グラフ
まず原因結果グラフから作成します。
原因結果グラフを作成するには最初に原因ノードと結果ノードを定義します。
さきにあげた仕様をよく分析し適切な原因ノードを定義する必要があります。必要となる原因ノードには次のものがあります。
(1) 満18以上
(2) 満16歳以上～18歳未満
(3) 満15歳
(4) 満15歳未満
(5) 今日が3月30日以前
(6) 児童の年齢証明書を提出
(7) 学校長の証明書を労基署に提出
(8) 学校長の証明書を事業所に提出
(9) 使用許可申請書を提出
(10)戸籍証明書を提出
(11)親権者がいる
(12)親権者が労基署に提出
(13)親権者が事業所に提出
(14)後見人がいる
(15)後見人が労基署に提出
(16)後見人が事業所に提出
このうち、(5)は年齢が満15歳の場合に児童かどうかを判別するために必要となる原因ノードです。
結果ノードは「就業可能」の１つのみです。
次に原因ノード間の制約を定義します。各年齢のノード間にはONE制約が、親権者と後見人のノード間にはEXCL制約が必要です。EXCL制約とする理由は、満20未満では親権者と後見人のどちらか一方だけが必ず真となること、満20歳以上では親権者と後見人は必ず偽となるからです。
続いて仕様から、原因ノードと結果ノードを結ぶために必要となる中間ノードを定義します。中間ノードは原因結果グラフが作成しやすくなるように必要に応じて定義します。このようにして作成した原因結果グラフを次に示します。
この原因結果グラフをもとにしてデシジョンテーブルを作成することにします。
デシジョンテーブルを作成する際の原則があります。OR条件のノードを真とする場合はどれか１つの入力だけを真とし、他の入力はすべて偽とします。AND条件のノードを偽とする場合はどれか１つの入力のみを偽とし、他の入力はすべて真とします。これはテスト対象が仕様の論理通りに実装されているかを漏れなく確認するために必要なことです。
最初に結果ノードが真となるルールを決定します。まず年齢が18歳以上であれば真となることが分かります。この場合、結果に関係しない入力はすべて偽となるようにします。これは年齢が18歳以上であるだけで無条件に結果が真となることを確認するために論理上は無関係な入力も偽とすることで、仕様の論理と異なる実装が行なわれていた場合にバグを発見しやすくするために必要なことです。
続いて中間ノードの「児童の就業を行政官庁が許可」と「児童の書類を事業所が保有」がともに真となるルールを決定します。これにはいくつかの組み合わせがあるのでそのすべての組み合わせを洗い出します。同様に中間ノードの「満18歳未満で非児童の書類を事業所が保有」が真となるルールを洗い出します。
次に結果ノードが偽となるルールを決定します。これは原因ノードの「満18歳以上」が偽で、中間ノードの「児童の就業を行政官庁が許可」と「児童の書類を事業所が保有」のどちらか一方だけが偽で、中間ノードの「満18歳未満で非児童の書類を事業所が保有」が偽となるルールを決定します。これには多くの組み合わせがあるのでそのすべての組み合わせを洗い出します。このとき、それぞれのルールでは結果ノードが偽となる必要最低限の原因ノードだけを偽とすることが重要です。
このようにして作成したデシジョンテーブルを次に示します。
CFD技法
次に同じ例題にCFD技法を適用してみます。
CFD技法では原因結果グラフと異なり、中間ノードという概念がありません。原因を横に並べ、その間を流れ線でつなぐ形になります。原因は原因結果グラフでの原因ノードと同じです。制約は流れ線の原因との接続で表現します。結果は「就業可」と「就業不可」の２つです。この原因と結果とをどのように流れ線でつなぐかで仕様の論理関係を表すことになります。
この例題は結果が正常系と異常系の２つとなり、CFD技法が最も適用しやすい対象です。作成したCFDを次に示します。
このCFDから作成したデシジョンテーブルを次に示します。
ルールの数が原因結果グラフの１７に対してCFDでは２７と多くなっていますが、これは15歳で児童と15歳未満の児童、親権者がいると後見人がいる、という条件と各書類の未提出の条件の組み合わせを原因結果グラフでは省略しているのに対し、CFDではその組み合わせを網羅していることが理由です。
原因結果グラフでは仕様の実装に近いと考えられる論理構造を把握することができます。このことから結果に影響を与えないと考えられる条件が比較的分かりやすいのですが、CDF技法では仕様の実装がどう行われるかを、描いたCFDから把握することはまず不可能です。
原因結果グラフとCFD技法の比較
原因結果グラフでは非常に複雑な論理関係も表現することができますが、CFD技法ではあまり複雑な論理関係は表現できません。CFD技法でもフラグを使ったりして複雑な論理関係を表現しようとする試みがあるようですが、一般にはほとんど知られていないのが現状のようです。CFD技法のメリットは何と言ってもCFDさえ描ければ流れ線をなぞるだけでデシジョンテーブルの作成が極めて簡単にできるという点です。この点に関しては原因結果グラフではCFD技法と比較すると難しくはありませんがかなり煩雑な作業が必要となります。
テスト技法の習得のしやすさという点ではCFD技法がかなり有利です。原因結果グラフは仕様の論理関係をANDやORで表現したり、制約を使用する必要があり、習得の敷居は高いと言えます。ただ原因結果グラフを使ったことがない人が思っているほど難しいわけではないように感じます。
原因結果グラフでもCFD技法でも最も難しいのが仕様から適切な原因を抽出するということです。今回の例題では書類を労基署と事業所の両方に提出する必要がありますが、最初は原因を書類の有無だけにしてしまうというミスをしてしまいました。原因には「書類を労基署に提出」と「書類を事業所に提出」の両方が必要だと後で気づきました。この仕様から適切な原因を抽出するということができれば、デシジョンテーブルの作成完了までの作業の半分は完了したも同じです。
原因結果グラフでは同時に真となる結果が１つだけの結果ノードが複数ある場合にデシジョンテーブルの作成が容易になります。これはデシジョンテーブル作成時に着目している１つの結果ノードが真となる条件だけを調べればよいからです。その結果ノードが偽となる条件は調べる必要がありません。これに対して結果ノードが１つだけであったり、同時に真となる結果ノードが複数ある場合は、着目している１つの結果ノードが真となる場合と偽となる場合の両方の条件を調べる必要があり煩雑な作業となります。
複数の原因間の論理関係がなく単純な組み合わせだけで異なる結果となる仕様を含む場合では、原因結果グラフでもCFD技法でも扱いが難しくなります。前回の記事で取り上げた「Wordの文字飾り機能をテストする」がその極端な例です。
原因結果グラフとCFD技法を比較した表を次に示します。
原因結果グラフのツール使用について
原因結果グラフにはCEGTestというフリーのツールがあります。CEGTestが生成したこの例題のデシジョンテーブルを次に示します。
このツールのデータは次のURLからテキストファイルとしてダウンロードすることができます。ダウンロードしたテキストファイルをCEGTestのファイルメニューのインポート（CSV)で表示されるテキストボックスにペーストすることで、上で示した原因結果グラフとまったく同じものを生成することができます。
http://sourceforge.jp/projects/pictmaster/docs/data/ja/2/data.txt
ここではこのツールを使用する上での注意点を記します。このツールが公開されているサイトのブログ記事に書かれていますが、CEGTestは「中間ノードが観測可能である」ことを前提としています。このことが何を意味するかというと、ツールが生成したデシジョンテーブルでテストを行なう場合は、事前に単体テストで検出すべきバグがすべて検出されていてバグがない状態となっている必要があるということです。CEGTestで生成されるデシジョンテーブルは、この条件を満たしていないテスト対象ではバグを見逃す可能性があります。さらにこのブログ記事には書かれていませんが、論理関係が機能間にまたがる場合は、その間のインタフェースが正しく実装されている必要があります。インタフェースが正しく実装されていないテスト対象ではバグを見逃す可能性があります。ここまでの条件が満たされているテスト対象がもしあるとすれば、もうCEGTestを使ってテストする必要がないといえるでしょう。
単体テストが充分行なわれていて単体テストで発見すべきバグがすべて単体テスト工程で発見できているのなら、単体テストの段階で発見すべきバグがシステムテストで発見されることはあり得ないことになりますが現実はそうなっていません。それにたとえ単体テストで発見すべきバグがすべて単体テスト工程で発見できていたとしても、機能間のインタフェース不一致で発生するバグをCEGTestが生成したデシジョンテーブルでは見逃す場合があります。OR条件の中間ノードでインタフェース不一致でどちらか一方の入力の真を検知できないバグを検出することができないデシジョンテーブルが生成されるのです。
さらに現実の実装方法が、システムテストで使用する原因結果グラフで設けた中間ノードのあり方と常に同じであるという保証はどこにもありません。その意味で「中間ノードが観測可能である」ということが意味をなさない場合があり得ます。またプログラマが仕様を誤解して実装してしまった場合も同じく意味をなしません。例えばAND条件とすべきところをOR条件でコーディングしてしまったなどのバグを検出することができないデシジョンテーブルが生成される場合もあります。
CEGTestは原因結果グラフを描く上ではとても役に立ちます。簡単に原因結果グラフを描くことができるフリーの描画ソフトとして活用することが実用的な使い方だと思います。
例題の仕様
例題は、就業可能な最低就業年齢を判定する問題です。最低就業年齢は次の仕様で決定されます。
1. 使用者が、労働者として就業させることが可能な最低年齢は、満15歳に達した日以後の最初の3月31日が経過した者（義務教育終了者）である（労働基準法56条）。
2. 最低年齢に達しない者は労働基準法上「児童」と称され、原則として就業させることはできないが、例外として次の事業については行政官庁の許可を受けて使用することができる。
3. 行政官庁の許可を受けるには、児童の年齢証明書、児童の就学に差し支えがないことを証明する学校長の証明書、および親権者または後見人の同意書を様式第1号の使用許可申請書に添えて労働基準監督署に提出しなければならない（年少則1条）。
4. 使用者は、使用する満18歳未満の者について、その年齢を証明する戸籍証明書を事業所に備え付けなくてはならない。また、満15歳に達した以後の3月31が経過しない者を使用する場合、児童の就学に差し支えがないことを証する学校長の証明書および親権者または後見人の同意書を事業場に備え付けなくてはならない（労働基準法57条）。
この仕様をもとに就業可能な年齢であるかを判定する原因結果グラフとCFDを作成してみます。
原因結果グラフ
まず原因結果グラフから作成します。
原因結果グラフを作成するには最初に原因ノードと結果ノードを定義します。
さきにあげた仕様をよく分析し適切な原因ノードを定義する必要があります。必要となる原因ノードには次のものがあります。
(1) 満18以上
(2) 満16歳以上～18歳未満
(3) 満15歳
(4) 満15歳未満
(5) 今日が3月30日以前
(6) 児童の年齢証明書を提出
(7) 学校長の証明書を労基署に提出
(8) 学校長の証明書を事業所に提出
(9) 使用許可申請書を提出
(10)戸籍証明書を提出
(11)親権者がいる
(12)親権者が労基署に提出
(13)親権者が事業所に提出
(14)後見人がいる
(15)後見人が労基署に提出
(16)後見人が事業所に提出
このうち、(5)は年齢が満15歳の場合に児童かどうかを判別するために必要となる原因ノードです。
結果ノードは「就業可能」の１つのみです。
次に原因ノード間の制約を定義します。各年齢のノード間にはONE制約が、親権者と後見人のノード間にはEXCL制約が必要です。EXCL制約とする理由は、満20未満では親権者と後見人のどちらか一方だけが必ず真となること、満20歳以上では親権者と後見人は必ず偽となるからです。
続いて仕様から、原因ノードと結果ノードを結ぶために必要となる中間ノードを定義します。中間ノードは原因結果グラフが作成しやすくなるように必要に応じて定義します。このようにして作成した原因結果グラフを次に示します。
この原因結果グラフをもとにしてデシジョンテーブルを作成することにします。
デシジョンテーブルを作成する際の原則があります。OR条件のノードを真とする場合はどれか１つの入力だけを真とし、他の入力はすべて偽とします。AND条件のノードを偽とする場合はどれか１つの入力のみを偽とし、他の入力はすべて真とします。これはテスト対象が仕様の論理通りに実装されているかを漏れなく確認するために必要なことです。
最初に結果ノードが真となるルールを決定します。まず年齢が18歳以上であれば真となることが分かります。この場合、結果に関係しない入力はすべて偽となるようにします。これは年齢が18歳以上であるだけで無条件に結果が真となることを確認するために論理上は無関係な入力も偽とすることで、仕様の論理と異なる実装が行なわれていた場合にバグを発見しやすくするために必要なことです。
続いて中間ノードの「児童の就業を行政官庁が許可」と「児童の書類を事業所が保有」がともに真となるルールを決定します。これにはいくつかの組み合わせがあるのでそのすべての組み合わせを洗い出します。同様に中間ノードの「満18歳未満で非児童の書類を事業所が保有」が真となるルールを洗い出します。
次に結果ノードが偽となるルールを決定します。これは原因ノードの「満18歳以上」が偽で、中間ノードの「児童の就業を行政官庁が許可」と「児童の書類を事業所が保有」のどちらか一方だけが偽で、中間ノードの「満18歳未満で非児童の書類を事業所が保有」が偽となるルールを決定します。これには多くの組み合わせがあるのでそのすべての組み合わせを洗い出します。このとき、それぞれのルールでは結果ノードが偽となる必要最低限の原因ノードだけを偽とすることが重要です。
このようにして作成したデシジョンテーブルを次に示します。
CFD技法
次に同じ例題にCFD技法を適用してみます。
CFD技法では原因結果グラフと異なり、中間ノードという概念がありません。原因を横に並べ、その間を流れ線でつなぐ形になります。原因は原因結果グラフでの原因ノードと同じです。制約は流れ線の原因との接続で表現します。結果は「就業可」と「就業不可」の２つです。この原因と結果とをどのように流れ線でつなぐかで仕様の論理関係を表すことになります。
この例題は結果が正常系と異常系の２つとなり、CFD技法が最も適用しやすい対象です。作成したCFDを次に示します。
このCFDから作成したデシジョンテーブルを次に示します。
ルールの数が原因結果グラフの１７に対してCFDでは２７と多くなっていますが、これは15歳で児童と15歳未満の児童、親権者がいると後見人がいる、という条件と各書類の未提出の条件の組み合わせを原因結果グラフでは省略しているのに対し、CFDではその組み合わせを網羅していることが理由です。
原因結果グラフでは仕様の実装に近いと考えられる論理構造を把握することができます。このことから結果に影響を与えないと考えられる条件が比較的分かりやすいのですが、CDF技法では仕様の実装がどう行われるかを、描いたCFDから把握することはまず不可能です。
原因結果グラフとCFD技法の比較
原因結果グラフでは非常に複雑な論理関係も表現することができますが、CFD技法ではあまり複雑な論理関係は表現できません。CFD技法でもフラグを使ったりして複雑な論理関係を表現しようとする試みがあるようですが、一般にはほとんど知られていないのが現状のようです。CFD技法のメリットは何と言ってもCFDさえ描ければ流れ線をなぞるだけでデシジョンテーブルの作成が極めて簡単にできるという点です。この点に関しては原因結果グラフではCFD技法と比較すると難しくはありませんがかなり煩雑な作業が必要となります。
テスト技法の習得のしやすさという点ではCFD技法がかなり有利です。原因結果グラフは仕様の論理関係をANDやORで表現したり、制約を使用する必要があり、習得の敷居は高いと言えます。ただ原因結果グラフを使ったことがない人が思っているほど難しいわけではないように感じます。
原因結果グラフでもCFD技法でも最も難しいのが仕様から適切な原因を抽出するということです。今回の例題では書類を労基署と事業所の両方に提出する必要がありますが、最初は原因を書類の有無だけにしてしまうというミスをしてしまいました。原因には「書類を労基署に提出」と「書類を事業所に提出」の両方が必要だと後で気づきました。この仕様から適切な原因を抽出するということができれば、デシジョンテーブルの作成完了までの作業の半分は完了したも同じです。
原因結果グラフでは同時に真となる結果が１つだけの結果ノードが複数ある場合にデシジョンテーブルの作成が容易になります。これはデシジョンテーブル作成時に着目している１つの結果ノードが真となる条件だけを調べればよいからです。その結果ノードが偽となる条件は調べる必要がありません。これに対して結果ノードが１つだけであったり、同時に真となる結果ノードが複数ある場合は、着目している１つの結果ノードが真となる場合と偽となる場合の両方の条件を調べる必要があり煩雑な作業となります。
複数の原因間の論理関係がなく単純な組み合わせだけで異なる結果となる仕様を含む場合では、原因結果グラフでもCFD技法でも扱いが難しくなります。前回の記事で取り上げた「Wordの文字飾り機能をテストする」がその極端な例です。
原因結果グラフとCFD技法を比較した表を次に示します。
原因結果グラフのツール使用について
原因結果グラフにはCEGTestというフリーのツールがあります。CEGTestが生成したこの例題のデシジョンテーブルを次に示します。
このツールのデータは次のURLからテキストファイルとしてダウンロードすることができます。ダウンロードしたテキストファイルをCEGTestのファイルメニューのインポート（CSV)で表示されるテキストボックスにペーストすることで、上で示した原因結果グラフとまったく同じものを生成することができます。
http://sourceforge.jp/projects/pictmaster/docs/data/ja/2/data.txt
ここではこのツールを使用する上での注意点を記します。このツールが公開されているサイトのブログ記事に書かれていますが、CEGTestは「中間ノードが観測可能である」ことを前提としています。このことが何を意味するかというと、ツールが生成したデシジョンテーブルでテストを行なう場合は、事前に単体テストで検出すべきバグがすべて検出されていてバグがない状態となっている必要があるということです。CEGTestで生成されるデシジョンテーブルは、この条件を満たしていないテスト対象ではバグを見逃す可能性があります。さらにこのブログ記事には書かれていませんが、論理関係が機能間にまたがる場合は、その間のインタフェースが正しく実装されている必要があります。インタフェースが正しく実装されていないテスト対象ではバグを見逃す可能性があります。ここまでの条件が満たされているテスト対象がもしあるとすれば、もうCEGTestを使ってテストする必要がないといえるでしょう。
単体テストが充分行なわれていて単体テストで発見すべきバグがすべて単体テスト工程で発見できているのなら、単体テストの段階で発見すべきバグがシステムテストで発見されることはあり得ないことになりますが現実はそうなっていません。それにたとえ単体テストで発見すべきバグがすべて単体テスト工程で発見できていたとしても、機能間のインタフェース不一致で発生するバグをCEGTestが生成したデシジョンテーブルでは見逃す場合があります。OR条件の中間ノードでインタフェース不一致でどちらか一方の入力の真を検知できないバグを検出することができないデシジョンテーブルが生成されるのです。
さらに現実の実装方法が、システムテストで使用する原因結果グラフで設けた中間ノードのあり方と常に同じであるという保証はどこにもありません。その意味で「中間ノードが観測可能である」ということが意味をなさない場合があり得ます。またプログラマが仕様を誤解して実装してしまった場合も同じく意味をなしません。例えばAND条件とすべきところをOR条件でコーディングしてしまったなどのバグを検出することができないデシジョンテーブルが生成される場合もあります。
CEGTestは原因結果グラフを描く上ではとても役に立ちます。簡単に原因結果グラフを描くことができるフリーの描画ソフトとして活用することが実用的な使い方だと思います。
Wordの文字飾り機能をデシジョンテーブルでテストする
Wordにはショートカットメニューから「フォント(F)…」を選択することで次のダイアログが表示され、各種の文字飾りを行なうことができる機能があります。
同時にはONにすることができない文字飾りには次のものがあります。
(1) 取り消し線と二重取り消し線
(2) 上付きと下付き
(3) 浮き出しと浮き彫り
(4) 浮き出しまたは浮き彫りをONにすると影付きと中抜きはOFFになる
(5) 小型英文字とすべて大文字
各種の文字飾りを原因とすると、(1)から(5)の制約はデシジョンテーブルで表現できる論理関係とみることができ、デシジョンテーブルとしてはやや複雑な論理を持つものということができます。この論理を取り込んだデシジョンテーブルを人手で作成することはかなり難しそうです。隠し文字を除いた１０の文字飾り機能の組み合わせは１０２４件になります。この場合、各原因がON/OFFの２値をとるので一般的なデシジョンテーブルの作成方法はExcelを用いて次の通りとなります。
1. 原因の取り消し線について、５１２列がON、残りの５１２列がOFFの行を１０２４列分作成する。
2. 原因の二重取り消し線について、２５６列がON、２５６列がOFFの行を１０２４列分作成する。
（以下同様に細分化していく）
11. 原因のすべて大文字について、ON/OFFの繰り返しを１０２４列分の行を作成する。
12. これで基本のテーブルができたので、次に制約の論理関係によって同時にはONとはならない列だけが残るようにExcelのフィルタ機能を使用して制約に違反する同時にONとなっている列をすべて削除する。
この作業は手間がかかるうえに間違いやすくできれば別の方法で行いたいものです。デシジョンテーブルを分割して作成する方法もありますが、かかる手間はそれほど違わないでしょう。デシジョンテーブルはPictMasterでも作成することができるので、PictMasterを使用してみることにしましょう。
PictMasterのモデルと制約指定を次に示します。８個の制約指定で同時にはONとならない組み合わせを除外しています。
ここで全数テスト、デシジョンテーブル、CFD技法／原因結果グラフの違いをまとめてみます。
全数テストというと、「テストの原則・全数テストは不可能」を思い浮かべる人がいるかもしれませんが、ここでの全数テストとは、ある限定された機能についての全数テストであり、限られた要因の全組み合わせをテストすることを意味しており、全数テストもテスト技法のひとつといえます。例えば、Wordの文字飾り機能が同時にONとはならないといった制約がなかった場合を考えてみましょう。その場合の文字飾り機能のテストは全数テストになります。制約のない全組み合わせのテストは全数テストそのものです。
デシジョンテーブルは全数テストの一種です。全数テストと異なる点は組み合わせに論理関係があるという点です。このことから、組わせることができない組み合わせ＝制約 のある全数テストはデシジョンテーブルということができます。結果に影響を与えないと考えられるルールは削除してテーブルを圧縮することもできますが、そのことによってバグを見逃す可能が常に存在します。特にミッションクリティカルなテストではテーブルを圧縮すべきではありません。
CFD技法と原因結果グラフは、デシジョンテーブルの一種であり、デシジョンテーブルと異なる点は仕様などをもとにすべての異なる結果がテーブルを作成する前にあらかじめ分っているという点です。今回取り上げたWordの文字飾り機能のデシジョンテーブルはPictMasterを使って異なる結果が１６２通りあることが分っていましたが、そうでなければ分りませんでした。このため、このテストにCFD技法や原因結果グラフは使用することはできません。なぜならCFD技法や原因結果グラフではあらかじめどのような異なる結果（アクション）があるかが分っていなければ作成することができないからです。またCFD技法や原因結果グラフではテスト対象が仕様通りの論理構造になっている場合に結果に影響を与えない組み合わせは自動的に削除されてしまうという特徴があります。これがあるためにミッションクリティカルなテスト対象にCFD技法や原因結果グラフを使用することは非常に危険なことです。
正確にいうともうひとつ、原因結果グラフやCFD技法が使用できるには条件があります。それは異なる結果の数が多過ぎないという条件です。今回の文字飾りの機能を原因結果グラフで作成しようとした場合、たとえ事前に異なる結果が１６２通りあることが分っていても作成は事実上不可能でしょう。このテストを行なうデシジョンテーブルを原因結果グラフで作成するには、１０個の原因ノードと１６２個の結果ノードを結ぶグラフを作成する必要があります。そんなことをするぐらいなら最初からデシジョンテーブルを作成するほうがはるかに簡単です。CFD技法でも同じことが言えます
全数テスト、デシジョンテーブル、CFD技法／原因結果グラフの包含関係を下図に示します。
同時にはONにすることができない文字飾りには次のものがあります。
(1) 取り消し線と二重取り消し線
(2) 上付きと下付き
(3) 浮き出しと浮き彫り
(4) 浮き出しまたは浮き彫りをONにすると影付きと中抜きはOFFになる
(5) 小型英文字とすべて大文字
各種の文字飾りを原因とすると、(1)から(5)の制約はデシジョンテーブルで表現できる論理関係とみることができ、デシジョンテーブルとしてはやや複雑な論理を持つものということができます。この論理を取り込んだデシジョンテーブルを人手で作成することはかなり難しそうです。隠し文字を除いた１０の文字飾り機能の組み合わせは１０２４件になります。この場合、各原因がON/OFFの２値をとるので一般的なデシジョンテーブルの作成方法はExcelを用いて次の通りとなります。
1. 原因の取り消し線について、５１２列がON、残りの５１２列がOFFの行を１０２４列分作成する。
2. 原因の二重取り消し線について、２５６列がON、２５６列がOFFの行を１０２４列分作成する。
（以下同様に細分化していく）
11. 原因のすべて大文字について、ON/OFFの繰り返しを１０２４列分の行を作成する。
12. これで基本のテーブルができたので、次に制約の論理関係によって同時にはONとはならない列だけが残るようにExcelのフィルタ機能を使用して制約に違反する同時にONとなっている列をすべて削除する。
この作業は手間がかかるうえに間違いやすくできれば別の方法で行いたいものです。デシジョンテーブルを分割して作成する方法もありますが、かかる手間はそれほど違わないでしょう。デシジョンテーブルはPictMasterでも作成することができるので、PictMasterを使用してみることにしましょう。
PictMasterのモデルと制約指定を次に示します。８個の制約指定で同時にはONとならない組み合わせを除外しています。
ここで全数テスト、デシジョンテーブル、CFD技法／原因結果グラフの違いをまとめてみます。
全数テストというと、「テストの原則・全数テストは不可能」を思い浮かべる人がいるかもしれませんが、ここでの全数テストとは、ある限定された機能についての全数テストであり、限られた要因の全組み合わせをテストすることを意味しており、全数テストもテスト技法のひとつといえます。例えば、Wordの文字飾り機能が同時にONとはならないといった制約がなかった場合を考えてみましょう。その場合の文字飾り機能のテストは全数テストになります。制約のない全組み合わせのテストは全数テストそのものです。
デシジョンテーブルは全数テストの一種です。全数テストと異なる点は組み合わせに論理関係があるという点です。このことから、組わせることができない組み合わせ＝制約 のある全数テストはデシジョンテーブルということができます。結果に影響を与えないと考えられるルールは削除してテーブルを圧縮することもできますが、そのことによってバグを見逃す可能が常に存在します。特にミッションクリティカルなテストではテーブルを圧縮すべきではありません。
CFD技法と原因結果グラフは、デシジョンテーブルの一種であり、デシジョンテーブルと異なる点は仕様などをもとにすべての異なる結果がテーブルを作成する前にあらかじめ分っているという点です。今回取り上げたWordの文字飾り機能のデシジョンテーブルはPictMasterを使って異なる結果が１６２通りあることが分っていましたが、そうでなければ分りませんでした。このため、このテストにCFD技法や原因結果グラフは使用することはできません。なぜならCFD技法や原因結果グラフではあらかじめどのような異なる結果（アクション）があるかが分っていなければ作成することができないからです。またCFD技法や原因結果グラフではテスト対象が仕様通りの論理構造になっている場合に結果に影響を与えない組み合わせは自動的に削除されてしまうという特徴があります。これがあるためにミッションクリティカルなテスト対象にCFD技法や原因結果グラフを使用することは非常に危険なことです。
正確にいうともうひとつ、原因結果グラフやCFD技法が使用できるには条件があります。それは異なる結果の数が多過ぎないという条件です。今回の文字飾りの機能を原因結果グラフで作成しようとした場合、たとえ事前に異なる結果が１６２通りあることが分っていても作成は事実上不可能でしょう。このテストを行なうデシジョンテーブルを原因結果グラフで作成するには、１０個の原因ノードと１６２個の結果ノードを結ぶグラフを作成する必要があります。そんなことをするぐらいなら最初からデシジョンテーブルを作成するほうがはるかに簡単です。CFD技法でも同じことが言えます
全数テスト、デシジョンテーブル、CFD技法／原因結果グラフの包含関係を下図に示します。
PictMaster 5.7.3をリリースしました
PictMaster 5.7.3をリリースしました。
今回のリリースではいくつかの機能改善を盛込んでいます。前バージョンからの変更点は次の通りです。
【機能改善】
・実行ボタンがクリックされた時、PICTがインストールされていることおよびnkf.exeがPICTフォルダ内に存在することをチェックし、存在しない場合エラーメッセージを表示するようにした。
・サブモデル欄でもショートカットメニューが使えるようにした。
・環境設定で「統計情報を表示」と「モデルファイルを表示」が同時に指定された場合、モデルファイルを表示した後で統計情報を表示するようにした。
・環境設定で「カバレッジを指定して生成」を指定した場合、ランダムなシードで生成するようにした。
・環境設定で「指定したシードで生成」を指定した場合、右端の設定情報表示欄に指定したシードの値を表示するようにした。
・将来VBAがVBA8以降にバージョンアップされた場合に起きる可能性のある互換性の問題を回避するようにした。
PictMaster 5.7.3は次のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
今回のリリースではいくつかの機能改善を盛込んでいます。前バージョンからの変更点は次の通りです。
【機能改善】
・実行ボタンがクリックされた時、PICTがインストールされていることおよびnkf.exeがPICTフォルダ内に存在することをチェックし、存在しない場合エラーメッセージを表示するようにした。
・サブモデル欄でもショートカットメニューが使えるようにした。
・環境設定で「統計情報を表示」と「モデルファイルを表示」が同時に指定された場合、モデルファイルを表示した後で統計情報を表示するようにした。
・環境設定で「カバレッジを指定して生成」を指定した場合、ランダムなシードで生成するようにした。
・環境設定で「指定したシードで生成」を指定した場合、右端の設定情報表示欄に指定したシードの値を表示するようにした。
・将来VBAがVBA8以降にバージョンアップされた場合に起きる可能性のある互換性の問題を回避するようにした。
PictMaster 5.7.3は次のサイトからダウンロードすることができます。
http://sourceforge.jp/projects/pictmaster/
開発チームとテストチームが独立していればおのずからＷモデルになる
最近ホットな話題としてＷモデルがあります。Ｗモデルの定義にはいろいろありますが、「テスト工程を上流工程から開始する」という捉え方ができます。Ｗモデルを採用することで期待される効果には、次のものがあるようです。
(1) 後工程で見つかるバグを事前に上流工程で発見することができ、手戻りコストの削減につながる。
(2) システムテスト工程でのバグ件数が減少することで開発期間の短縮が見込める。
(3) 上流工程からテストにかかわることでテストの進め方を把握しやすくなり、テスト準備が容易になる。
(4) 開発側にテストの知見がフィードバックされることにより、ソフトウェアの品質向上につながる。
これらのうち、中でも(4)はＷモデルを採用することで得られる最も有益な効果だと思われます。
Ｗモデルは、英国の大手調査会社オーバムのアナリストであるポール・エルズリッシュが、1993年に発表したのが最初だと言われています。日本においては2000年代の半ば頃から研究や実践の取り組みが盛んになってきたようです。
そのＷモデルですが、「Ｗモデル」という言葉から、あたかも開発とテストが完全に並行して行なわれるような印象を受けますが、実際にはそういうことはありません。Ｗモデルを実践する上で、開発チームとテストチームが独立しているか、それとも同じチームが開発もテストも行なうかで大きな違いが出てきます。本来、Ｗモデルは開発チームとテストチームが独立しているプロジェクトのためのものです。同じチームが開発もテストも行なうプロジェクトでもＷモデルを採用することはできますが、開発チームとテストチームが独立している場合に比較してそのメリットは小さくなります。
Ｗモデルに対する従来のＶモデルがありますが、Ｖモデルという言い方は、開発の各工程とテストの各工程が対応していることを強調するために用いられた言い方です。ここではＶモデルやＷモデルの図形を描くのが面倒なので、単純な直線の工程線の形で表すことにします。そうすると従来のＶモデルは図１で表現できます。ここで線の長さは実際の期間の長さを表しているわけではありませんので気にしないでください。
一方、開発チームとテストチームが独立している場合はＷモデルのメリットを最大限に発揮することが可能となります。この場合のＷモデルを図４に示します。このＷモデルは私たちのチームで採用しているものですので独特な部分があります。一部で重複がありますが、開発工程とテスト工程が並列で進行するプロセスです。
テストの観点分析の結果は開発チームを含めたテストの観点レビューでその正確性と充分性を徹底的にチェックします。テストチームのレビューに開発チームが参加することはとても重要です。これはシステムテストに「グレーボックステスト」の性質を与えるものです。開発チームはシステムの構成を知っているので無駄なテストを指摘することができ、またリスクの大きい部分を指摘することができます。システムテストをグレーボックステストで実施することはテストの効率向上とテスト漏れを防ぐうえで大きな効果があります。その意味で、テストチームは開発チームと密なコミュニケーションをとっておく必要があります。
テストの観点分析が完了したらシステムテスト設計を開始します。開発チームは結合テスト設計、単体テスト設計を担当します。結合テストと単体テストはシステム内部の知識が必要とされるため、テストチームが担当することはできません。
プロセスが並列で進むといっても、単体テストと結合テストに関しては多くの場合テストチームが関与することは難しいと思います。この工程に関してはＷモデルのメリットが半減してしまいます。なかには結合テスト工程をテストチームが関与するケースがあり得るかもしれませんが、あまり多くはないと思います。この単体テストと結合テスト工程に関しては本来のＷモデルの考え方、開発とテストのプロセスが並行して進行するという形態をとることができないという点については、Ｗモデルを扱っている論考ではなぜかどれも言及していないようです。
システムテスト設計はごく小人数で充分です。システムテスト開始までには充分な時間があるからです。システムテスト設計が完了したら次はテスターの訓練です。例えばシステムテスト設計を５人で担当し、テスターを協力会社から１５人採用し、１カ月程度の学習・訓練を実施します。学習・訓練の期間はテスト対象が組み込み機器で専門用語が多く、機能の理解とテスト実施方法を習得してもらうために必要です。テストチームはシステムテストを実施し、開発チームはデバッグに専念します。
大きなプロジェクトでは必然的に開発チームとテストチームが独立することになります。こうした形態はずっと昔からありましたが、それをＷモデルの実践とは言いません。ですが開発チームとテストチームが独立していて、開発工程の上流でテストチームの知見が開発チームへフィードバックされているなら、それはＷモデルの実践と言っていいと思います。冒頭のタイトルはそういう意味でつけました。
(1) 後工程で見つかるバグを事前に上流工程で発見することができ、手戻りコストの削減につながる。
(2) システムテスト工程でのバグ件数が減少することで開発期間の短縮が見込める。
(3) 上流工程からテストにかかわることでテストの進め方を把握しやすくなり、テスト準備が容易になる。
(4) 開発側にテストの知見がフィードバックされることにより、ソフトウェアの品質向上につながる。
これらのうち、中でも(4)はＷモデルを採用することで得られる最も有益な効果だと思われます。
Ｗモデルは、英国の大手調査会社オーバムのアナリストであるポール・エルズリッシュが、1993年に発表したのが最初だと言われています。日本においては2000年代の半ば頃から研究や実践の取り組みが盛んになってきたようです。
そのＷモデルですが、「Ｗモデル」という言葉から、あたかも開発とテストが完全に並行して行なわれるような印象を受けますが、実際にはそういうことはありません。Ｗモデルを実践する上で、開発チームとテストチームが独立しているか、それとも同じチームが開発もテストも行なうかで大きな違いが出てきます。本来、Ｗモデルは開発チームとテストチームが独立しているプロジェクトのためのものです。同じチームが開発もテストも行なうプロジェクトでもＷモデルを採用することはできますが、開発チームとテストチームが独立している場合に比較してそのメリットは小さくなります。
Ｗモデルに対する従来のＶモデルがありますが、Ｖモデルという言い方は、開発の各工程とテストの各工程が対応していることを強調するために用いられた言い方です。ここではＶモデルやＷモデルの図形を描くのが面倒なので、単純な直線の工程線の形で表すことにします。そうすると従来のＶモデルは図１で表現できます。ここで線の長さは実際の期間の長さを表しているわけではありませんので気にしないでください。
一方、開発チームとテストチームが独立している場合はＷモデルのメリットを最大限に発揮することが可能となります。この場合のＷモデルを図４に示します。このＷモデルは私たちのチームで採用しているものですので独特な部分があります。一部で重複がありますが、開発工程とテスト工程が並列で進行するプロセスです。
テストの観点分析の結果は開発チームを含めたテストの観点レビューでその正確性と充分性を徹底的にチェックします。テストチームのレビューに開発チームが参加することはとても重要です。これはシステムテストに「グレーボックステスト」の性質を与えるものです。開発チームはシステムの構成を知っているので無駄なテストを指摘することができ、またリスクの大きい部分を指摘することができます。システムテストをグレーボックステストで実施することはテストの効率向上とテスト漏れを防ぐうえで大きな効果があります。その意味で、テストチームは開発チームと密なコミュニケーションをとっておく必要があります。
テストの観点分析が完了したらシステムテスト設計を開始します。開発チームは結合テスト設計、単体テスト設計を担当します。結合テストと単体テストはシステム内部の知識が必要とされるため、テストチームが担当することはできません。
プロセスが並列で進むといっても、単体テストと結合テストに関しては多くの場合テストチームが関与することは難しいと思います。この工程に関してはＷモデルのメリットが半減してしまいます。なかには結合テスト工程をテストチームが関与するケースがあり得るかもしれませんが、あまり多くはないと思います。この単体テストと結合テスト工程に関しては本来のＷモデルの考え方、開発とテストのプロセスが並行して進行するという形態をとることができないという点については、Ｗモデルを扱っている論考ではなぜかどれも言及していないようです。
システムテスト設計はごく小人数で充分です。システムテスト開始までには充分な時間があるからです。システムテスト設計が完了したら次はテスターの訓練です。例えばシステムテスト設計を５人で担当し、テスターを協力会社から１５人採用し、１カ月程度の学習・訓練を実施します。学習・訓練の期間はテスト対象が組み込み機器で専門用語が多く、機能の理解とテスト実施方法を習得してもらうために必要です。テストチームはシステムテストを実施し、開発チームはデバッグに専念します。
大きなプロジェクトでは必然的に開発チームとテストチームが独立することになります。こうした形態はずっと昔からありましたが、それをＷモデルの実践とは言いません。ですが開発チームとテストチームが独立していて、開発工程の上流でテストチームの知見が開発チームへフィードバックされているなら、それはＷモデルの実践と言っていいと思います。冒頭のタイトルはそういう意味でつけました。