2009年8月14日 (金)

「JSTQB」の試験対策用ブログ

ひょんな事で発見。「JSTQB回帰試験」という名前。

http://degrade.seesaa.net/

丁寧な作りです。プロフィールを見つけようとしたけど、無いみたいです。

2009年06月09日の記事に関しては、謙虚に受け止めました。

8月 14, 2009 ソフトウェア, 組み合わせテスト | | コメント (0) | トラックバック (0)

2008年3月19日 (水)

ソフトウェアテスト カバレッジ

「ソフトウェアテストの勉強室」での、コードカバレッジの記事。↓

http://softest.cocolog-nifty.com/blog/2008/03/post_7864.html

モディファイドコンディション/デシジョンカバレッジとかは良く知らなかったので、ちょっと勉強になった。「原因結果グラフやデシジョンテーブルなどを利用したテスト設計は、このカバレッジ基準と同等といえる。」って、網羅度として同値ということにもなるのかもしれないけど、良く考えてみたい。

具体的な例で100%の網羅度の例を示したり、強み/弱みが対比されてて面白い。


実は、月曜日の宴会で、”網羅度”が少し話題となった。こっちは、「網羅度って割合で、分子/分母」とか「コードカバレッジ、要件に対するカバレッジ、組合せテストでのカバレッジは、それぞれ意味が違うよ」っと途中まで言ったけど、何か聞く耳持たない人が多かった。うーん、大事な事なんだけどね。

3月 19, 2008 ソフトウェア, 品質, 組み合わせテスト | | コメント (1) | トラックバック (0)

2008年2月18日 (月)

「情報処理」 ”ソフトウェアテストの最新動向”

情報処理学会の会誌「情報処理」2月号の特集は、”ソフトウェアテストの最新動向”。

http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=4-JS8020-JS-Z

以下が最新号のはずなんだけど、今は1月号。
http://www.bookpark.ne.jp/ipsj/index.asp

以下は購入ページだけど、詳しい目次が分かる。
http://fw8.bookpark.ne.jp/cm/ipsj/search.asp?from=Magazine&flag=-1&keyword=Magazine,YM200802

学会誌なので、少し固めの内容。特に並列プログラムのテストとTDDは、そう感じるかもしれない。ただし、具体的なので、分かりやすいと思うんだけど。

なお、テスト/デバッグ技法の効果と効率は、テスト技法の包括的な話。もう少し突っ込んだ話は、松尾谷さん自身の講演なんかで聞くのが良さそうに感じた。

情報処理って、ソフトウェア開発者でも読んでない人が多いんだよな~。まっ、学会誌だから仕方ないというか、それが日本の実力。会社で話題になればラッキーな方だろう。特にお偉いさんが読んで気が付けば、ちょっとソフトウェア品質上がるというか、ソフトウェアテストの体制や技法の見直しなどに結びつくかもしれない。

2月 18, 2008 ソフトウェア, 品質, 直交表, 組み合わせテスト | | コメント (1) | トラックバック (0)

2007年8月 3日 (金)

本「ソフトウェアテスト HAYST法 入門」感想

「ソフトウェアテスト HAYST法 入門」を読んだ。ちょっと時間出来たので、急いで感想を書いとかないと、、、。

この本、ずばり HAYST法の本。このブログ読んでる人は、JaSSTなどでのHAYST法の資料や論文を読んでる人が多いと思うけど、それを詳しく書いたもの。HAYST法以外に、ソフトウェアの肥大化などにも触れているので、ソフトウェアテスト担当の人もそうだけど設計や開発の人にも参考になる。(というか、組み合わせテストって、設計の人も理解しておくべきというのが持論。)

帯=推薦のことばがいい。冒頭が”画期的な本である。”。ソフトウェアテストでは著名な、電気通信大学の西さんによる。推薦のことばでは、”曽呂利新左衛門の褒美のように”なんて書いてあって微笑ましい部分もあるけど、最後は”日本の産業競争力の向上”なんていう少し重いテーマで結んである。

