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月 6日 (水)

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

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

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

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

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

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

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

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

2007年3月10日 (土)

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月12日 (月)

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

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

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

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

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


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

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

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

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

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


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

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

2007年1月31日 (水)

ブログサーフィン サイボウズやマイクロソフト

時々、サイボウズ・ラボのブログは読んでいるが、一昨日のヨードンさんの話に触発されて、ブログをいくつか読んでみた。

サイボウズは、ラボ以外にもいくつかブログがあった。求人のコーナーには品質管理の人の書き込みもあったりして、ちょっと面白かった。ネタ(?)ごとにユーザ数が判明する。

個人的には、「社内ソーシャルウェア?」での、法務部知財担当のタグクラウドが面白かった。社内の関心事、社内特定分野での関心事の程度を技術的に計測する解決方法の提示でもある。なんか、色んなものに応用できそうで、少しわくわく。


で、もう一つは直交表関係。PICTというマイクロソフトのツールが、あるコミュニティで多少話題となったので、少し調査。すると、マイクロソフトのMSDNのブログに辿り着いた。まだちゃんと読んで無いけど、結構掘り下げているように思う。

どうも、マイクロソフトと聞いて、敬遠したかったが情報収集としてはいいのかも。敬遠したいと思ったのは、そんだけ直交表使ってあの品質じゃね~との思い。ただし、飲み会などで言うと、それでもマイクロソフトの検証体制はピカイチとの話も少なくない。うーーん。

Bloglinesにいくつかのブログを登録しているが、今日見て面白かったものを追加したり、Bloglinesでの購読見直しもやらないといけない。いま少し購読数が多くて、量が半端でなくなった。(歳のせいか、件数多いと目や頭が疲れてしまう。)

1月 31, 2007 ソフトウェア, テクノロジー, パソコン・インターネット, 技術, 直交表, 科学・技術, 科学技術 | | コメント (0) | トラックバック (0)

2007年1月18日 (木)

マイリストの「ソフトウェアテストにおける直交表やAll-pair法の利用」を更新

マイリストの、「ソフトウェアテストにおける直交表やAll-pair法の利用」を更新しました。

大きな変更は以下です。
・自明と書いた部分を補足
・図でHAYST法をタグチメソッドからの派生としていたが、実験計画法からの派生へ
・L18の水準組み合わせを訂正
・直交表の例でのLauncharを紙サイズへ。またその表での間違いを訂正。
・その他。誤字脱字も。

コメントやトラックバック大歓迎です。承認制ですが、勧誘の類でなければ反映します。また、普段のハンドルネーム外を含む匿名でも構いません(気にしません)。

1月 18, 2007 ソフトウェア, プロジェクトマネジメント, プロジェクト管理, 品質, 技術, 直交表, 科学, 科学・技術, 科学技術 | | コメント (0) | トラックバック (0)

2006年12月29日 (金)

AmazonでSPSSでの分散分析の本を注文

ここ2,3ヶ月、ソフトウェアでの直交表利用をちょっと考えている。で、ここ1月ほどが、統計での分散分析も少し勉強。というか、統計ソフトのSPSSでの分析方法が良く分からない。(大抵は回帰分析での利用なので。)

この類の本は、大きな本屋さんではいくつか棚にある。そこで他に関連する見ておきたい本もあったので、、帰宅途中の有燐堂に行ってみた。店員さんに聞いても無いとの事。藤沢店に在庫が有るようだけど、今からそのためだけに行く気はしない。

結局Amazon経由で注文。計3冊。他にちょっとグラフ作成でよく分からないところもあったので。

なお、SPSSで本格的な分散分析のためには、「Advanced Models」を買う必要がある。うーん、金が無い。 まっ勉強は、「Advanced Models」を含めてやっておくけど、検討している事項は「Advanced Models」なしでまとめたい。検討している事項は、ソフトウェアテスト結果の分析。繰り返しの場合が、ほんとは「Advanced Models」が必要。なお、根本的に分散分析まで一生懸命やる必要があるかは疑問ではあるんだけど。(論理的な検討はしておくべきとの判断。)

うーん、冬休みの宿題になってしまった。

12月 29, 2006 ソフトウェア, パソコン・インターネット, 書籍・雑誌, 直交表, 科学, 科学・技術 | | コメント (0) | トラックバック (0)

2006年12月 3日 (日)

マイリストに「ソフトウェアテストにおける直交表やAll-pair法の利用」をアップ

やっと、「ソフトウェアテストにおける直交表やAll-pair法の利用」について、まとめることが出来たので、マイリストにアップしました。

何年か前からタグチメソッドのソフトウェアへの応用への感心が無くはなかったので、まとめてみました。ソフトウェアにおける直交表の利用での問題点を書くとともに、提言も書いてみました。

問題点の記述では、直交表に携わっている人達(色んな会合で私がお世話になっている人達を含みます)には、ちょっと挑発的な記載もあるかもしれません。これから、ソフトウェアテストが良い方向になればとの思いからですので、了解ください。

なお、ソフトウェアテストの専門家と言うほどでもないので勘違い等があるかもしれません。

意見や指摘等は、トラックバックなりコメントでください。許可制にしているので、反映までにちょっと時間かかるかもしれませんが、反論とかでも掲示する予定です。(さすがに、勧誘目的のトラックバック等は勘弁してくださいネ。)

順次コメント追記したり、マイリストのドキュメントそのものを更新して対応して行きます。(でも他にいろいろ宿題があるので、どれくらい対応できるか多少不安ですが。)

よろしくお願いします。

12月 3, 2006 ソフトウェア, プロジェクトマネジメント, 品質, 技術, 直交表, 科学技術 | | コメント (2) | トラックバック (1)

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)