プロジェクトマネジメント　品質分析の観点

この記事は前回からの続きです。プロジェクトのシステムテストフェーズの中で、PB曲線を引いたが、試験の項目消化に伴って、不具合の検出数も増加するのが想定される動きだが、今回のプロジェクトではそうなっていない。そのため、品質分析を行うというお仕事になったので、どのような観点でみていったかをまとめました。

システムテストで品質分析でやったこと

①システムテストの試験項目書の内容・数について、妥当性があるかを確認をする

・実施した理由その１）システムテストの試験項目書が、どのような試験観点で項目を抽出し、試験書として作られているか？を確認した。なぜなら、このプロジェクトで新規・変更点として抽出されるべき改造箇所に対して、適切に試験を実施していなかった場合、不具合は想定通りの数で検出されない。いわゆる、試験観点・項目不足となるからである。また、試験の内容が簡単でも適切に不具合が検出できない。そのため、試験項目書が問題がないかの確認を実施した。

・実施した理由その２）試験項目数に不足があれば、不具合の検出数が少なくなるので、試験項目書の項目数に問題がないかを確認したかったため。結果からいうと、今回設定した指標値に試験項目書密度(件/kstep)があり、この指標値をオーバーするぐらい試験項目書の数は作られていた。そのため、試験項目数については過不足はないと考え、改めて項目書を作って実施したりするような、強化試験は必要ない、という方向で考えた。

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

開発で行った改造規模と、システムテストの機能別に試験項目数を比較し、試験項目密度が問題ないかの確認を行った。改造規模が大きい上位10件に対して、データを集めて分析を行ったところ、今回のプロジェクトで新しく盛り込んだ機能で、不具合検出が多くされていた。全体で見たときに、機能別の不具合密度も算出して確認をしたが、問題がある傾向はみられなかった。

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

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

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

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

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