≣概要

FLシラバスの「テストの7原則」の4つ目です。前回の原則3は、「早期テストで時間とコストを節約」でした。原則3で早くテストを始める意義が分かったとして、原則4ではテストの目的のひとつである「故障や欠陥を発見する」ために知っておくべきことが書かれています。（目的を果たすために、ターゲットとなる欠陥の性質について知っておくべきことが書かれています。）

さて、今回の原則4は、「欠陥の偏在」ですが、一言でいえば、「欠陥は全体的にランダムに存在するのではなく、偏って存在する」ということです。テストをしている方は実感があるのではないでしょうか。

≣ シラバスの記載

『ISTQBテスト技術者資格制度　Foundation Level シラバス 日本語版 Version 2018.J02』の該当部分を引用します。

4.欠陥の偏在 

リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。
テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。（原則2で触れたことと同様）

≣ 解説（全体）

ソフトウェアテストのテクニックの一つとして「ミューテーション」が流行ったことがあります。いまでもその進化型というべき「fault-prone」の研究が続いています。

「ミューテーション」とは、「突然変異」のことです。昔（1970年代後半）、「地球へ…」（「テラへ」と読みます）というマンガ＆アニメがヒットしたことがありました（本ページのキャッチイメージです）。このアニメは、突然変異を起こし、超能力を持つようになった人類（ミュータント）の物語でした。

ミューテーションテストとは、テストのときに、テスターには内緒でソースコードの一部を、例えば、「＋３」を「＋５」にするなど、機械的に書き換えることで、人工的なバグを加えたものをテストするという方法です。
例えば、ソースコードの100か所を機械的に書き換えてテストしたところ、200個のバグが見つかったとします。そして、見つかった200個バグのなかの70個は、書き換た人工的なバグだったとします。
100個の人工的なバグ埋め込んで70個見つかったわけですから全バグの70%のバグが見つかったと考えます。この段階で見つかっている本物のバグは、200-70＝130個です。ただ、このとき、130個は本物のバグの総数に対しても70%に相当すると考えます。すると、本物のバグ総数ｘは、
　　130 ： ｘ ＝ 70 ： 100
の比例関係となるため、ｘ＝130×100÷70＝185.714286...。すなわち、186個と見積ることができます、186個の本物のバグのうち、130個のバグが見つかっているわけですから、あと56個の本物のバグを見つければ、バグを見つけ尽くした？ということになります。
この方法について、「良い方法じゃないか！」と思った方がいらっしゃるかもしれません。
でも、ちょっと待ってください。原則4は「欠陥は偏在する」ということを示しています。はたして、機械的にソースコードを書き換えることで作った人工バグは、テスト対象のソフトウェアに「偏在」しているでしょうか？

　単に偏らせたいだけなら適当にモジュールを選らび、そのモジュールのソースコードを書き換えてバグを埋め込めばよいですが、大切なことは本物のバグの偏り方と人工的に作ったバグの偏り方が同じであること（少なくとも相関があること）です。
ちなみに、本物のバグの偏り方を予測することを「fault-proneモジュール予測」と呼びます。とても大切な技術ですし、大きな成果も出ています。

≣ 解説（詳細）

ここからは、FLシラバスの解説をもう少し分解して細かく読み解いていきたいと思います。
まずは、FLシラバスの解説を再掲します。

リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う。（原則2で触れたことと同様）

■　リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する

前半のこちらは、「欠陥が偏在すること」そのものの話です。ここに書かれているように、「モジュール単位でみたときの偏在」もありますし、書いていませんが、「境界値のあたり」に多くのバグが存在するといった偏在もあります。（ですから境界値分析というテスト技法が存在します。）
さて、偏在モジュールを分析する時には、慎重に原因を分析する必要があります。

私の実体験を書きます。あるプロジェクトで、「GUIのバグが異常に多い」という指摘が出たことがあります。ほとんどのバグはユーザーの入力に対する異常な出力なので、「ユーザーの入力をハンドリングするモジュールに欠陥が偏在している！」という誤った分析結果になったのです。
本当は、「ユーザーの入力をハンドリングするモジュールがその裏にある機能モジュールの欠陥をカバーする役割を持っていた」ために見かけ上、GUIにたくさんのバグがあるように見えたのでした。

■　テストの労力を集中させるために欠陥の偏在を予測し、テストや運用での実際の観察結果に基づいてリスク分析を行う

後半のこちらは、原則4に対する対策が書いてあります。「欠陥の偏在を予測」する技術は、上述した、「fault-prone」のことです。（fault-proneは、「欠陥を含んでいる確率が高い」とか「欠陥の傾向」という意味です）

fault-proneというと、難しそうに思われたかもしれません。でも、ソースコードのサイクロマチック複雑度を測定し、「複雑なモジュールに欠陥があるのでは？」と推測してテストすることありませんか？　これもfault-proneです。

私が一番よく使うのは、開発者に3Hを教えてもらう方法です。「3Hをリストしてもらい、それぞれに対して心配事やテストをしてほしいこと」を書いてもらうのです。とても原始的な方法ですが、効果を実感できますのでおすすめです。

≪3Hについて≫
3Hは、3H作業とも呼ぶのですが、「変化（Henka）」、「初めて（Hajimete）」、「久しぶり（Hisashiburi）」の3つのHで3Hです。
　・変化：　変更を加えたところ、環境の変化
　・初めて：　初めて使う技術、初めての開発環境、初めてのライブラリ
　・久しぶり：　昔作ったライブラリを作り直す、担当者が変わる
等の箇所に欠陥が生まれやすいことを仮定しています。

また、「テストや運用での実際の観察結果に基づいてリスク分析を行う」は、テストや運用時にメトリクス（管理特性）のモニタリングをしっかり行い、テスト計画を更新するなど、リスク分析やその対応をすることを示しています。

≣ まとめ

「欠陥の偏在」自体は非常に分かりやすく実感が持てる原則です。それゆえに納得感も高いものです。したがって、「ミューテーションテスト」や「fault-proneモジュール予測」は大変人気があります。機械学習技術を応用すると面白いのではと思っています。

≣ 注意！

本エントリーに対して、下記の情報をいただきました。ミューテーションテストについて、Wikipediaの説明はこちらです。詳細が分かり次第、本エントリーの修正をします。