PR

STEP2 テスト観点とひも付ける

 不具合の傾向だけでは、どういったテストを手厚くすればいいのかまでは分からない。そこで、不具合とテスト観点とのマッピングを行い、不具合がどのようなテスト観点で多く見つかっているのか分析を行う。

 テスト観点とは、ソフトウエアのどの部分をどのようにテストするのかを決めるための観点である。テスト観点には、画面に表示されるテキスト・文言が仕様通りであることを確認する「テキスト・文言」、画面項目の表示/非表示の切り替えが正しいことを確認する「表示/非表示」、データを正しく登録できることを確認する「登録」、計算処理が仕様通りであることを確認する「計算ロジック」などがある。

 まず、STEP1で洗い出した不具合はどういったテスト観点で検出できるものなのかをひも付ける。例えば、「画面の説明文に誤字がある」という不具合のテスト観点は「テキスト・文言」となる。テスト観点ごとに不具合を整理すれば、どのような観点で業務影響度や目に付きやすさが高い不具合が出ているのかを把握できる。

 テスト観点別の不具合数を可視化した例が下図だ。登録と計算ロジックのテスト観点で、業務影響度の高い不具合が多く出ていると分かる。また、テキスト・文言と表示/非表示の観点で、目に付きやすい不具合が多く出ている。この4つの観点は重点的にテストをする必要がありそうだ、と当たりを付けられる。

テスト観点別不具合数の分析例
テスト観点別不具合数の分析例
[画像のクリックで拡大表示]

 ここから、重点的なテストが必要なテスト観点を絞り込む。STEP1で分類した不具合の軸や傾向などによっても異なるが、例えば業務影響度「高」の不具合1件当たり5ポイント、「中」は3ポイント、「低」は1ポイント、目に付きやすさ「高」を5ポイント、「低」を0ポイントといった具合に点数化する。不具合数と業務影響度、目に付きやすさの総合ポイントの高いテスト観点から順に優先順位付けを行う。

 規模の大きい製品・サービスでは、テスト観点以外にも分析の切り口を考えるとよい。機能数や画面数が多いと、1つの製品・サービスの中でも機能の処理内容や画面の作りにいくつかの種類がある。不具合傾向もそれによって異なってくる可能性がある。機能別または画面別、かつテスト観点別といった切り口で不具合数の分析ができれば、より細かい単位で不具合の起こっている箇所を特定できる。