前のブログは、結局まとめると、
大手企業の場合は、テストの目的は、「品質の向上」だが、
ベンチャーの場合は、テストの目的は、「品質のチェック」というケースがある。
|
品質のチェックの場合、結局リリースできる品質かどうかを知りたいのだから、そのチェックレベルにおいて、「バグ ０」というのも、とても有意義なテスト結果である。
っていうことになります。
つまり、いいかえると、ベンチャーの（特にプロダクトの）マネージャーは、時間がないテストの場合、「不具合をたくさん見つけ」てくれたり、「異常系のテストケースに注力すべく、「遷移が存在しない、誤っている」「本来存在しない遷移」「不正な入力に反応」というようにテスト設計方針」といったテストを、行ってほしいのではない気がします。
時間がないのであれば、あくまでも、正常系が通るかどうか、リリースして大丈夫かの品質を知りたいわけです。
つまり、「画面入出力項目に対して、各項目の設定可能項目と設定値の組み合わせをマトリクスにて抽出し」、「最大値／最小値や境界値また異常値を考慮し組み合わせを合理的に少なく」したテストをしてほしいわけです。
そういうテストをしてくれる会社があれば、「うん、値段が合えば、使ってみようかな？」って考えるわけです。
ところが、「画面入出力項目に対して（以下中略）」やる方法では、ほかの異常系のテストに注力する方法にくらべ、バグ数を見つけるという意味であれば、圧倒的に不利です。なんたって、前者は、正常系のテストになってしまうので、まあ、ふつう正常系は、つぶしてくるものですから。
で、バグ数の数字でしか判断できない経営者とかなんかだと、バグが出てこない前者のテストのよさが見抜けないわけです。
さあ、ここで問題です。
実は、上記の文は、
「テスト設計の方針は千差万別」の「テストライブ」でテストを行った方のテスト戦略から、抜き出したものです。
で、そこの参加者が、問題なんですよ！
・日本IBM（テストエンジニア担当）
・NEC （テストエンジニア担当）
・ベリサーブ （テストエンジニア担当）
上の２社は、大手企業です。これは、問題ないです。バグを見つければいいだけです。
でも、ベリサーブは、検証屋さんです！検証屋に期待するのは、プロダクトマネージャーでは、先ほど述べた、品質を知りたい、つまり、「画面入出力項目に対して（以下中略）」というやり方です。でも、経営者に売り込むには、バグを多く見つけなければいけません。ほかの異常系の方策を選んだほうがいいです。
でも、そのやり方を選べば、プロダクトマネージャーや、そーいう関連のコンサルは、「なーんだ、そういうテストじゃあ、使えないな。だったら、「画面入出力項目に対して（以下中略）」みたいな仕様書つくって、パソナの派遣にやらせたほうがいいじゃん」といわれてしまいます。これも、売り上げにつながりません。
ジレンマです。酷過ぎます。どちらの戦略をとっても、だれかの不評を買います。
どっちの戦略をとったのか、興味津々。
それを解説する人も、すごいツッコミになったんでしょうね。
「おお、あくまでも、経営者に売り込みにいく方法をとったかあ、大丈夫か、それで、明日から現場で問題起きないか？」とか、
「おお、現場の人の受けをねらったか、大丈夫なのか、経営者や投資家の歓心を買わなくて、明日の株価とか」「CSKグループだから、大丈夫なんじゃないですか、これが、ホリエモンのライブドアグループならたいへんです。まずは、株価です」とか、ディープなツッコミが・・・入るわけないって(^^;)
| このブログのURL
|この記事のURL
←記事が面白ければクリックをお願いします。1クリックで投票できます。
米ＣＢＳではHallmark Hall of FameのＴＶＭ「Riding the Bus with My Sister」を5月1日放送予定。