コラムカテゴリー：プロジェクトマネジメント
テストケースは誰が作成するべき？
システム開発のプロジェクトでは、各種ドキュメントなど多くの成果物をベンダーが作成します。
そのため、テストケースもベンダー側が作成し、ユーザー側で確認・修正をして完成させるものだと考えている人が多いように感じます。
しかし、本来はユーザー側、特に業務担当者がメインで作成するべきものであり、ベンダーはあくまで補佐的なポジションであることを認識するべきです。
テストケースをベンダーで作成することのリスク
システムの開発者であるベンダーの目的は、ユーザーの要望に沿ったシステムを納品することです。
そのため、ベンダーは「この機能ではこの入力をして、こういう動作の確認ができればOK」という視点での確認となります。
一方、ユーザーの目的は新システムを活用して業務効率化や新ビジネスへの対応であり、「新システムで達成可能かどうか」という視点での確認となります。
つまり、ユーザーとベンダーでは確認の視点が異なるということです。
ベンダーが作成するテストケースでは「業務効率化などの目的が新システムで達成可能かどうか」という視点での確認ができないリスクがあります。
新システムを活用した新業務フローには、新システムの対象範囲外の業務も含まれますが、ベンダーは新システムの対象範囲外の機能については責任を負うことができません。
そのため、ベンダーが作成する場合はシステム化対象外の業務（例：継続利用する会計システムとの連携や連携したデータを使用した処理等）がテストの対象外となる可能性があります。
テストするべき業務が対象外となってしまうと、以下のような悪影響が発生する可能性が高まります。
・テストスケジュール（プロジェクト）の遅延
・本番稼働の延期
・本番稼働後のユーザー負荷が増加
テストケースはどのように作成するか
テストケースのベースは新業務フローです。
受入テストは「新業務フローに新システムが対応できているか」の最終確認を行うフェーズのためです。
ベンダーが要件定義フェーズ等で作成したものではなく、ユーザーが描く新システムを利用した新しい業務フローを使用するのが望ましいです。
テストケースの作成方法はシンプルで、新業務フローで業務を行うために必要な機能をテストケースとして落とし込んでいくだけです。
業務フローからテストケースを作成できない場合は、業務フローの解像度が低いか網羅的に作成できていない可能性が高いです。
その場合は新業務フローの見直しを行い、修正したフローから再度テストケースを作成してください。
業務フローから見直さないと、テストケース作成時に気がついた業務の漏れから他の漏れに気が付きにくく、テストの対象外となってしまう可能性が高まります。
以上のことから、テストケースはユーザー（業務担当者）が作成するべきですが、ユーザー側に「テストケースは自分たちで作成するべきだ」ということに気が付いている人は少ないように感じます。
また、作成方法はシンプルですが、実際に作成する業務担当者からすると非常に負荷が高い作業です。
（通常の業務に加え、ベンダーとの打ち合わせや成果物の確認などの業務が重なり、プロジェクト中は高負荷状態であることが多いです。）
業務担当者がテストケースを作成する理由やその時間の捻出するためには、まず経営者等のプロジェクトオーナーがユーザー側でテストケースを作成する必要性を理解する必要があります。
プロジェクトオーナーが主導権を握って業務担当者にその必要性の説明やリソースの分配を行い、ユーザーがテストケースを作成できる環境を整備することが重要です。
最後に
受入テストはプロジェクトの集大成ともいえる重要なフェーズです。
このフェーズを抜け漏れなく確認することができれば本番稼働後のリスクを大きく減らせます。
ぜひ、本コラムで紹介した内容を活かし、受入テスト・プロジェクトの成功の一助としていただけると幸いです。
2023年06月27日 (火)
青山システムコンサルティング株式会社
