こんにちは、テストエンジニアの佐藤です。

テスト期間の期日直前になって、特定の機能から大量の不具合が検知された……、
「予め、不具合が多く発生する箇所が分かってれば、そこから先にテストしたのに……!」と、
悔しい想いをした経験は、テストエンジニアであれば一度は経験した事があると思います。

本記事ではこれまでに知られて来た、不具合が多く発生する箇所の予測に有効な方法を二つ挙げ、
そして自分自身のテスト経験から、「表記揺れ」の多さは品質の低さの予兆ではないかという自説を一つ、
添えさせて頂きます。

1.テストマネージメントで不具合多発箇所に目星をつける

発生した不具合の統計から発生傾向を予測し、
検知と修正の効率を向上させる為のマネージメント方法は数多く存在します。

例えば下図のケース、
実際のプロジェクトで、これほどはっきりとした傾向が示される事は少ないでしょうが、
この図では既に、現時点で最も品質が低いと思しき箇所は見えています。

一例としてここに「パレートの法則」を当てはめ、
“不具合の80%は、特定の20%のコンポーネント/モジュールに起因している”という考え方の下、
発生傾向が高く見られた箇所に対し、更に多くの不具合が伏在しているものと想定し、
集中的にテストを実施する方針を採ります。

「弱点を集中的に叩く」とだけ書くと当たり前のようにも聞こえますが、
経験と実績に裏打ちされる法則を参考にした戦略を立てる事により、
限られた工数の中でテスト効果を最大化出来ると考えます。

勿論、上述の法則は飽くまでも参考の一つであって、
あらゆるプロジェクトに適用出来るわけではありません。
プロジェクトの性質に応じて適切な理論や法則、マネージメント方法を選択する必要があります。

2.アルゴリズムから危険度の高いソースコードを割り出す

これは2011年にGoogle社の技術者向けブログ「Google Engineering Tools」の
記事「Bug Prediction at Google」にて「バグ予測アルゴリズム」が発表されました。

これはソースコードを管理しているリポジトリーの更新ログより、
「直近でバグフィックスのために修正された回数が多いファイル」ほど、
不具合を発生する可能性が高いと看做し、高いスコアーを付けるというシンプルなアルゴリズムです。

このGoogleのアルゴリズムを組み込んだ、GitやSubversion対応ツールも既に公開されています。

3.「表記揺れ」は品質のバロメーター

ここからは私の経験から得た事柄について記述します。
私が担当する工程はほぼ「総合・シナリオテスト」の一本槍ですが、
この工程の現場レベルでは、表記揺れなど文言系の不備の多さが、
プロジェクトの健康度を測るバロメーターになるのではないかと考えています。

もし色々な種類の不具合に対し、修正順序の優先度をランキングするならば、
「表記揺れ」は最下位に位置付ける事が順当です。

ですが、「表記揺れ」の多さが目につくプロジェクトは、

・ 設計書/仕様書に不備
・ 実装者による設計書/仕様書の確認不足
・ 指示者及び開発者間でのコミュニケーション不全
・ 結合テストが不十分

上記のいずれかの問題、或いは全ての問題を抱えていると推察出来ます。

実際のところ、文言に不備がある機能について詳しくテストしてみると
他の不具合が一緒に埋まっていたという事が、私の経験上では多いです。

ご参考までに、ソフトウェアテストに於ける“表記揺れあるある”をまとめました。

テストの際、もしも特定の機能周辺で「表記揺れ」が複数見つかった場合、
それは何らかの不具合が伏在している事を示す兆候の可能性があります。
追加テストの要否について是非ご一考下さい!