最悪の領域とは多くの欠陥が隠されている領域です。
つまり、多くの欠陥がどこにあるかを予測することが重要なタスクです。
これは、想定される欠陥発生要因を分析することで予測できます。
このセクションでは、最も重大な欠陥発生要因と欠陥が発生しやすい領域によく現れる症状について説明します。
欠陥は特定の要因に集中しています。これに関しては一部この章でも説明します。
それは最も重要な部分と最悪の領域を特定するために適用されます。
複雑さというのはおそらく最も注意しなければいけない欠陥発要因です。
世の中には200種類以上の複雑さを計測する方法が存在し、複雑さと欠陥頻度（欠陥密度）の関連性についての研究は20年以上に渡って続けられています。
しかし、現在になってもなお一般的にちゃんと検証された欠陥の予測方法は存在していません。
それでもなお、現在使われている複雑さの指標のほとんどは実際に問題のある領域を明らかにできます。
指標の例としては、使われている変数の数、ロジックの複雑さ、制御構造の複雑さなどです。
複雑さに関してさまざまな側面に対していくつかの分析を行うことで、製品中で問題を引き起こす可能性のある領域を見つけられます。
変更は重要な欠陥発要因です（Khoshgoftaarら、1998）。
その1つのケースとして、
変更は簡単であると主観的に認識されている箇所に関して、しばしば影響範囲が十分に分析されていない事があります。
もう1つは、時間の経過とともに徐々に変更が繰り返された場合、影響度分析が不完全なケースがあります。
その結果、副作用が起きてしまいます。
一般的な製品ではソースコードの変更のログが存在するでしょう。
これは構成管理システムの一部と呼びます（存在する場合）。
変更を機能領域別にソートしたり、変更した行数が異常である領域を見つけられます。
これらの情報から、最初から設計が十分でない、または多くの変更によって元の設計が跡形もなく破壊され、さらにその後の設計が不十分である兆候が見て取れます。
変更した行数が異常であるというのは、設計が不十分である1つの兆候です。
つまり、大幅に変更された領域は、ユーザーが期待していないような欠陥が存在する可能性があります。
新しいツール、方法、技術にチャレンジしている場合、プログラマーは一定の学習曲線に沿ってスキルアップしていくでしょう。
学習曲線の初期では、それ以降と比較して多くの不具合を生み出すかもしれません。
新しいツールの例としてはCASE（Computer Aided Software Engineering）ツールや、会社内で新しく業務に取り入れるツール、市場においても新しくて不安定なツール等が含まれます。
もう1つの問題はプログラミング言語です。言語によってはプログラマーにとって新しいものもあるでしょう。
また、新しいツールやテクニックそのものが、問題を引き起こす場合もあります。
考慮すべきもう1つの要素は、利用する手法やモデルの成熟度です。
ここで言う成熟とは、理論的根拠の強さ、または経験的証拠の強さを意味します。
もし、対象のソフトウェアが、有限オートマトンや文法、関係データ・モデル等によって、適切に表現されている場合、それはかなり信頼できるものと期待できるでしょう。
一方、新しくてまだ実証されていない種類の方法またはモデル、または最先端技術が用いられている場合、ソフトウェアはより信頼性が低い可能性があります。
ほとんどのソフトウェア・コスト・モデルでは手法やツール、技術に対してプログラマーの経験に基づく要素が含まれています。
これは、開発コストの見積もりとではもちろん、テスト計画においても重要です。
ここのアイデアは千匹の猿シンドロームと呼ばれます。
つまり、タスクに関わる人が多くなればなるほど、コミュニケーションのオーバヘッドは大きくなり、その領域が悪くなる（欠陥を多く含む）可能性も大きくなります。
少人数で熟練したメンバー達で作業する方が、中程度の能力メンバーが集まった大規模なグループよりもはるかに生産的です。
COCOMO（Boehm、1981）ソフトウェアコストモデルでは、メンバーサイズはソフトウェアサイズの次に重要な要因となります。
それらの欠陥の影響の大きさは、欠陥を検出し修正するときにかかるコストから算出できます。
比較的多くの有資格者で構成されている領域は、よくテストされていると認識されることがあります。
この文脈において「有資格者」とは何かを定義することが重要です。
プログラミング言語のスキルやドメイン知識、開発プロセスのスキル、職務経験など。
その分析には注意が必要です：
いくつかの企業（Jørgensen、1984）では、より複雑な領域に対して最高の人材で対応し、はレベルの低い人材は簡単な領域にアサインしています。
しかしながら、欠陥密度は、人数または構成されるメンバーの優秀さに関連していないかもしれません。
優秀だけど欠陥密度が高い、典型的なケースとしては、大人数で、しかもフォローアップが十分にされていないコンサルタント達が開発しているプログラムです。
欠陥が多い理由の1つは彼らはそれぞれまったく違うやり方で働いているからかもしれません。
時間的プレッシャーにさらされると人はショートカットしたくなります。
人々は問題を解決することに集中し、しばしばすべてがうまくいくと楽観的に考え、品質管理活動をショートカットしようとします。
成熟した組織ではこの楽観主義がちゃんとコントロールされているでしょう。
また、時間的プレッシャーは、残業を誘発する可能性があります。
しかし、よく知られている事として、長期間の作業は人の集中力を奪います。
不十分なレビューとインスペクションは欠陥密度を極端に増加させる可能性があります。
開発中の時間的プレッシャーをデータとして取得したい場合、労働時間のリストの調査やマネージャーやプログラマーにインタビューすることによって取得できます。
図2：プレッシャー下で事態は悪化する。
COCOMOコストモデルでは、コスト要因の1つとして機械時間とメモリーの不足があげれています。
論点としては、最適化をすると追加でデザインする労力を必要とするか、あまり堅牢でないデザインを使用して最適化を行えるということです。
追加デザインは、欠陥除去活動（バグフィックス）からリソースを奪う可能性があり、あまり堅牢でないデザインは、より多くの欠陥を生み出しかねねません。
欠陥修復は"変更"をもたらします。これは先述したとおり、新たな欠陥を生み出しやすくなります。
したがって欠陥のある領域はこの負のサイクルを通して持続する傾向がある。
経験則によると、本番環境のシステムで欠陥のある領域は、レビューやユニットとサブシステムのテストで欠陥のある領域に遡れます。
次の2つの研究（Khoshgoftaar et al.1998）と（Levendel.1991）によると、過去に欠陥があったモジュールは将来に渡って欠陥を継続しやすいことを示している。
設計とコードレビュー、およびユニットとサブシステムのテストによる欠陥の統計が取得できたならば、後工程であるテストフェーズで優先順位を決定するのに有益なデータとなり得ます。
プロジェクトで一緒に働いているメンバーが同じ場所で働いておらず、地理的に分散ている事は、コミュニケーションの悪化をもたらします。
これは同じ建物レベルでも当てはまります。
地理的距離がプロジェクトに悪影響を及ぼしかねない場合、ある程度効果が判明しているアイデアは次に列挙するものです。
-
同じ建物の異なる階にオフィスを構えている人は、同じ階にいる人と同じくらいコミュニケーションをとりましょう。25メートル以上離れて座っている人は、十分にコミュニケーション取れていないかもしれません。
-
一般的にプリンターやコーヒーマシンなど、ワークスペース内に共有スペースを設置するとコミュニケーションが改善されます。
-
異なるラボにいる人とは、同じラボの人よりもコミュニケーションが少なくなる傾向があります。
-
国や人種が異なる人同士は、文化的にも言語的にも、コミュニケーションの問題を抱えている可能性があります。
-
タイムゾーンが異なる場合、コミュニケーションはより困難になります。
原則として、地理的に分散して働くことは危険ではありませんが、それらの人々が互いにコミュニケーションしなければならない状況が危険が生じます。
たとえば、彼らがシステムの共通部分で作業する場合などです。
あなたは、ソフトウェア構造の中でメンバー間の良好なコミュニケーションを要する領域はどこかを事前にチェックしておく必要があります。これらの領域は地理学的には同じ場所が良いでしょう。
そのほか考慮される要因としては、
-
新規開発か再利用か：完全に（1から）フルスクラッチで開発された領域は、（主に）再利用される領域よりも多くの欠陥を含む可能性が高くなります。
-
インターフェイス：多くの欠陥は、しばしばコミュニケーションの問題に起因して、コンポーネント間のインターフェイスに関連していることが実証されています。したがって、より多くのインターフェイスを持つコンポーネントは、欠陥を起こしやすくなります。この文脈における特徴的な問題は、しばしば、内部インターフェイスと外部インターフェイスとの間で発生します。
-
サイズ：コンポーネントが大きくなり過ぎると、メンバー間で全体間が失われることがあります。したがって、（あまりにもコード量が多い）大きなコンポーネントは、普通のサイズのコンポーネントよりも多くの欠陥を含んでいる可能性があります。
プロジェクトについて知識が少ない場合や、欠陥発生源が特定できない場合は、探索的テストを実施します。
最初にざっとテストして、欠陥のある領域が見つけます。次のテストでは、欠陥の見つかった領域に集中できます。
最初のテストはシステム全体をまんべんなくカバーすべきですが、非常に浅いテストとなります。
代表的なビジネスシナリオといくつかの重要な障害の状況についてのみ実施してください。
その後、最も多く欠陥が発見された領域を特定し、次のテストでこれらの領域を優先させましょう。
次のラウンドは、優先順位をつけた領域に対してより深く、より徹底的なテストをしましょう。
この2フェーズのアプローチは、テストの前に行われた計画と優先順位と併用することで、どんなプロジェクトでも適用できます。
ハードウェア、産業プロセス、ネットワークなどと直接コミュニケーションするソフトウェアは、ハードウェア障害、データのノイズ、タイミング問題など、比較的外部の影響を受け易いと言われています。
テスターとして見積もりを減らしたり、テストの実行対象を絞り込んだりしても、どうか怒らないでください。
なぜならばどんなプロジェクトにおいても予算とリソースは常に制約されており、欠陥をゼロにすることはできないため、テストを絞り込む罪悪感と恐怖にさいなまれることは避けることはできないはずです。