テスト項目の検討

担当者によってテストの実施内容にばらつきが出ないように、工程毎にテスト項目を定める必要があります。 ただし、品質を高めようとしてむやみに項目を増やしてしまうと、コストを掛けたわりにバグが見つけられず QCDのバランスが悪化する恐れがあります。

ここでは、テスト項目を取捨選択するときに考え方を説明します。

テスト観点の収集

まず、テスト種別＆テスト観点カタログを参照し、 単体テスト仕様書フォーマットをプロジェクト用に作成します。

テスト項目は多ければよいというものではありません。 テスト項目を多くすると品質は確保しやすくなりますが、コストや納期に影響を与えます。 このため、プロジェクトのQCD目標に合わせたテスト項目を設定する必要があります。

テスト観点の抽出

最初は、考慮漏れを防ぐため観点カタログからテスト観点を用意しますが、 その中からプロジェクトに関係しないものを除外します。 例えば、プロジェクトでバッチ処理やメール送信の要件がなければ これらの観点は除外します。

ここからさらに観点を取捨選択する必要があります。 テスト観点を見て、「製造担当者がどのようなミスをしたら、このテスト観点でバグが発見できるか？」を考えます。 その結果以下のようなテスト観点があれば省略を検討します。

  • そのテストを行ってもバグが発見できる見込みがない、可能性が極めて低くコストに見合わない
  • 他の活動で検知できる
    • レビューで検知できる
    • 次工程のテストで検知できる

例えば、画面確認項目でjsp:includeを使用してレイアウトを実現する場合、 個々の共通領域（ヘッダーやフッター）の確認は省略可能です。 なぜなら、担当者がプロジェクトの開発標準に沿って開発すれば、その画面を作成する過程でバグを埋め込む要因がないからです。

もし担当者がプロジェクトの開発標準に沿わずに画面を作成した場合は、共通領域が正しく実装されない可能性はあります。 しかし、標準に沿ったコーディングをしているかはソースコードレビューでチェックできますし、 そもそもプロジェクトの開発標準が適切に展開されていれば、担当者が独自のやり方でコーディングをする理由はありません。

このようにして、共通領域の確認は、下記のような観点から省略可能であるという判断が可能です。

  • プロジェクトの特性から考えてバグを埋め込む可能性が低い
  • 他の活動でも検知可能である
  • バグがあったとしてもその影響が軽微である

単体テストだけで閉じてテスト観点を考えるのではなく、プロジェクトの特性を踏まえて観点の取捨選択をすることで プロジェクトの生産性を向上させることができます。