結構丁寧に書かれている。直交表もいくつか記載されているし、用語集とか、脚注も丁寧。まとめや宿題(理由はあるけど解答は記載なし)で、理解度を自己採点できる。コラムがいくつかあり、別視点での見方などが書かれていて、参考になるものが少なくない。

HAYST法では、FV表とかFL表などを使うようだけど、詳しく書かれている。また”連結法”とか”水準集約法”という、直交表のサイズを変更する技法も紹介されている。ほんとは、”連結法”そのものでサイズは変化しないけど。

網羅度そのものの説明(具体的な計算方法)は詳しくないけど、網羅度と品質の目安が書かれていて、個人的には興味深かった。

またペアワイズ法やPICTにも少し触れているので、HAYST法以外に興味ある人も参考になると思う。k-wayテストにも触れている。(もちろん、ペアワイズ法などの方がいいとの考えの人には、多少不満のある記述かな。)

ちなみに、この本、発売日の25日に入手しようとして神奈川の有隣堂に行ったけど、なし。検索サービスで探してもらったけど、引っかからなかった。翌日26日が外出だったので、電車の中で読もうと、横浜のダイヤモンド地下街店で検索してもらったけど、その日もだめ。結局、28日の隅田川の花火大会に行く際にイヤモンド地下街店で買って、電車の中で急いで読んだ。日曜である程度読み終えたんだけど、感想を書く時間が無い。というか、すぐに文章にしたり、キーボードで打ち込めない。こんなのも、老化現象なのかな~。なんてね。

さて、ちょっと不満の部分も書いておかないと、、、。^.^;;

・用語集のFL表とFV表の記述(正確には用語での見出し語)が逆
FL表とFV表って、結構重要なキーワードなので残念。

・FV表の説明がよく分からない
というか、機能分析って、もっと別のやり方がいいというのが個人的な意見。

・どこまでがHAYST法での規定部分なのか、自組織で考えてもいい部分か分かりにくい
上のFV表もそうだけど、HAYST法のHAYST法なる部分がよく分からない、。HAYST法を体系と思えば、全部と言えるけど、全部を実践するのは多分酷。どの部分を自組織の既存のプロセスなり手法を流用できるか考えにくい。つまり、それが無いと、HAYST法をどう自組織に適用するか作戦が描けない。

・”テストファースト”
V字モデルからWモデル(を意識?)で、HAYST法を使うことを”テストファースト”と読んでるけど、XP系の人には違和感あると思う。また、もう少し設計系での利用方法の具体例があるといいなと思った。

・話が発散する部分が所々にある
FV表とFMEAの関連とかバランススコアカードとの連携とか、、、。コラムでの「お客様視点での因子」とか「機能だけを因子にすればいいか」というのも、ちょっと飛躍してると思える。まっ、各自の受け取り方だろうけど。

・実践するには??
直交表とか技法はある程度分かったとして、じゃ実践するにはどうするかが頭をよぎってしまう。そのあたりも書いてあればよかったんだけど。続編につづくなのかな。


と、後の方は個人視点が強い意見も書いてみた。ただし、冒頭で述べたように、組み合わせテストに関係する人には非常に参考になるので、一読してみてはいかがですか?

8月 3, 2007 ソフトウェア, 品質, 書籍・雑誌, 直交表, 組み合わせテスト | | コメント (2) | トラックバック (0)

2007年6月12日 (火)

「AssistAllpair」がPICT生成も対応

表題のように、「AssistAllpair」が「PICT」による生成へも対応した。今日、偶然にも知り合いの人が教えてくれて、早速ダウンロード。既にPICTは動かしていたし、旧版の「AssistAllpair」も動かしていた。そのために、あまり手間もなく動いた。また、こうなって欲しいな~と思うとおりの操作性。結構感激した

「AssistAllpair」のダウンロードは以下。07.05.29公開。

「AssistAllpair」は、そこに書いてあるように、エクセルのアドインで、All-pair法の組み合わせを生成する。今回は、その延長で、PICTの組み合わせケースも生成する。PICTは、マイクロソフトの提供する組み合わせテストケース生成ツール。禁則を構文で記述できるなどが特徴。

