開発工程の中の受入テストの説明です。
受入テストはベンダーのテストが終わった後、発注者が検収のために実施するテストです。受入テストには、システム部門の受入テストとユーザー部門の受入テストの２種類があります。
１．システム部門の受入テスト
システム部門の受入テストは、外注している場合に実施します。当然、内製している場合には実施しませんし、ベンダーに丸投げしているようなシステム部門もやりません。きちんとベンダーコントロールしているシステム部門でも小規模案件では実施しないことも多いです。
ベンダーのテスト内容をきちんとレビューしていれば、システム部門の受入テストは必ずしも必要ではなく、必要なケースはベンダーの責任範囲がテストに必要な範囲よりも狭い場合です。
例えば他システムとの連携が重要なシステムで、ベンダーの請負範囲は自システムだけの場合、他システムとの連携テストはベンダーのテスト対象となりません。その場合には、システム部門が他システムとの連携テストを実施します。
私が新卒で入った会社は、システム同士が密に連携し合っていたため、システム部門の受入テストを非常に重視していました。規模の大きい案件の場合、システム部門の受入テストを半年間も延々と実施していたこともあります。
２．ユーザー部門の受入テスト
ユーザー部門の受入テストは、自分たちの思ったとおりにシステムが作られているかを確認するためのものです。
きちんとテスト仕様書を作ってテストする場合もあれば、ユーザーが好きなようにシステムをいじる場合もあります。テスト仕様書を利用する場合、通常はユーザーはテスト仕様書なんて作れないので、システム部門やベンダーが作ってお膳立てをしてあげます。
一般的に良く言われるのが、「テストは後工程に進むほど不具合の修正で手戻りが大きくなる」というものですが、これは必ずしも正しくはありません。V字モデルを妄信して、テストの工程の本質を理解できていない人の誤解です。
テストの初期の段階である単体テストや結合テストでも、致命的な不具合が見つかって早々にユーザー部門に「ごめんなさい」を言うこともあります。
対応が難しい不具合と、発見されるテスト工程には関係がありません。
もちろんユーザー部門の受入テストでも、対応が難しい不具合を指摘されることもゼロではありません。ただ難易度の高い不具合をユーザーがテストで見つける可能性は非常に低く、ほとんどの場合は表面的な「メッセージ修正」であったり、「メッセージの出るタイミングの変更」であったり、修正量としては軽微なケースが多いです。
ただユーザー部門の受入テストは、通常、リリース間近に実施する場合が多く、不具合が出ないことを見越してリリース資産を凍結してしまう場合もあります。そういった場合、軽微な修正であっても「安全なリリース」の観点から、ユーザー部門に「ごめんなさい」をして、リリース後の対応とする場合も多々あります。
３．運用部門の受入テストというものもある
システム運用の部門が強い会社だと、この運用部門による受入テストがあります。
開発部門は「柔軟にユーザーの要望を叶えたい」という顧客満足を最優先とし、運用部門は「安定したシステムをユーザーに提供したい」というシステムの安全安定運行を最優先としているため、この性質の違いから開発部門と運用部門は水と油のように相容れません。
そのため会社によっては、この運用部門の受入テストが最大のハードルになる場合もあります。
運用部門の受入テストの観点としては、今までの運用マニュアルの中で正常にシステム運用ができるか？というものです。あるいは運用が変わる場合、変更された運用マニュアルで「誰でも」運用ができるか？というものです。
この「誰でも」という部分が非常にくせ者で、私かかつて在籍していた官公庁系の会社では、PCの電源を入れるところからマニュアルに記載しないといけませんでした。しかもその電源の入れ方も、PCの写真を貼りつけて電源の場所まで明記しないといけませんでした。
マニュアルが無いとPCの電源も入れられないような人に、運用を任せたくはないのですが・・・
【振り返り】
今回は受入テストの説明でした。
開発工程の紹介は以上となります。
