プログラム開発の品質評価の内容を聞いていると、「おや？」と思うことが時々あります。
試験密度と故障検出密度
昔ながらのプログラム開発をしていると、まずはウォーターフォールで各工程の品質評価に用いる定量的な目標数値を最初に設定しておきます。
よく使われるのは、プログラム1Ksあたり何件の試験項目を設定するかを表す試験密度、プログラム1Ksあたり何件のバグを検出するかというバグ検出密度の二つです。
例えば単体試験が終わったあとには、実際に設定した試験項目の数、検出したバグの数を目標数値と比較して定量評価を実施します。
また、バグの原因や種類、作り込んだ人の偏り、作り込んだときのプロセスの問題、全工程までで見つけられなかった原因などを元にして定性分析が行われます。
品質評価をするときの心構え
定性分析でありがちなこと、次の工程になんとかして進めるために、上の人に納得してもらうために品質分析資料を作ってしまうことです。こうなると、「バグの件数は指標値を上回っているが網羅的に試験をしているので問題はない」などといった言い訳がたくさん並んだ資料になります。勘の良い上司であれば、本当に大丈夫なのかどうか、指摘を多く受けることになるでしょう。
とても大事なことは、自分自身が本当にこの品質で大丈夫だと思っているのか、不安な点は残っていないか、メンバーの声は聞けているかと言った点です。できるPMほどとても謙虚で心配性です。
コーディングが終わったばかりのプログラムはまるで砂浜にダイヤモンドを撒き散らかしたような状態になっています。このダイヤモンドを単体試験の粒度、結合試験の粒度、総合試験の粒度でダイヤモンドを見つけていき、サービス開始前には全てのダイヤモンドが拾えていることがベストです。
そのためには、砂浜のどこについては試験をしっかりと実施して自信があるか、どこは不安があるかといったことを区画に分けて管理することが大事です。いわゆる品質管理単位と呼べばいいでしょう。
こうやって自分でここはきちんと出来ている、ここは不安だから次工程でこういうアクションを取るということを整然と上司に説明すれば、上司はしっかりと受け止めてくれるでしょう。
単体試験で取るべきバグは結合試験で出るのか？
よく結合試験でたくさんのバグが摘出されて、バグの中身を見たら本当は単体試験で取るべき性格のバグばかりだったということがあります。
このようなときに残された時間も少ないので、ありがちなのは、結合試験で網羅的に試験をして品質を万全にするというセリフです。
単体試験で取るべきバグは結合試験で取れないものが多いです。モジュールの中で使っている関数の仕様でパラメータ5個までしか設定できないので、5個ずつ繰り返すといった実装上の条件は、要件定義書や詳細設計書に書かれていないことが多く、モジュール内部をホワイトボックスにして試験をしないと見つかりません。
結合試験や総合試験でバグがたくさん出てしまったとき、どの工程に戻って品質強化作業をするかはよく考えた方が良いです。単体試験はスタンドアロンのパソコンでできることも多く、数多くのバリエーションをこなすならば単体試験で枯らした方が効率的な場合が多くあります。
コメント