操作は、因子と水準の表を作成、その部分を選択状態にして生成を指示する。生成指示の際に、All-pairとPICTのどちらで生成するか指示できる。指示すると、別シートに結果が生成される。

ちなみに、PICT生成では、2つ目の選択セルに禁則構文などを記述しておく。

いや~、ここまで出来ていたら、以前本ブログで書いた「PICTの可視化」は、ちょっとお恥ずかしいくらい。特に禁則までサポートしてもらったので、感激。

明日とかに、AssistAllpairを使って、禁則とかSub-Modelsを含めたちょっと本格的なテストケースを生成してみようと思う。

後は網羅度の計算とか、他の組み合わせテスト生成の構文化などが自分自身の課題かな。後者は、あるコミュニティで話題となっているので、ちょっと何らかの成果が出るといいな~と思っている。

6月 12, 2007 ソフトウェア, 品質, 組み合わせテスト | | コメント (0) | トラックバック (0)

2007年6月10日 (日)

組み合わせテスト 禁則表現

最近、組み合わせテスト系の人たちと”禁則”について話す時があり、結構統一した表現を使うので、ここで書いておく。

よく使うのは、PICTというマイクロソフトのツールが利用している表記方法。ちなみにPICTは、以下からダウンロードできる。

http://download.microsoft.com/download/f/5/5/f55484df-8494-48fa-8dbd-8c6f76cc014b/pict33.msi
(解凍すると、プログラムとマニュアル「PICTHelp.htm」が生成される、ただし、URLは、もしかしたら最新版じゃないかも。)

また、以下がPICTに関する掲示板(英語;MSDN=マイクロソフト運営?)。
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1626664&SiteID=1

例えば、「PICTHelp.htm」での
IF [File system] = "FAT" THEN [Size] <= 4096;
は、 [File system] という因子の水準値が"FAT"だったら、 [Size] という因子の水準値は 4096以下とすることを示している。ちなみに、 [Size] という因子の本来の水準値は、 10, 100, 500, 1000, 5000, 10000, 40000。したがって、"FAT"だったら、 [Size] は10,100,500, 1000のどれかかとなる。(どれになるかは、ツール=PICTに依存する。)


さて、原点に戻り”禁則”とは。禁則は、日本語での行末の改行処理を指すことが多い。組み合わせテストでの禁則は、生成したテストケースでテストできない事、テストを継続するために代わりの処理をすることを指す。処理には、水準値を変更する事がほとんど。テストを行わない場合も含めるが、組み合わせテストを生成する人たちの間では、水準値の変更が基本。

上の例では、当初  [File system] = "FAT"   [Size] = 500 が生成された場合、禁則条件が記載されていたら、そのテストケースの500を10に置き換えてテストする。

で、今まで問題だったのが、それらの禁則を組み合わせの表の上で操作する事が多かったので、他の人が妥当性をチェックしにくい点。また、バッチ的にテストケースを生成しにくかった事も問題。

そこで、多少飛びつく格好になったのが、PICTでの構文。構文に沿って記述すると、曖昧さがなくなる。PICTそのものを利用していなくても、本構文は利用できる。なお、自分の場合は、PICT以外のツール利用の場合は、以下のような記述とする事が多い。

IF [File system] = "FAT" THEN [Size]  =  10;

つまり、禁則時の水準値(ここでは10) を決めている。本案は、一長一短。PICT以外のツールで一旦生成されたテストケースを加工する事になり加工結果がはっきりしているので、組み合わせテストやテスト対象に詳しくなくても加工できる。短所は、網羅度が低くなる点。ただし個人的には、禁則状態で水準をいじる事での網羅度向上は、余り意味が無いと思っている。

今まで組み合わせテストでの禁則でよく例に出されたのが、プリンタでの紙方向(縦、横)と用紙サイズ(A4,B4,A3,,,,)。A3(以上)の場合は、紙方向が縦のみというケース。

IF [用紙サイズ] = "A3" or [用紙サイズ] = "B3" THEN [紙方向]  = "縦";

と記述できる。


本表記で、組み合わせテスト系の人たちと話すケースが多くなってきた。結構便利。

