テストで品質は上がらない

テストではバグを検出することが目的であるが、それが勘違いされて伝わっている場合がある。
「テストではバグが出るのは当たり前」と理解している開発者がいるが、そう思っている人の成果物の品質は非常に悪い。


検出されるバグが多いのが良いか、少ないのが良いのか、と問われたら、私は当然少ない方が良い、と答える。
大抵、バグ検出数には、「目標値:50件±15件」のように、ある程度範囲のある目標値を定め、その範囲内のバグが検出できるよう、テストを実施する場合が多いだろう。
しかしながら、優秀な組織/チームは、その目標値自体を下げても、十分な品質を確保することができる。


ところが、先のように誤解している人が担当した機能は、目標値を大きく超えてもバグが収束しきらないことが多い。
特に、同じ開発者が一貫して担当することが多い詳細設計/実装/単体テストの工程が重要で、その工程内で、品質が十分に向上させられていないモノは、何度テストを実施してもバグが出続け、終いには運用でもその部分でバグが出続ける。


テストは「品質保証」であって、「品質向上」にはならないのである。
テストにかけられる時間は限られているため(さらには、進捗の遅れにより、初めからテスト期間が圧迫されてしまっていることは多い)、根本的に品質の悪いモノは、結局は品質が十分に確保されないままリリースを迎えてしまう。


品質向上のための作業は、設計や実装と合わせて「作り込む」ものであり、開発者が行うべき役割であると考えることが必要だろう。

私は、自分が実装するモノは、結合テスト以降でもバグ0件を意識して開発を進める。


最近では、オープンソースでも、効果の高い品質向上ツールが多く登場している。
それらのツールをしっかり活用できれば、品質問題により、納期遅延やコスト超過となる状況は、大抵未然に防ぐことができる。


参考までに、以下のサイトでは、開発者でも知っておくと良い情報が得られる。


developerWorks : developerにもテストを


しかしながら、このような有用なツールがあっても、実際の現場では、ツール名ぐらいは知っていても、インストールしていなかったり、設定がされていなかったりして、十分に活用できていない状況も良く目にする。


少なくとも、CheckstyleFindBugsなどはEclipseとも連携できるため、開発者の最低限のマナーとして利用方法を習得すべきものだろう。