最近、直交表をソフトウェアテストに応用する事に少し関心がある。ただし個人的には昔から、それに関係する品質工学などをある程度知っていたし、社外の知り合いとの会合などでも話題となっていた。そのため、少しさらに身近になった程度の意識しか無い。自分自身が使う訳ではないが、、、。
ここでは、そんな経緯から、直交表によるソフトウェアテストに関する教育や実践での問題を考えてみたい。
まず直交表で代表的なHAYST法に関して、以下のJaSST(ジャスト)での論文などが参考になる。
http://www.jasst.jp/jasst05w/jasst05w.html
http://www.jasst.jp/jasst04/jasst04.html
での以下のドキュメント。
http://www.jasst.jp/jasst05w/pdf/S4-1.pdf
http://www.jasst.jp/jasst04/pdf/B1ap.pdf
http://www.jasst.jp/jasst04/pdf/B1ah.pdf
他に、雑誌「ソフトウェア・テスト PRESS Vol.2」でも取り上げられている。
ちなみに、こんなブログもある。
http://fnya.cocolog-nifty.com/blog/2006/09/__54af.html
また、直交表のテスト項目生成のバックグラウンドを知る為には、品質工学とか”タグチメソッド”を知っていた方がよい。ちなみに品質工学会のページは以下。ただし後述するように、品質工学とかの勉強が、直交表のテスト項目生成の理解の”諸刃の剣”になりかねないので注意。
では、本題の教育や実践での問題。
１）田口先生の話が分かりにくい。
今まで、田口先生自らが講演される会合に２回ほど参加した事がある。どちらもソフトウェア関連の会議とかフォーラム。タグチメソッドに関する話なのだが、色んな事例に話が飛び理解に苦しんでしまう。また、ソフトウェアテストの応用となると、（自分の例では）田口先生から直接聞いた事がない。
田口先生の話し方は、タグチメッソッド自体、（特に日本では）理解してもらえなかった事への反論がある為かもしれない。そのせいもあって、今すぐにでもソフトウェアテストへ利用したい立場で話を聞こうとすると、拍子抜けになると思われる。（話自体は、結構面白い。念のため。）
２）タグチメソッドでのSNや機能ばらつきとのギャップ。
品質工学とかの勉強が”諸刃の剣”となる、代表の一つがSN。そして、機能ばらつき。田口先生も言うように、タグチメソッドでの基本的な考えは、機能の悪さは気にせずにばらつきを最小化すること。そして入力等を信号と考え、分散などによりSN比を算出する。
タグチメソッドの考えを知れば知るほど、ソフトウェアへの応用＝直交表のテスト項目生成がすんなりと頭に入らない。そもそも出力が数値化できないと行けないのではとか、ソフトウェアでのばらつきって何だろうかと悩んでしまう。
直交表のテスト項目生成の推進派は、タグチメソッドでのSN比なりノイズを外乱要因とするようだが、数値化との関係で少し理解に苦しむ時がある。
また、それと関連して、直交表のテスト項目生成で因子にOn/Offのような状態を選ぶ事があるが、そこが少し理解しにくい。特にOn/Offのような因子が複数出てくると、タグチメソッドでの数値化とどんどん乖離して行くような気がしてしまう。
３）直交表のテスト項目生成推進派から時々話の出る品質用語。
直交表のテスト項目生成の推進派には、タグチメソッドでのSN比等の理解もそうであるが、そもそも品質に関する理解度が深い。分散とかσの理解は、当然である。
逆に、ソフトウェアテスト系の人には、品質での分散とかσに馴染みが無い人が多い。
時として悲劇が発生するのは、直交表のテスト項目生成推進派が（専門家ぶりをひけびらかす為に）分散とかσなどを意味も無く使うとき。ソフトウェアテスト系の人に統計的などの基礎が無いと、話がかみ合わない。（ほんとは、ソフトウェアのテストの設計者にはそんな素養が必要だと管理職が分かり、必要なら教育課程を用意するなどが必要なのだが。）
4)直交表のテスト項目生成推進派の大きなサイズの直交表。
直交表のテスト項目生成の推進者からは、L６４とかL１２８の話がすぐ出る。ツールが自動的に生成するので、生成時間を気にしなければ、サイズはあまり気にならない。
逆に、タグチメソッドを多少かじった人にとっては、普段利用するよりもサイズが格段に大きいので、結構抵抗が出てしまう。
また、直交表のテスト項目生成の推進者の作成を見ていると、因子（水準）をどんどん列挙し、一挙に直交表にまとめるように思える時がある。タグチメソッドでは、各因子を結構吟味する様に思えるので、そのギャップに驚いてしまう。
直交表のテスト項目生成の推進者からは、更に数の多い因子への対応法の話が出る。つまり、そのままだとより大きなサイズの直交表を小さなサイズの表にする手法の話。頭では理解できるものの、上記の抵抗感と同様にふと疑問が湧いてしまう。
抵抗感は何かと以前から考えていたが、”直交性”が保てるかとの疑問かもと思うようになった。”直交性”は相関の逆数で、大きければ大きいほど直交表としてはいいと言える。ただし、具体的な算出方法が思いつかない。２つの因子で、各因子の水準が数値なら出来なくはない。が、因子が増えると計算が面倒。まして、水準が離散的とかOn/Offのようなケースをどう考えたらいいのか？？？
５）ソフトウェアテストの設計者のスキル。
既述の３）での品質の話にも関連するが、ソフトウェアテストの設計者が品質やソフトウェア設計の経験が無いという事が少なくない。そのため直交表のテスト項目生成の勉強を実際のテストに生かす時に、テスト全体の中での位置づけが分かっていない。
ソフトウエア開発のVモデルはもちろん、スパイラルとかアジャイルモデルも理解しておくべきと考える。念のためだが、アジャイルモデル自体はモデルではなく、雰囲気とか、高レベルの人は各アジャイルでの手法の違いの理解と考えてほしい。その辺りの知識が無い事が多い。
直交表のテスト項目生成の学習者はテスターであることも少なくなく、ソフトウェア開発のどのフェースでのソフトウェアテストに利用するかの方針めいた事に無頓着な事が少なくない。その場合、直交表のテスト項目生成の学習で終わったり、有効的な活用にならない事がある。
直交表のテスト項目生成の推進者からは、各テストフェーズでの利用の話は出る。が、製品のソフトウェアテストでトータル的に直交表のテスト項目生成を利用したケースは、事例としてあまり発表されているように思えない。本件は、事例発表を含め今後の課題かもしれない。
６）直交表のテスト項目生成を救世主・絶対視する人達の存在。
直交表のテスト項目生成の推進者がそうだとは思わないが、直交表でテスト件数が相当減るとか品質が上がると思っている人達がいる。従来のテストを行う事自体を否定する事すらある。
MBAでの新経営手法の一つとでも勘違いしている人もいるように思える。少なくとも、MBAでの新経営手法と同様な扱いと思える時があるようである。
そうなったら、従来のテストとの併用とかテストのどのフェーズで利用するかなどの細部検討がなおざりになってしまう。
個人的には、最近になって騒ぐ管理職は上記の類かもしれないので、要注意といった所に思えてならない。
直交表によるテスト項目生成が、ソフトウェアテストの関係者に浸透しつつある。直交表がテスト設計者やテスターの生産性に寄与する為にはどうすべきが考える事が必要な時期かと思う。