なお、テストケースって、なかなかモデリングが進んでいない。プログラミングはUMLとかが普及しているのに。ちなみに、デザインパターンには、テストパターンがあったような気がするが、ネット等で何種類かあるのかも??

禁則とかで、少しづつテストのモデリング化が進みつつあるように思える。


追記;禁則をイメージ、しかもHAYST法でのそれをイメージするなら、JaSSTの05大阪の以下の資料、P12、P29~32が参考になる。

http://www.jasst.jp/archives/jasst05w/pdf/S4-1.pdf

6月 10, 2007 ソフトウェア, 科学技術, 組み合わせテスト | | コメント (0) | トラックバック (0)

2007年6月 6日 (水)

組み合わせテスト 料理に例えるといい?

今日、雑談してて、組み合わせテストでの、直交表とAll-pair法の違いについて妙案を思いついた。

端的には、「カレーとハヤシの違いくらいかな」。牛肉とかタマネギ、、、、は、それぞれ因子と水準に相当。まったく同じ因子と水準(食材)でも、最終的な料理が違う。まっ、実世界での食材の細部は違うけど。また、カレーとハナシが嫌なら、甘辛カレーとピリ辛カレーの違いにしてもいい。

なお、大体の定説として、2因子の網羅度ならAll-pair法が、より多い因子の網羅度だと直交表が優れている。表生成以外に、長所・短所がそれぞれある。

で、最終的な料理をイメージしないと、いくら食材を組み合わせても意味が無い。組み合わせテストツールを使っていると、面白いから因子と水準を色々組み合わせてみることがある。全然アンバランスな因子と水準でも、ツールの上では気にせずに作業する事が考えられる。それじゃ、あかん。何をテストするのかが最初に無いと、因子・水準の検討は、無意味/効率悪い。

最終的な料理がイメージできれば、他の料理とかその場の会食もイメージしてみればいい。どこを組合せテストとするか、単機能でのテストとするかなどが見えてくる。

特に女性のテスト設計者には、判りやすい例えに利用できるかな。

6月 6, 2007 ソフトウェア, 品質, 直交表, 組み合わせテスト | | コメント (0) | トラックバック (0)

2007年3月10日 (土)

ソフトウェアテスト関連のUSPとかIPC

悩んでいた「All-pair法って直交表を利用しているの?」をネットで調べていたら、途中でUSP(米国特許)が急に出てきた。USP 5831995 「Arrangement for generating command sequences using orthogonal arrays」。特に特許調査しているわけでもないので、アメリカはそうやってちゃんと特許出してるんだ位の気持ちだった。しかも重要な特許かも良く分からないし。(念のためだけど、日本もやってるとこは、ちゃんとやってると思う。)

で、Current US Classを見てみると、714/738:Including test pattern generator、 702/108:TESTING SYSTEM。

おっととと状態。念のためにIPC(国際特許分類)を検索してみたら、以下あたりがこの分野に近いかな。
G06F11/28 305 . . デバッグ手法
G06F11/28 330 . . プログラムの修正,作成
G06F11/28 340 . . プログラムテスト

#誤記とかだったらごめんなさい。

技術は進歩してるんだー、自分が知らないだけと実感した瞬間だった。

3月 10, 2007 ソフトウェア, テクノロジー, 技術, 科学, 科学・技術, 科学技術, 組み合わせテスト | | コメント (0) | トラックバック (0)

All-pair法は直交表を利用している?

ここ1,2週間で悩んでいたのが、「All-pair法って直交表を利用しているの?」ってこと。細かい事考えてたら、どうもそうじゃないのではないかなと思うようになった。しかもAll-pair=pairwiseと固定的に考えるのにも疑問が湧いてきた。

多分分類としては一緒でいいけど、All-pair法でのロジックにはラテン方格などの性質を使ってるか疑問になってきた。

ということで、自分の頭の仲がすっきりしてないので、昔の記事も少し変更。マイリストのドキュメントも少し変更する。ただし、後者は少し時間かかりそう。

ついでに、HAYST法とAll-pair法が直交表利用として同類に扱ってた様なので、そこも修正。

