2024
6/21
ベンダーは作るけどユーザーは作らない
ベンダー側は、必ず「テスト計画書」を作成します。もし作っていなければ、ユーザー側は強く要求します。
では、ユーザー側は「テスト計画書」は作っていますでしょうか？
こちらは、ほとんど作られることはありません。おかしな話です。
ベンダー側もユーザー側も、テストは実施します。
ベンダー側では「単体テスト」「結合テスト」「システムテスト」を実施します。これらをどう進めるかを計画します。
他方、ユーザー側では「受入テスト」を実施します。
（現場によっては「UAT（User Acceptance Test）」とも呼びますが、本コラムでは「受入テスト」で統一します。）
こちら1種類のように見えますが、受入テストも分解すると「要求機能テスト」「システム間連携テスト」「シナリオテスト」「現新比較テスト」とバリエーションがあります。
これらをどう進めるかを計画しないといけません。
ベンダーにテスト計画書を要求するなら、ユーザー自身も作るべきではないでしょうか。
なぜユーザーは作らないのか？
では、なぜユーザーはテスト計画書を作らないのでしょうか？
理由は2つあります。
1点目は、ベンダーがわざわざ受入テストを細かく依頼しないからです。
ベンダーは自分たちのテストで手一杯です。ユーザーにたくさんテストをされて、バグや仕様変更が大量に見つかっても困ります。
だから、ベンダーはユーザーが受入テストをほとんどやらなくても、全く構わないのです。
2点目は、テスト計画書の「作り方がわからない」からです。もっといえば、「ユーザー側で作らないといけない」という発想自体がないのです。
しかし、ユーザー受入テストは超重要です。ここが最後の砦です。
もし、ここでバグを見逃してしまえば、リリース後の「本番障害」となってしまうからです。
品質確保のため、しっかりと受入テストを計画し、実行していきたいものです。
情シスがユーザーを巻き込む方法
また、別の問題として、受入テストを頑張るのが「情シスだけ」というパターンもよく見かけます。
これは、非常にまずいです。
情シスは、エンドユーザーではないため、現場視点を持っていません。業務知識も不足しています。
どちらかといえば、IT側の視点となるため、テストをしてもベンダーと被ってしまいます。
では、どうすればユーザーを受入テストに巻き込むことができるのでしょうか？
それが「受入テスト計画書」です。
ここで、テストを定義し、その主役がユーザーであることを示すのです。
ユーザーの役割と責任を明確にすることで、ユーザーの当事者意識を作っていくことが重要です。
この計画書のたたき台は、情シスが作ってもよいでしょう。その後、ユーザーと一緒に計画書を完成させることで、明確に主役が情シスからユーザーにバトンタッチされていきます。
そのため、「受入テスト計画書」を作ることは、非常に重要なのです。
受入テスト計画書の考え方
受入テスト計画書は、そこまで難しくはありません。
端的にいえば、「テスト種類」を明確にし「体制」と「スケジュール」を決めて「進め方」を示すだけです。
テスト内容の詳細は「テスト項目書」に書くので、別資料となります。
そう考えれば、作成のための心理的なハードルは、かなり下がるのではないでしょうか。
受入テスト計画書のサンプル
（※ 画像をクリックすると、大きな画像が表示されます）
受入テスト計画書の項目解説
1.受入テストの位置づけ
ベンダーテストとユーザーテストの違いを示します。ベンダーは「要件定義書」や「設計書」通りにシステムが作られているかを確認します。一方でユーザーは、もともとの「要求」通りに作られているかを確認します。
その上で、ユーザーが実施すべき受入テストの種類を定義します。
2.受入テストの概要
受入テストの各テストの内容を定義します。「システム連携図」や「業務パターン表」などのイメージ画像は、実際のプロジェクト資料で適切なものに差し替えてください。
3.受入テスト環境
テスト種類によって、テスト環境は分けた方がよい場合があります。例えば、テストデータがバッティングしたり、誰かのテストデータを書き換えたりしないためです。
また、サーバーの性能的にも、本番の全件データを投入してテストをしたい場合は、本番と同等にする必要があります。一方で、機能テストであれば、性能は最低限で構いません。
そのため、どの環境でテストをするのかをそれぞれ定義します。
4.受入テストスケジュール
ベンダーと合意したマスタースケジュールに、受入テストの各テストを当てはめていきます。当てはめていくと、実はユーザーのテスト期間が驚くほど短いことに気づく場合があります。その場合は、ユーザーのテストタイミングを早めたり、ベンダーとスケジュールを調整したりする必要があります。
5.プロジェクト体制
このページが最も重要です。ここで「ユーザー」を巻き込めるかどうかが決まるからです。そのためには、部署名だけを書くのではなく、ユーザーの「個人名」で体制図、役割をどんどん書き込んでいきます。場合によっては、リーダーだけ決めて、メンバーはリーダーに書かせる方が良いこともあります。リーダーが自分でチームを組成した方が、やる気が高まるからです。
6.受入テスト管理方針
「テストドキュメント」をどこに格納するか「進捗会議」をどうするか、バグを見つけたらどこに「起票」するか、など管理方針を示します。
受入テストキックオフを開催する
情シスが受入テスト計画書のたたき台を作り、ユーザーに更新してもらいます。そして、完成したら、関係者を集めて「受入テストキックオフ」を開催します。
ここで、体制図に書かれたユーザーを一同に集めて、受入テスト計画書を読み合わせします。各ユーザーの役割と責任を自覚していただき、当事者意識を強めてもらいます。
ここからが、本当の勝負です！ユーザー側で最大の労力を投入する「受入テスト」が本格的に始動します。
では、受入テストを頑張っていきましょう！！
（↓関連記事↓）
要求機能テスト項目書の作り方（サンプル画像付き）
シナリオテスト項目書の作り方（サンプル画像付き）
リリース判定／本稼働判定の作り方（サンプル画像付き）
＊＊＊＊＊
※ 弊社で公開しているサンプルについては、基本的に画像のみの提供とさせていただいております。ファイルデータのダウンロードを可能とすると、内容の吟味をせずにそのまま流用し、トラブルに発展する可能性があるためです。画像データから文字起こしを行う過程で、それぞれのプロジェクトの状況に合わせてアレンジしていただければ幸いです。
