この記事はNishi Grover Gargによるゲスト投稿です。

欠陥はテスト対象ソフトウェアの一部の領域にクラスターとして固まっている傾向があります。その理由としては、高い複雑性、アルゴリズム、あるいはソフトウェアの限られたセグメントに多数の統合が存在することなどが挙げられます。

欠陥クラスターは、見つけるのも対応するのも想像以上に難しい場合があります。テスターは常に欠陥クラスターを切り分ける方法に気を配り、クラスターを克服する方法を考案し、欠陥と戦い、また新たなクラスターに取り組む必要があります。

欠陥クラスターを突き止める

多くの欠陥はソフトウェアの特定の領域にクラスターとして存在している傾向があります。これはテストの7原則の1つです。多くのテスターには欠陥がありそうな領域が本能的にわかりますが、それでもさまざまな方法で欠陥のクラスターを見逃さないよう見張ることができます。

メトリクス

欠陥密度チャートやモジュールの欠陥数などのメトリクスを使うと、これまでに見つかっている欠陥の履歴を確認し、欠陥の密度が高い領域、モジュール、機能を予測することができます。ここから欠陥クラスターの捜索を始めるべきです。これらの領域のテストにより多くの時間を費やすと、より多くの欠陥や、考慮すべきより複雑なユースケースを発見できる可能性があります。

たとえば、下のグラフはモジュール４に最も多くの欠陥があることを示しています。したがって、今後もこのモジュールに重点を置くのが賢明でしょう。

また、コード行数あたりの欠陥数を追跡したり、欠陥密度をチャートやグラフにプロットしたりすることも有効です。

履歴

不具合管理システムとソフトウェアの履歴を使用して過去の欠陥を閲覧し、システムで再現を試みます。システムの履歴を理解し、どこでシステムが壊れ、今はどのように動作しているかがわかるでしょう。ソフトウェアについて多くを学び、テストすべき新たな領域を見つけられるかもしれません。

経験

テスターの直感、経験、製品に携わってきた過去は欠陥クラスターを発見する上で非常に優れた手段です。経験を積んだチームメイトから学んだことを新しい同僚とも共有するべきです。そうすることで、知識を継承し、欠陥の多い領域を新たな視点から検証することで知識を役立て、改善することができます。

欠陥クラスターと戦う

欠陥のクラスターは、ソフトウェアの80％の欠陥は20%のモジュールに起因するというパレートの法則に従います。テスターは大多数の欠陥がある20%のモジュールはどれかを知り、そのモジュールに対して最大の労力を割くことができるようにする必要があります。そうすると、それほどテストの時間がない場合でも、うまくいけば、欠陥の大部分を発見できるでしょう。

欠陥クラスターの領域がわかれば、テスターはさまざまな方法で製品の欠陥を防止することに集中できます。

クラスターの領域をテストするよりよい方法を考案する

どの機能やモジュールに多数の欠陥が含まれているかを知ることで、テスターはテストするためのより良い方法を見出すことにもっと力を注ぐことができます。対象モジュールにより多くの単体テストや統合テストを追加することができます。また、機能が実際にどのように使用されているかという顧客から得たユースケースを参考にして、より掘り下げたテストシナリオを作成することもできます。

テストデータに注力すること、変数に対してより網羅的な組み合わせテストを作成することは、より多くの演算やアルゴリズムの欠陥をより早期に発見することにもつながります。

テスト計画で欠陥クラスター領域により多くの時間を割く

機能の重要性、複雑さ、あるいは「汚さ」には違いがあるため、テストに必要な労力や時間も異なるのが通常です。欠陥クラスターの場所を突き止めることで、テスターは欠陥がある可能性が高い、欠陥密度が高い領域やモジュールにより多くのテスト作業や時間を割り当てるよう計画できます。

このような透明性は、ユーザーストーリーごとのタスクの見積や実際にかかった時間をレポートするテスターの仕事を容易にします。欠陥の密度が高い領域を担当するテスターは、他のより小さなモジュールをいくつか担当するテスターがかける時間の2倍の時間を1つのユーザ―ストーリーにかけるかもしれません。このことを知っていると、現実的な予想に基づいて、タスクの割り当てを公平かつオープンにできます。

複数人の目で欠陥クラスター領域を検証する

将来に発生する欠陥を防ぐため、欠陥の密度が高いモジュールはより高いレベルのレビューをより多くの回数受けるべきです。さまざまなステージでピアレビューと複数人によるテストを実施し、機能の設計・実装・テストに関して異なる観点とフィードバックを得ることができます。

継続的プロセス

欠陥クラスターを特定し、上で述べたようなやり方で欠陥クラスターへの取り組みを始めると、欠陥の数は減ってゆき、時が経つうちにその欠陥クラスターはもう脅威ではなくなるでしょう。そのころには、欠陥を呼び寄せる新たな複雑な領域がシステムにできているでしょう。

テスターは欠陥クラスターを絶え間なく見張っている必要があります。欠陥クラスターを探し、対処することは、アプリケーションとともに発展してゆく継続的なプロセスです。

Nishiは企業トレーナー、アジャイルの信奉者、そして根っからのテスターです。業界で11年以上の経験を持ち、現在はSahi Proでエバンジェリスト兼トレーニングヘッドとして働いています。トレーニングに情熱を注ぎ、テストコミュニティイベントやミートアップを主催したり、多数のテストイベントやカンファレンスで講演を行っています。アジャイルおよびテスト分野での最近のトピックを取り上げたブログをご覧ください。

（この記事は、開発元Gurock社の Blog 「Fighting Defect Clusters in Software Testing」2020年6月4日の翻訳記事です。）