システム開発における品質指標と完了条件などについて思うこと

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

走り書き。

システム開発プロジェクトにおいて、テスト項目設定率○件/Ks(分母のKsとは書いたプログラムの「行数」。ファンクションポイントなどを用いる場合もある。ここではなんでもいいです)や、エラー検出率○件/Ks(以下同じ)を品質指標として設定する(される?)ことがあるのですが、システム開発をよくわかっていない方に限って、このような品質指標だけに頼りきろうとします。

品質指標のだいたい±20%程度に収まっていれば安心するらしい。反対に収まっていなければダメだと思うらしい。

ここがよくわからない。

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

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

これだとピタリと品質指標通りになりますが、これで品質を確保したことになるんでしょうか。
たぶん、ならない。厳密に言えば「わからない」。

品質指標というのは「設定した品質指標(そもそもこの品質指標が妥当かどうかも怪しい)と照らし合わせて、許容範囲内であれば一応OKということにしましょう」という、時間も予算も有限であるシステム開発プロジェクトの約束事の”ひとつ”にすぎないと思っています。

そもそも(どこからかもってきた)品質指標が、今行っているシステム開発にとって有効妥当な値かどうかはわかりません。

また「テスト項目」ひとつとっても、その粒度が揃っているのかも怪しい。なんでもいいからテスト項目数を増やそうということになれば、例えば直交表を使いそのマトリクスのセルのひとつひとつをテスト項目としてカウントすれば、100や200のテスト項目は簡単に設定できてしまいます。また、「同値分割」という考え方を知らずにほぼ意味のない入力パターンをやたら増やしてしまう人もいるかもしれません。

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

まぁ、そこ(お膳立てされた数値)でしか評価できないのかもしれませんが・・・

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

  • テスト計画(結果としての指標値ではなく)の中身(アプローチやテストの観点、シナリオなど)を確認すること
  • 使って使って使い倒して、エラー(や意図しない振る舞い)がでなくなっていること

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

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

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

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

これを確認していただけば、(サンプリングされたプロジェクト間で、)指標値にかなりバラツキがあることがわかると思います。そりゃーそうですよね。規模も特性もメンバーのスキルもユーザーのスキルもテストアプローチも予算も実施方針も開発環境も何もかにも違うわけですから、バラツキがでて当然です。

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

ここで書いたことは、開発の現場に入っている人はもううんざりするほどわかりきっていると思うのですが、マネージャー層になると途端に理解できなくなる(興味を持てなくなる?)ようです。まー、そもそもステップ数で測ろうとすること自体「?」なんですけどね。

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

参考文献

テストって本当に難しくって、漫然とノープランでやってもほとんど意味ありません。ソフトウェアのテストに関する書籍はいろいろとありますが、最近読んだなかではこの本が一番よかったです。


もう一冊。マイクロソフトのテストエンジニアの方が書いた本です。テストそのものにフォーカスした本ではないのですが、どうやって品質を高めていくのか、担保するのかという観点では非常にタメになります。

 

 

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

カテゴリーIT