品質を上げる上では、レビューやテストにてあるプログラムのバグを１つ見つけた場合、「他にも同じようなバグが潜んでいないか」という視点で追加でレビューやテストを入れるのが定石です。
類似バグが発生しやすいポイントを押さえて追加レビュー・追加テストを行うことで、少ない工数で品質を上げることができます。
類似バグが潜んでいないかどうかのチェックをIT業界の用語で「横展開」や「水平展開」と呼ぶのですが、このチェックを行うポイントの見極めにはいくつかのコツがあります。
今回の記事では、そのコツについて挙げていきたいと思います。
１．業務ロジックが類似している処理に目をつける
これが基本中の基本です。
「横展開」や「水平展開」と呼ばれるチェックは、多くの場合は業務ロジックが類似している処理のチェックになります。
例えば、小売店のシステムについて、新たな割引制度を導入するシステム対応を行っているとします。
そして、割引後の値段の算出について、端数の扱いの誤りに起因するバグが見つかったとします。
もし、割引後の値段を算出する記述が複数個所にあるのだとしたら、他の記述についても同じ誤りをしている可能性が高いので、それらの記述については全て追加レビューや追加テストをするべきです。
また、割引後の値段を算出するロジックを考える際に参考にしたロジックがあるのであれば、例え既存ロジックだとしてもその記述をチェックするべきです（本番運用でまだ見つかっていないバグが既存ロジック中に潜んでいる場合があります）。
２．特定の担当者や会社に着目する
スキルや仕事の進め方の違いにより、特定の担当者や会社の成果物にバグが集中して発生することがあります。
そのようなケースだと考えられる場合、特定の担当者や会社の成果物について集中的にレビューやテストを行うことで、効率的にバグを見つけ出すことができます。
特定の担当者や会社の成果物にバグが集中していることを見つけるためには、客観的な指標としては、メトリクス（品質の高さを示す数値）が参考になります。
例えば、「単体試験バグ数/STEP数」はソースコードの品質を推し量るのに役に立ちますし、「単体試験で見つけるべきバグの発生頻度」を結合試験で測っているのであればそれは単体試験の品質を推し量るのに役立ちます。
また、品質チェックを行う側に十分なスキルがあるのであれば、メトリクスを取るまでもなく、ちょっとしたやりとりから主観的な観点で品質の高さを推し量ることも可能です。
３．低品質のモジュールに着目する
仮に同程度のスキルで同じような仕事の進め方をする担当者・会社が集まっていたとしても、バグが集中的に潜んでいるモジュール（部品）とそうではないモジュールに分かれることが多いです。
一般的に、業務ロジックが複雑なモジュールや、多くの他モジュール・他システムと連携するモジュールは、バグが発生しやすいです。
バグが発生しやすいモジュールに対しても、集中的にレビューやテストを行うことで、効率的にバグを見つけ出すことができます。
注意点として、業務ロジックや連携が複雑なモジュールに関しては、そのモジュールを作成した担当者や管理者がどれだけレビュー・テストを行っても知識不足により十分にバグを見つけ出せない場合があります。
そのため、業務のスペシャリストや、連携先のモジュール・システムの担当者の力を借りることも重要になります。
低品質なモジュールについても、メトリクスのような客観的な指標を用いると見つけやすいです。
また、複雑性が高くバグを埋め込みやすいモジュールは設計段階で何となく気付くので、早い内から集中的にチェック・テストを行う計画を立てておくことも有効です。
いかがでしたでしょうか。
レビューやテストを完璧に行うことは時間的に不可能なので、バグを引き起こしやすい箇所に集中して行う必要があります。
（テストで境界値チェックが有効とされる理由もそこにあります）
今回は、バグを引き起こしやすい箇所の見分け方を、横展開という観点で書いてみました。
参考になれば幸いです。
コメント