リリース判定基準・テストの実施状況はバグの検出状況も見る

2020年11月18日2022年5月10日リリース判定

リリース判定でのテスト品質ではバグの検出とバグの修正の状況も重要

テストの実施状況としてテストの進捗の次に確認するのは、テストで検出したバグの状況と、見つけたバグの修正の状況です。テストをするとバグがわんさか見つかるというのも困った状況ですが、１つもバグが見つからないというのもまた悩ましいです。　では、どの程度のバグが見つかればいいのでしょうか？

見つかるバグの件数やバグの内容は、テストの量とテストに質とに依存しますし、テスト対象のソフトウエアにバグがどれだけ潜在しているかにも依存します。　このあたりは、テストとバグの悩ましい関係として、別記事に書いていますので、興味のある方はそちらも参照ください。

テストで見つかるバグの状況からテストの品質の善し悪しを判定するために、グータラ親父は見つかるバグの件数と、見つかったバグの内容について注意をしていました。定性的な内容ですが以下のような視点でテストの品質を判断していました。

テストで見つかるバグの件数は正規化した検出率で見ましょう

テストで見つかるバグの件数ですが、絶対的な件数はソフトウエアの規模やテストの規模によって変わってきますので、何かで正規化しないと妥当性が判断できません。　

正規化する分母としてテスト項目数が使えるなら、、検出バグ XX件/ テスト項目 YY項目 で計算されるバグ検出率が使えるので、この値が良いでしょう。　　でテストの実施方法には自動テストと手動テストがありますが、テスト項目数なら両方に使えます。　　ただし、テスト項目数は集計する仕組みが要るので少し手間です。　テストが手動テストが主体ならば、検出バグ XX件/ テスト工数 YY人日　 でバグ検出率を計算しても良いでしょう。　

グータラ親父は、検出バグ XX件/ テスト工数 YY人日 でバグの検出数を見ていました。　これは、全てのソフトウエア開発プロジェクトで、テスト項目数を集計できる仕組みまでは出来上がっていなかったので、どのプロジェクトでも使える手テスト工数を使っていた、というだけの事です。

バグの検出率はテストの中盤で確認します

テストが始まるとバグが見つかりますが、テストの立ち上げ時期はだいたいに於いて、テストの進捗も悪いですし、見つかるバグの件数にもバラつきが出てきます。　

テストの立ち上げ時期は、まだテスト環境が充分に安定していなくて、テスト作業自体が順調に進まない事もあります。　また、その事を見越して、必ず合格するような非常に基本的な動作の確認をテストの立ち上げ時期に集中して実施するように、テスト計画を立てる事もあります。　基本的な動作確認テストで、テスト環境の微調整をしてしまおう、という考えですね。

ですので、グータラ親父は、テスト環境が充分に安定してきて、テストチームもそのソフトウエアのテストに慣れてきた、テストの中盤の頃にバグの検出率を確認していました。

単純に前に比べてどうだったか？

では、バグの検出率から何を判断するのでしょうか？　実は、これと言って良い判断基準はありません。　バグの検出数は、元になっているソースコードに潜在するバグの数やテストの品質に大きく左右されるので、この値が正解としうのは存在しません。　　では、グータラ親父は何のためにバグの検出率なんて確認していたのでしょう？

ソースコードの品質とテストの品質が同じ程度なら、バグ検出率も同じ程度の値になるはずです。　ですので、以前の類似の開発と比較して、今回のソフトウエアについてのバグ検出率が多いか少ないか、を確認していたのです。

日本の組織の場合には、ソフトウエ開発チームもテストチームも、組織があるていど固定されている場合が多いです。　長年多くのソフトウエアの品質を見ていると、各々の開発チームやテストチームの力量が、なんとなく判ってきます。　この開発チームならシステムテストの開始時期までにこの程度まで品質を高めてくるだろうとか、このテストチームならこの程度のバグを見つけ出すだろう、とかの感覚が経験値としてですが判ってきます。

今回のソフトウエアのテストに関して、その経験値ちとだいたい合っていれば、まあテストの品質としても問題無いだろうと、とても大雑把で根拠に乏しいのですが、判断はできます。　

そんないい加減な事で何が判るの？

根拠に乏しいので何とも言えないのですが、バグ検出率が高めの時はたいていの場合、社外から導入したソフトモジュールの品質が悪い場合が多いです。

　購入した機能モジュールだったり、新たにさいようしたオープンソースだったり、出典はいろいろですが、社内で開発した物ではなく、外から初めて持ち込んだソフトウエアがあってその品質が悪いと、バグ検出率が明確に大きくなります。

逆にバグ検出率が低めの時はたいていの場合、テストチームの人員に入れ替わりがあって、熟練したテスト担当者が減っている事が多いです。　

テスト作業も、ソフトウエアの設計/実装と同じく高度な専門技術を必要とする作業です。　いろいろな方式について知識として知るための机上の勉強とともに、何年もの実践で鍛えられるテスト技量というのが、バグ検出力に大きく影響します。　テストチームから熟練のテスト担当者が減っていると、いくら過去のテスト経験を活用していたも、バグの検出率が低下します。

テストの品質を判断するという目的に関して言えば、後者のテストチームからの熟練担当者の減少は、テストの品質に大きく影響してくるので、リリース判定においてはテストの内容まで立ち入って、注意深く確認する必要がでてきます。

見つかったバグの内容はテストの終盤で確認します

検出したバグの件数とともに、見つかったバグの内容についても確認しますが、こちらは主にテストの終盤での確認が主体です。　テストの終盤になると、発生条件が複雑だったり、発生頻度が低かったりするような、安定性に関するバグが見つかって来るようになります。

これらの安定性に関するバグは、テストの中盤まではあまり目立ちません。　中盤までは、正常機能の実行に関するバグや、大規模動作環境でのバグなど、比較的見つかり易いバグが多数見つかります。　それらのバグが多い状況ではシステムが安定稼働しない事が多いです。　そのため、様々な条件での動作や複数の処理を競合させた時の動作などのテストが、充分に実施できないので、安定性に関するバグは見つかり難いです。

テストも終盤になって、一通りのバグが見つかり修正されてくると、システムは安定稼働する様になります。　この状態になｔってくると、競合系や高負荷を掛けた状態での長期稼働などの、安定性を確認するテストが本格化し、そのテストで見つかるバグが目立つようになります。

テストの終盤に安定性に関するバグが少ないなら要注意

見方を変えると、テストの終盤になって安定性に関するバグが余り見つかっていないと、テストに何か問題が発生しているかも知れないので、要注意です。

テストが終盤に差し掛かったいるのに、まだ安定性を確認するテストが充分にできる程にソフトウエアの品質が良くなっていないのか、テスト設計に安定性を確認するテスト項目が不足しているかのどちらかが起きています。

前者なら、バグの件数や心理アド成長曲線による潜在バグ数の推定などでも品質不足の状況が見えてきているでしょうから、問題を見落とすリスクは低いです。

しかし後者のテスト設計の問題は他の指標からは見つけにくい事ですので、ここで検出する必要があります。　具体的にはテストの設計書のレベルで安定性に関するテスト項目が充分に考慮されているか、まで遡った確認が必要です。