やっぱ色々難しい。

3月 10, 2007 スポーツ, 品質, 直交表, 科学, 科学・技術, 科学技術, 組み合わせテスト | | コメント (0) | トラックバック (0)

2007年3月 3日 (土)

食品添加物の組み合わせテスト

今、フジテレビでやってる番組の「日本全国 そんなんあり?!」というコーナーの話題は、商品添加物。ph調整剤とか、、、。で、それぞれの添加物の是非は分かることが多いが、組み合わせとなるとまだ分からない事が多いとの事。番組では、厚生労働省の見解と紹介していた。

ある意味では、食べ合わせ。→組み合わせテスト。 (へと、ついつい考えが行くのが、少し悲しい。^.^;; テスト専門家じゃないけど、職業病?)

日本で認められている添加物は、800種類ぐらいあるようだ。これを因子・水準でテーブル化できそうなら、組み合わせテスター(組み合わせテスト設計屋さん)の出番になる。種類が多いことや因子という考えが希薄なので、色々工夫はいりそうだが。関連する分野としては、薬品とか、食品メーカーでも活躍の場になるかもしれない。

実験計画法の起こりは、R.A.フィッシャーの農事試験によるのだから、少し回帰する事になるとも言える。ソフトウェアテストでの組み合わせ手法は、ちょっと進化したかなと言えなくも無いので、色々交流すると面白いアイデアが出るかもしれない。

3月 3, 2007 ソフトウェア, テクノロジー, 品質, 映画・テレビ, 直交表, 科学, 科学・技術, 科学技術, 組み合わせテスト | | コメント (0) | トラックバック (1)

2007年2月27日 (火)

組み合わせテストの縮小化

ここ1週間、組み合わせテストでのテスト件数を(強制的に)小さくする事を考えていた。以下のように考えたけど、どうなんだろう? 

ほんとは図とかを付けた方がいいが、少し先にする。また、アイデアの一部は、とあるコミュニティでのまったく別件に関するやり取りも参考にした。感謝。


因子(M個)と水準(M個毎に個数は違う)をノミネートして、All-pair法などでテストケースを生成すると、行方向にN件、横方向はM個の表になる。

「テストケースを小さくする」ということは、MやNを小さくするということ。ただし、基本的に因子M個は減らせない。

となるとNを減らす事になる。なるべく均一に減らす。→N行を並べて、最終的に収めたい行数nへすればよい。

となると、1からNでのn個の乱数を発生させて、その行を該当行とすればよい。

1からNの乱数を発生させて、同一番号が発生したら?? 1つは、そんなに多くないのでそのまま該当行としてよい。大抵は、同一番号の発生によりテストを複数回行う必要は無い。つまり、同一番号の発生をそのまま利用する方法なら、n個ではなくて、n-1個等のテストケースとなる。

同一番号の発生をそのまま利用したくなければ、乱数を余計に発生させる方法がある。他にエクセルなどを利用する場合は、乱数関数とRANK関数を利用すればいい。(RANK関数も、OpenOfficeのCalcで使える。) この場合は、個数nを一定に出来るメリットはある。

この際、テストケースでの表で因子と水準は均一になっておくべきなので、先頭の因子を優先順位1、次の因子を優先順位2などとしてソートした上で、乱数での該当行を有効にするのが必須。またALLPAIRSを使った場合、Don't Care(テストケースでの”~”記号)の部分は、”~”記号を省いた並び替えとなるし、本強制的な縮小後はDon't Careの意味は薄れることになる。

もし、強制的に水準を少なくしたいときで水準に重み付けがある場合は、重みを軽くする方法がある。All-pairなどでは重みを”(5)”などと表記する事があるようだか、それを”(3)”などと記述して生成すればいい。また、重み付け表記でなくて水準をそのまま列挙している場合で同一水準が複数ある場合は、同一かの判断を元に水準値の間引きが可能だ。

更には、因子そのものを削除してしまう方法がある。

水準や因子の削除は、操作系を中心としたテストで利用している場合は抵抗あるだろうけど、自動テストで利用したり操作で何度も同じようにテストしていたら利用できる。自動テストで、ずっと同じ水準値のままでUnitテストする必要は無い。(操作系を中心としたテストでも、この類はやるべきというのが持論だが。)

