IoTとAI、ビッグデータ時代のソフトウェアテスト（2）

ソフトウェアテストのコストと品質（後編）―現場と「上」で一緒に考える（2/6 ページ）

公開 2017年01月23日 09時00分

更新 2017年04月05日 12時31分

著者

五味弘

[TechFactory]

印刷する連載新着通知を受け取る

問題2 テストの完了基準と網羅基準

　原則2の「完全なテストは不可能」から、テストの完了基準を設ける必要が生じるが、これも難しい問題である。（i）プログラム規模当たりのテストケース数（テスト密度）が一定以上になれば完了させる基準や（ii）バグ曲線（信頼度成長曲線）によるバグの発見状況から残存バグ数を推測して、一定以下になればテストを完了させる方法、さらに計画したお金を使い切るまでテストをするという方法もあるが、全てオカルト的な完了基準である（*2）。

図3. 信頼度成長曲線（バグ曲線）

　これらに対して科学的な完了基準として、何らかの網羅基準を科学的に設定し、ある網羅率に達したときに完了とするものがある。「網羅基準」という言葉を聞くと小難しい話のように聞こえるが、要するにどれだけカバーしたかである。例えば、網羅基準には「全てのプログラムコードを1回はテストした」や「2個の入力組み合わせを1回以上はテストした」などの基準がある。テストというと、どうしても100％のカバーを目指したくなるが、コスト的に見てどう勘案すべきかという別の問題も浮上する。

　*2　なぜ（i）のテスト密度がオカルト的な完了基準かと言うと、問題はテストの密度ではなくテストの内容だからである。（ii）のバグ曲線がまやかしである理由は、今までのバグの発見具合は確かに過去の統計に従っていたかもしれないが、この特定の1個のプロジェクトがそれに従うとは限らないからである。しかしこのような統計的詐欺テクニックを使えば、一瞬、科学的に思えて、ユーザーへの説得力が増すところがミソである。（iii）の使えるお金を完了基準にするのは現実的であるが科学的ではない。

とあるテスト現場より（2）

A：「先輩、もうテストを止めたいです……」

B：「いや、まだ100万円分が残っている」

問題3. テストの定量的計測

　ソフトウェアテストのコストと効果は、定量的に計測する必要がある。計測してこそテストの評価ができ、制御もできる。「上から目線」ならば、来年度の全社目標の1つにもできる。しかし計測は困難な問題である。コストや効果をどのように定量的に扱うかという問題から、テスト環境（テスト技術者のスキルや作成環境、実行環境など）をどうするかなど、面倒な問題が山積みされている。

　計測は開発現場では面倒なのでやりたくないものだが、上から目線では会社のベンチマークにもなるのでぜひとも実行したいものである。ここでも両者のせめぎ合いがあるが、負けるのは開発現場である。

　どうして勝ち負けの話になるかというと、上から言われてコストをかけて計測したデータは大抵、開発現場に下りてこないからである。現世（現場）の利益になっていないのだ。言い方を変えれば、計測こそが開発現場と上から目線で解決する最初の問題である。

とあるテスト現場より（3）

A：「先輩、コストの測定単位は人月ですか？それともお金の円ですか」

B：「もちろん人月だよ」

A：「先輩、品質の測定単位はバグ密度でいいですか」

B：「部長に怒られた回数だよ」

次ページへ非機能要求のテスト

印刷する

IoTとAI、ビッグデータ時代のソフトウェアテスト

言うまでもなくソフトウェアテストは重要だが、IoTやAIなどの新しい概念によってソフトウェア自体の在り方が変わりつつある中、旧来からのテストを踏襲するだけでは成果は得られない。新時代のソフトウェアテストについて、考察する。

連載新着通知を受け取る

この連載の記事をもっと見る

この記事の著者

五味弘

OKI（沖電気工業）シニアスペシャリスト、エバンジェリスト。博士（工学）。ソフトウエアの開発支援・教育に従事。電子情報振興協会（JEITA）専門委員会の委員長や情報処理振興機構（IPA/SEC）などの委員多数。三重大学などの非常勤講師も務める。エンタープライズ系と組み込み系におけるソフトウエア開発の知見融合が関心事。共著書に『定量的品質予測のススメ』（オーム社、2008年）、『プログラミング言語論』（コロナ社、2008年）などがある。