幸運にもテスト部隊が独立している場合、彼らは正しくバグを定義しています。たとえばテスト部隊は、テストやチェックを１０００回実施し、バグを摘出します。ソフトウェアやシステムの規模に応じて、回数は増減させるべきですよね？
ここで壁にぶつかります。ソフトウェアの規模はどうやって計るのか？
・ソース行数でいいんじゃない→C/C++とCOBOLで同じでいいの？
・バイナリサイズでいいんじゃない？→C/C++とJavaで同じでいいの？
便宜的に、ソース行数を用いるとして、テストの計画を立てます。
テスト件数目標 ソース総行数１千行あたり、100項目
バグ摘出目標 ソース総行数１千行あたり、10項目
もし経験的に、ソフトウェアの品質が向上したと認められれば、テスト件数目標を下げることができます。これはテストの工数削減となり、コスト削減を意味します。つまり生産性が向上します。
バグ摘出目標は、もっと戦略的に運用しなければなりません。
新機能追加モジュールにおいては、高めに。ユーザからのクレームが多いモジュールにおいても、高めに。戦略的に、と書いたのは、クレーム発生は時差があることと、クレーム＝バグではないからです。
テストの成績は以下のように表せるでしょう。
テスト実施実績 ＸＸＸ項目 (実施率YY%)
バグ摘出件数 ＷＷＷ件 (摘出率VV%)
ここで結果を慎重に分析しなければなりません。バグ摘出が目標を下回る場合、原因はいろいろありそうです。
(a)ソフトウェアの（実装）品質が高かった
(b)バグの摘出が難しかった
(c)見当違いの摘出手法を用いていた
安易に(a),(b)で片付けると、(c)によって漏れたバグが、製品に紛れ込むことになります。
また、
(d)テストがまともに進められないくらい品質が低かった
なんてものもあるでしょう。
これは、テスト項目に相互依存性がある場合顕著になります。あるテストＡを実施するためには別のテストＢがパスしていることが前提となっている場合などです。これをテスト計画の不備と軽く見てはいけないと思います。テスト容易化設計についてまじめに考えるならこの辺をじっくり調べるべきなのだろうと思います。どうせ実装屋さんには関係ない話ですが。
最後にテストにおけるバグに関する暗黙的前提を書いておきます。
・バグは無限に摘出できる(コスト効果を無視すれば)
開発者あるいは実装者は、これらの事情を踏まえて実装や実装の修正に望まなければなりません。
わかりやすい言葉で書けば、「バグのない実装を心がける」というのがいかにばかげているか考え直してください、ということです。
炎上している現場では上で書いた、バグ摘出が目標を下回る状態が常態化しているのではないでしょうか。そのためテストが遅延し、摘出が遅れ、さらにバグ修正も遅れるわけです。つまり(C)や(d)だということです。そこでは本来バグでないものがバグとカウントされています。
そんなことが起きる原因はただひとつ、設計なき実装のように思われます。
・・・とまぁバグ=ソフトウェア故障と決め付けた議論を書いてみました。
コメント