当然だけど、修正影響を調べるための重要な回帰テストでは、前のテスト件数の行数や因子や水準で調べるのが普通。また水準での重み付けを軽くする部分は自動的な処理が可能だが、水準そのものや因子そのものの削除自動化は難しい。

組み合わせテストでのテスト件数を、テストフェーズやソフトウェアの品質に応じてダイナミックに変更してテストすべきと思っているんだけど、どうなんだろう。その場合は、本方法などでの縮小化は有用だ。また、直交表によるテストケースとAll-pair法によるテストケースに本方式を適用した場合どうなるかも調べたいけど、ちょっと先だろうな。

2月 27, 2007 ソフトウェア, テクノロジー, 品質, 技術, 直交表, 科学・技術, 科学技術, 組み合わせテスト | | コメント (0) | トラックバック (0)

2007年2月18日 (日)

マイリストに「ソフトウェア組み合わせ生成ツール「PICT」の可視化」をアップ

マイリストに、表題のドキュメントをアップした。

All-pair(Pairwise)法によるソフトウェアテストの組み合わせ生成ツールの中での、 Microsoft社による”PICT”と呼ぶツールの可視化。具体的には、表計算ソフトのExcelで因子・水準の設定→結果表示を行なうようにした。ただし、PICTでの基本的な設定への対応のみで、重みづけとか禁則の指定へは対応していない。

Excelのマクロで実装したのには、理由がある。All-Pair法に基づくテストケース生成ツール"ALLPAIRS"利用を支援するExcelアドイン「AssistAllpair」があり、それとの因子・水準の共用を考えたため。矩形領域を指定して実行する操作方法も似せた。

ちなみに「AssistAllpair」は、moonlightさんの作でフリーソフト。"ALLPAIRS"はJames Bachさんの作。ただし、本Excelファイルにはそれらのアドインは含んでいない。

#個人的にはMac使いなので、”PICT”はMacでの画像ファイル形式の代表的な形式名と同一のため組み合わせツールの名称を別にして欲しかった。

PICTと"ALLPAIRS"(/AssistAllpair)をさらっと勉強した事になる。後、組み合わせテスト生成ツールで勉強すべきと思っているのに「 Intelligent Test Case Handler」がありダウンロードまではやったけど、使ってみるのは先になりそう(他が忙しい)。個人的には、「 Intelligent Test Case Handler」のように開発ツールに組み込む方法は、上流設計への利用や自動化と結びつける際のメリットとなると思っている。

2月 18, 2007 ソフトウェア, テクノロジー, 品質, 技術, 科学・技術, 科学技術, 組み合わせテスト | | コメント (0) | トラックバック (0)

2007年2月12日 (月)

網羅度の計算 時間がもったいないんだけど、、

ちょっとした勉強会の関係もあって、All-pairsでのソフトウェアテスト生成を行っている。

ベースとなるツールは以下。Bachさんのページ。(正確にはBachさんのページというよりも、Bachさんのグループのページというのが正確かな。)

http://www.satisfice.com/tools.shtml

実際は、これを利用したツール。ごめん、細部は省略。


で、本ツール自体では禁則指定ができないとか網羅度が出てこない。自分で工夫して追加するというか、後処理が必要だ。個人的には、「そうなんだ」程度に思っていた。ロジックはたいした事ないので。もちろんここでの網羅度は、2因子間の網羅度とか3因子間の網羅度。

ロジックの実装を考えようと思ったが、なんでこんなのが必要なんだと段々不平に。ロジック自体は、エクセルのマクロで実装できる。もしかしたら、OpenOfficeのCalcでも出来るかもしれないが、、。

禁則指定は別として、網羅度。網羅度算出そのものの必要性はわかっている。でも、問題なのは、毎回テストケース生成の度に算出する必要性。因子と水準が膨大な時は、処理時間が馬鹿にならないからだ。更には、グラフィックで見せてくれというケース。実際のテスト開始の頃とか、実際のテストで因子や水準を見直してある程度安定した頃ならいいんだが、毎度計算して欲しいといいケース。

