プロが教える超ざっくりシステム開発～受入テスト編

さて今回は
「プロが教える超ざっくりシステム開発」
の受入テスト編となります。
このシリーズにおいては、今回で最終回となります。

前工程の総合テストをまだご覧になっていない方はこちらをご覧ください。

受入テストって誰がやるの？

それは発注者であるお客様自身です！

受入テストは、実際の利用者（発注者）が実施するテストで、納品されたシステム（ソフトウェア）を受け入れてもよいか否かを判定します。
発注者の検収行為の一環となります。
この受入テストで問題ないことを確認いただいた後に、我々からご請求をさせていただくことになります。

ちなみに受入テストは、UAT（User Acceptance Test）とも呼ばれています。

何をどこまでやればいいの？

これについては、何をどこまで確認したら良いのかお客様は悩まれることが多いかと思います。
時間も限られていますし、全部の確認をすることは難しいですよね。
しっかりテストケースを作成されて、じっくり確認されるお客さまもいらっしゃいますし、
一通り動作を確認するだけのお客様もいらっしゃいます。

以下のことから、普通に動作確認しても問題は発見できないケースが多いです。

　・基本的な操作・仕様については工程を進める中でお客様に確認しながら進めている
　・各工程で品質を作りこんでいる
　・テスト工程ではかなり細かいところまで確認している

現実的な時間の制限もありますので観点の工夫が必要かなと考えています。
ではどのような観点で確認すればいいのでしょうか？

　・難しい機能もしくは難しい業務
　・重要な機能もしくは重要な業務
　・イレギュラーな業務やデータパタン
　・本番データ（個人情報、機密情報など開発ベンダーに貸し出していないデータ）を使う

このような観点で効率よくご確認いただくことをお勧めいたします。
もちろん時間が許すのであれば、隅々までご確認いただくのがベストかとは思います。

短い期間ですべての不具合を発見できなかったら・・・

受け入れテストは、システム開発を開発ベンダーに外注して納品された時に発注者の本来の目的や意図通りに稼働するかどうかを検証することです。
受入テストで合格を出すということは、検収OKということになります。

ここで不具合が取り切れなかったら・・・・
と不安になるかもしれませんが安心してください。
仮にシステム利用後、不具合が見つかった場合でも請負責任として無償で対応いたします。

ですので、受入テストでは上記に記載したような観点で実施いただくことをお勧めいたします。

さいごに

これまでシステム開発の主な工程について説明してきましたがいかがでしたでしょうか。
これからも、システム開発についていろんな観点でブログを書いていこうと思います。
引き続きよろしくお願いいたします。