ベンダーの手垢がついていない資料をもとに作成する

ユーザーが「受入テスト項目書」を作成する際、ベンダーが作成した「要件定義書」や「機能一覧」をベースに作ろうとする現場を多く見かけます。

ですが、それだと意味がありません。

なぜでしょうか？

それは「ベンダーとテスト項目が重複する」からです。

ベンダーは要件定義書をもとに「システムテスト」を実施しています。そこと重複するからです。

要件定義書通りにシステムが作られているか、を確認することも重要です。しかし、そこはベンダーの責務です。

一方で、もし、要件定義書に「不備」や「漏れ」があったらどうなるのでしょうか？ベンダーのシステムテストにも「不備」や「漏れ」が発生してしまいます。

もし、ユーザーもその要件定義書をもとに受入テストを実施したなら、同様に「不備」や「漏れ」が発生することでしょう。

要件定義書自体の「不備」や「漏れ」は、ベンダーは絶対に気づけません。

そこに気づくことができるのは、ユーザーだけです。

だからこそ、要件定義書から距離を置きたいのです。目の前の新システムに固着せず、そもそものユーザーの要求に立ち返って、テストをすることが重要です。

では、どのように受入テスト項目書を作っていけばよいのでしょうか？

もっとも手っ取り早いのは、RFPの時に作った「要求機能一覧」です。その一覧の右側に「日付」「テスト結果」「実行者」を記載する欄を作れば、テスト項目書は完成です。

もし、RFPを作っていない場合は（このケースも多いのですが…）、現行システムの資料や現行マニュアルを参考に、テスト項目書を作成しましょう。
（ベンダー資料を見るのは我慢です！）

 
 

要求機能テストはユーザーも着手しやすい

ユーザーの受入テストは、主に「要求機能テスト」と「シナリオテスト」に分かれます。作りやすいのはどちらでしょうか？

それは、要求機能テストです。

シナリオテストは、少し手間がかかります。上から下まで「通し」でテストするため、顧客パターンや取引パターンを整理し、実施するシナリオを準備しないといけないからです。

一方、機能テストは、いわば「部品」のテストです。前後の流れに関係なく、単体でテストできます。

そのため、ユーザーの心理的な「テストのハードル」を下げるためにも、まずは要求機能テストがうってつけなのです。

 
 

要求機能テストでユーザーを巻き込む

さて、受入テストは「どれだけユーザーを巻き込めるか？」が重要です。

これまでプロジェクト活動と距離があったエンドユーザーに対しても、最後の受入テストはなるべく巻き込むようにします。現場目線での検証が欠かせないからです。

テストのハードルを下げるために、まずは着手しやすい要求機能テストから参画してもらいましょう。

このテストを通じて、ユーザーは
・新システムに慣れる
・ベンダーとのコミュニケーションに慣れる
・バグ起票に慣れる
など、プロジェクト自体に慣れてもらいます。

そのためには、テスト項目書をあまり細かく作り込みすぎないことも重要です。ベンダーのようにシステムの動きを細かく網羅した書き方にした途端、ユーザーは白旗をあげてしまいます。要求事項の書き方は、シンプルに簡潔に書くことです。

細かい確認が大事なのではなく、大きく俯瞰して要求の漏れがないかを確認することが大事だからです。

 
 

要求機能テストサンプル

（※ 画像をクリックすると、大きな画像が表示されます）

テスト項目は、業務毎（サブシステム毎）にシートを分けて、それぞれ分担して作成します。なお、このサンプル画像は、ある現場で作成した9つの業務のうちの7番目のシートです。

 
 

情シスがサンプルを提示することでユーザーに寄り添う

いくら簡単といっても、いきなり「テスト項目書を作成してください」と言われて、ユーザーがすぐに作れるものではありません。

そのため、可能であれば情シスがフォーマットと記入サンプルを提示した上で、たたき台を作りましょう。

その上で、ユーザーに「バトンタッチ」して、資料の完成を委ねましょう。

ただし、あまり完璧に作り込みすぎると、ユーザーの当事者意識が希薄になってしまいます。とはいえ、作り込みが浅いとユーザーは丸投げと感じてやりたくなくなるかもしれません。

このバランスが悩ましいのですが、個人的には40点〜60点の出来で渡すのがよいと考えます（渡すユーザーのレベルに応じて完成度を調整します）。

あえて簡単な隙をつくって、その部分はユーザーに書き込んでもらったりします。与えられたテストよりも、自分達で考えたテストの方が主体的になるからです。

情シスは、この活動を各業務のユーザーと行います。シートが10枚あれば、10回、ユーザーに寄り添い、立ち上がりを支援します。

そのため、情シスは受入テストが立ち上がるまでは、かなりの負担があります。

ですが、ユーザーとの関係性、距離感を創り出し、プロジェクトを軌道に乗せるのが情シスの役割であり、醍醐味ともいえます。

では、要求機能テストを頑張っていきましょう！！

 
 

（↓関連記事↓）
受入テスト計画書の作り方（サンプル画像付き）
リリース判定／本稼働判定の作り方（サンプル画像付き）
プロジェクト計画書の作り方（サンプル画像付き）
プロジェクト体制図と役割分担表の作り方（サンプル画像付き）
キックオフAgendaの作り方（サンプル画像付き）

 
 

＊＊＊＊＊
 
 
※ 弊社で公開しているサンプルについては、基本的に画像のみの提供とさせていただいております。ファイルデータのダウンロードを可能とすると、内容の吟味をせずにそのまま流用し、トラブルに発展する可能性があるためです。画像データから文字起こしを行う過程で、それぞれのプロジェクトの状況に合わせてアレンジしていただければ幸いです。