なんか、数字が出るので、それを弄んでいる感じ。そんな毎回の算出よりも、より効率的な組み合わせ手法を考えるとか、テストの効率化を考えるべきなんだけど、、、。

#「4因子の網羅度は?」と言い出したら、よほど専門家か、弄び派のどちらかだろう。まっ、ほぼ後者。


ソフトウェアテストの学術的な進歩と、現場の後進性までついつい考えてしまった。

2月 12, 2007 ソフトウェア, テクノロジー, 直交表, 組み合わせテスト | | コメント (0) | トラックバック (0)

2006年10月12日 (木)

直交表によるソフトウェアテストに関する教育や実践での問題

最近、直交表をソフトウェアテストに応用する事に少し関心がある。ただし個人的には昔から、それに関係する品質工学などをある程度知っていたし、社外の知り合いとの会合などでも話題となっていた。そのため、少しさらに身近になった程度の意識しか無い。自分自身が使う訳ではないが、、、。

ここでは、そんな経緯から、直交表によるソフトウェアテストに関する教育や実践での問題を考えてみたい。


まず直交表で代表的な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://www.amazon.co.jp/%30bd%30d5%30c8%30a6%30a7%30a2%30fb%30c6%30b9%30c8-PRESS-Vol-2/dp/4774125733/sr=8-1/qid=1158284230/ref=sr_1_1?ie=UTF8&s=gateway&tag2=blogamebaj01c-22

ちなみに、こんなブログもある。
http://fnya.cocolog-nifty.com/blog/2006/09/__54af.html

また、直交表のテスト項目生成のバックグラウンドを知る為には、品質工学とか”タグチメソッド”を知っていた方がよい。ちなみに品質工学会のページは以下。ただし後述するように、品質工学とかの勉強が、直交表のテスト項目生成の理解の”諸刃の剣”になりかねないので注意。
http://www.qes.gr.jp/top.html


では、本題の教育や実践での問題。

1)田口先生の話が分かりにくい。
今まで、田口先生自らが講演される会合に2回ほど参加した事がある。どちらもソフトウェア関連の会議とかフォーラム。タグチメソッドに関する話なのだが、色んな事例に話が飛び理解に苦しんでしまう。また、ソフトウェアテストの応用となると、(自分の例では)田口先生から直接聞いた事がない。

田口先生の話し方は、タグチメッソッド自体、(特に日本では)理解してもらえなかった事への反論がある為かもしれない。そのせいもあって、今すぐにでもソフトウェアテストへ利用したい立場で話を聞こうとすると、拍子抜けになると思われる。(話自体は、結構面白い。念のため。)


2)タグチメソッドでのSNや機能ばらつきとのギャップ。
品質工学とかの勉強が”諸刃の剣”となる、代表の一つがSN。そして、機能ばらつき。田口先生も言うように、タグチメソッドでの基本的な考えは、機能の悪さは気にせずにばらつきを最小化すること。そして入力等を信号と考え、分散などによりSN比を算出する。

タグチメソッドの考えを知れば知るほど、ソフトウェアへの応用=直交表のテスト項目生成がすんなりと頭に入らない。そもそも出力が数値化できないと行けないのではとか、ソフトウェアでのばらつきって何だろうかと悩んでしまう。

直交表のテスト項目生成の推進派は、タグチメソッドでのSN比なりノイズを外乱要因とするようだが、数値化との関係で少し理解に苦しむ時がある。

また、それと関連して、直交表のテスト項目生成で因子にOn/Offのような状態を選ぶ事があるが、そこが少し理解しにくい。特にOn/Offのような因子が複数出てくると、タグチメソッドでの数値化とどんどん乖離して行くような気がしてしまう。


3)直交表のテスト項目生成推進派から時々話の出る品質用語。
直交表のテスト項目生成の推進派には、タグチメソッドでのSN比等の理解もそうであるが、そもそも品質に関する理解度が深い。分散とかσの理解は、当然である。

