システムテストの品質分析その３

プロジェクトの状況

このプロジェクトでの開発もシステムテストの工程に入り、試験も順調に消化している。試験の消化とともに、不具合も検出されているが、試験の項目消化がすすんでも、不具合が検出される割合が低い。

これはどういうことか？ということで品質分析を行った。その1、その2でその話をして、今回はその結論をプロジェクトとしてまとめた。

システムテストの品質分析結果

①システムテストの試験項目書の内容・数について

試験項目書は、数の観点では試験密度を超過している状況なので、項目書の数には不足はない。内容・質の観点では、試験項目書は設計書から作られていて、システムテストで実施する試験の観点としては問題はなかった。

→　①の結論：試験項目書については、品質として問題はない。

②検出されている不具合からの分析

改造規模の大きい順に並べた上位10件で、試験密度の比較、不具合の検出数・密度の比較を行った。これらについては、今回のプロジェクトで、新しく取り入れた機能A、機能B、機能Cで不具合の検出に偏りが見られた。機能A > 機能B > 機能C　の順で開発規模が大きいが、不具合の検出数は、機能B > 機能A > 機能C　だった。

→②の結論：不具合の検出数に偏りはあるが、新しい機能で不具合が検出されていて、全体的な傾向としては問題はない。

③PB曲線のもとになった不具合検出密度について

不具合検出数が計画値よりも少なかったので、システムテストの試験項目不足なのでは？という疑いを持った。しかし、テスト項目書は正しい観点で作られていて、試験内容に不足はないと考えている。バグ密度が大きくアンダーになった理由は、指標値の設定が高すぎたのではないか？という推測を行い、試験結果から最初から高かったと結論付けた。

④システムテストで発見されると予測した不具合件数の妥当性について

もし、品質が良いプログラムであれば、予測した不具合件数通りには、不具合が検出されない。今回のケースでは、指標値として使った不具合件数が間違っていたと判断はした。

しかし、品質が良いと判断するには材料が不足しているのと、この先の開発工程で品質が良かったかどうかはわかることである。

※後日追記

品質が良いと判断した結果は間違っていなかった。後の工程でも不具合の検出が大幅に少なくなっており、上流工程にて不具合を検出したため、と考えられる。