システム開発品質指標と開発完了条件

走り書き。

システム開発プロジェクトにおいて、規模あたりのテスト項目数や、規模あたりのエラー検出数品質指標として設定することがあります。

品質指標のおよそ±20%程度に収まっていればOK、そうでなければNGという見方をします。

ここがよくわかりません。

例えば、品質指標として、テスト項目数10件/KSLOC、エラー検出率0.2件/KSLOC、を設定していたとし、テストの結果、品質指標値通りの結果がでたとしましょう。

つまり、
10Ksのプログラムを書いて、
100項目のテストを行って、
2件のエラーを検出した、と。

これだとピタリと品質指標通りになりますが、これで品質を確保したことになるんでしょうか。

たぶん、なりません。

そもそもこの品質指標が妥当かどうかも怪しいです。

***

「テスト項目」ひとつとっても、その粒度が揃っているのかも怪しいものです。

なんでもいいからテスト項目数を増やそうということになれば、例えば直交表を使いそのマトリクスのセルのひとつひとつをテスト項目としてカウントすれば、100や200のテスト項目は簡単に設定できてしまいます。

また、「同値分割」という考え方を知らずにほぼ意味のない入力パターンをやたら増やしてしまう人もいるかもしれません。

これらのテスト手法、アプローチをまったく理解・確認せずに、単に「テスト項目設定率10件/Ks」を追いかけても何の意味もありません。

***

こんなよくわからない数値(だけ)を追いかけまわすより、

  • テストのアプローチやテストの観点、シテストナリオは十分か
  • 使い倒して、エラーや意図しない振る舞いはなくなったか

を確認したほうがいいと思います。

横軸にテスト項目数をとって、縦軸にエラー検出数をとれば「信頼成長曲線」というグラフができますので、そのグラフで収束傾向にあるか否かを確認できます。

信頼成長曲線のようなグラフにするとよくわかるのですが、上述した品質指標を満たしていても、つまりテスト項目設定率10件/Ks、エラー検出率0.2件/Ksを満たしていても、まだまだバンバンとエラーが発生していることがあります。この状態で「よし!完了!」とはならないですよね。

ところで品質指標については、IPA(独立行政法人 情報処理推進機構)から「ソフトウェア開発データ白書」が毎年発行されていますが、本書にはSLOC(source lines of code)あたりのテスト項目設定率やエラー検出率などが記載されています。確か生産性についてもデータがあったはずです。

これを確認していただけば、(サンプリングされたプロジェクト間で、)指標値にかなりバラツキがあることがわかると思います。

そりゃーそうですよね。規模も特性もメンバーのスキルもユーザーのスキルもテストアプローチも予算も実施方針も開発環境も何もかにも違うわけですから、バラツキがでて当然です。

ですので、こういった数値は「ヨソではこうだった」というデータを集計した参考値でありそれ以上でもそれ以下でもないと思っています。

開発の現場に入っている人はもううんざりするほどわかりきっていると思うのですが、マネージャー層になると途端に理解できなくなる(興味を持てなくなる?)ようです。

品質を高める!リスクをヘッジする!という名目で行っている数多くの施策が、実は品質を低下させ、リスクを増大させ、利益を圧迫し、開発者を消耗させているかもしれません。よーーく見極めましょう。

参考文献

ソフトウェアのテストに関する書籍はいろいろとありますが、最近読んだなかではこの本が一番よかったです。

マイクロソフトのテストエンジニアの方が書いた本です。テストそのものにフォーカスした本ではないのですが、どうやって品質を高めていくのか?についてのアプローチについて大変、刺激をうきけました。

Follow me!