逆に、ソフトウェアテスト系の人には、品質での分散とかσに馴染みが無い人が多い。

時として悲劇が発生するのは、直交表のテスト項目生成推進派が(専門家ぶりをひけびらかす為に)分散とかσなどを意味も無く使うとき。ソフトウェアテスト系の人に統計的などの基礎が無いと、話がかみ合わない。(ほんとは、ソフトウェアのテストの設計者にはそんな素養が必要だと管理職が分かり、必要なら教育課程を用意するなどが必要なのだが。)


4)直交表のテスト項目生成推進派の大きなサイズの直交表。
直交表のテスト項目生成の推進者からは、L64とかL128の話がすぐ出る。ツールが自動的に生成するので、生成時間を気にしなければ、サイズはあまり気にならない。

逆に、タグチメソッドを多少かじった人にとっては、普段利用するよりもサイズが格段に大きいので、結構抵抗が出てしまう。

また、直交表のテスト項目生成の推進者の作成を見ていると、因子(水準)をどんどん列挙し、一挙に直交表にまとめるように思える時がある。タグチメソッドでは、各因子を結構吟味する様に思えるので、そのギャップに驚いてしまう。

直交表のテスト項目生成の推進者からは、更に数の多い因子への対応法の話が出る。つまり、そのままだとより大きなサイズの直交表を小さなサイズの表にする手法の話。頭では理解できるものの、上記の抵抗感と同様にふと疑問が湧いてしまう。

抵抗感は何かと以前から考えていたが、”直交性”が保てるかとの疑問かもと思うようになった。”直交性”は相関の逆数で、大きければ大きいほど直交表としてはいいと言える。ただし、具体的な算出方法が思いつかない。2つの因子で、各因子の水準が数値なら出来なくはない。が、因子が増えると計算が面倒。まして、水準が離散的とかOn/Offのようなケースをどう考えたらいいのか???


5)ソフトウェアテストの設計者のスキル。
既述の3)での品質の話にも関連するが、ソフトウェアテストの設計者が品質やソフトウェア設計の経験が無いという事が少なくない。そのため直交表のテスト項目生成の勉強を実際のテストに生かす時に、テスト全体の中での位置づけが分かっていない。

ソフトウエア開発のVモデルはもちろん、スパイラルとかアジャイルモデルも理解しておくべきと考える。念のためだが、アジャイルモデル自体はモデルではなく、雰囲気とか、高レベルの人は各アジャイルでの手法の違いの理解と考えてほしい。その辺りの知識が無い事が多い。

直交表のテスト項目生成の学習者はテスターであることも少なくなく、ソフトウェア開発のどのフェースでのソフトウェアテストに利用するかの方針めいた事に無頓着な事が少なくない。その場合、直交表のテスト項目生成の学習で終わったり、有効的な活用にならない事がある。

直交表のテスト項目生成の推進者からは、各テストフェーズでの利用の話は出る。が、製品のソフトウェアテストでトータル的に直交表のテスト項目生成を利用したケースは、事例としてあまり発表されているように思えない。本件は、事例発表を含め今後の課題かもしれない。


6)直交表のテスト項目生成を救世主・絶対視する人達の存在。
直交表のテスト項目生成の推進者がそうだとは思わないが、直交表でテスト件数が相当減るとか品質が上がると思っている人達がいる。従来のテストを行う事自体を否定する事すらある。

MBAでの新経営手法の一つとでも勘違いしている人もいるように思える。少なくとも、MBAでの新経営手法と同様な扱いと思える時があるようである。

そうなったら、従来のテストとの併用とかテストのどのフェーズで利用するかなどの細部検討がなおざりになってしまう。

個人的には、最近になって騒ぐ管理職は上記の類かもしれないので、要注意といった所に思えてならない。


直交表によるテスト項目生成が、ソフトウェアテストの関係者に浸透しつつある。直交表がテスト設計者やテスターの生産性に寄与する為にはどうすべきが考える事が必要な時期かと思う。

10月 12, 2006 ソフトウェア, 品質, 直交表, 科学, 科学・技術, 科学技術, 組み合わせテスト | | コメント (2) | トラックバック (1)