品質を定量的に把握するテンプレート

受入テストをサポートしよう

　前項の障害管理方法により、障害が収束したことを確認し、品質的に問題なく開発側でのテストが無事終了できたとしましょう。しかし開発側でのテストを十分行ったとしても、それはあくまでもこちら側視点での想定であり、最終的には顧客がテストをしてOKを出さなければ、使えるシステムとは言えません。

　システム稼働前には、必ず顧客側の検証フェーズが必要です。受入テストとかユーザーテストとか呼ばれるフェーズですが、スケジュールが切迫すると、これを割愛したり、短期間に圧縮したりしようとしがちです。しかし、そうした事情でこのフェーズをはしょって稼働したことで、「こんなはずじゃなかった」と顧客の不満が爆発しても、稼働後に後戻りするのは難しくなります。したがって、このフェーズも軽視することなく、最終品質を確保する重要なフェーズととらえるべきでしょう。

　このフェーズはあくまでも顧客側主体での作業となりますが、「では明日から皆さんでテストしてください」と言っても通常は、難しいと思います。ただ「お願い」と放置するのではなく、短期間でも効率よくテストが進むように、開発側の立場から積極的にサポートすることが現実的であり、最終的な品質を確保し、満足度を向上する方策だと思います。

　その1つの方法として、ユーザーテストフォーマットをサンプル入りで提供することが挙げられます。その後、業務単位にこのユーザテスト仕様書作成の担当割りを行う、期限までに記入してもらう、レビューを行う、そしてテストを実施するといった流れで進めていきます。

ユーザテスト仕様書の使い方

　顧客の実施するテストですから、いかにシンプルにわかりやすいフォーマットであるかがポイントとなります。図2を見てください。これが「DUNGEON」で使用している「ユーザテスト仕様書兼報告書」です。

　ユーザテスト仕様書兼報告書のフォーマットはこちら（http://www.thinkit.co.jp/images/article/140/5/14052.zip）からダウンロードできます（14052.zip/7 KB）。

　顧客が行う業務主体で、どの画面で何の作業を行うか。そのテスト結果がOKかどうかを一覧形式で記載していくだけの、シンプルなフォーマットになっています。これにサンプルを記載して渡してあげることで、顧客が担当者ごとに行っている業務単位のテスト仕様書を作成してもらうことができます。

　「DUNGEON」では結合テスト仕様書も業務主体なので、それをそのまま渡せばいいのでは？という意見もあります。しかしシステム外の手順も交えて、担当者の業務が最初から最後まで一貫して行えるかどうかの確認が必要であること、それを渡してしまうと、受動的にこちらと同じ観点でテストしてしまうことなどから、あくまでも別ファイルとして、顧客に考えて記載してもらうことが大切なのです。結合テスト仕様書の業務手順は、参考にとどめておいてもらうほうがよいでしょう。

　また、担当割りも手伝うとよいでしょう。どの業務を誰が担当しているかによって、どの仕様書を作成するかを割り振りましょう。割り振りは顧客側のプロジェクトリーダーでも可能かもしれませんが、「いつまでに」という期限は、開発側のほうが全体スケジュールの中で適切に設定できるはずです。顧客の通常業務も考慮しながら、プロジェクトが滞りなく進む期限設定を手伝いましょう。その際、「ユーザテスト仕様書一覧」を使用してみてください。誰がいつまでに作成し、テストをいつ実施するかなどを決められるフォーマットとなっています。