お役立ち記事
発注者がシステム開発を依頼する前に知るべきこと7選 No6
受入テスト・納品されたシステムの検証方法
システム開発工程を知る
(システム開発の流れ)開発中の関与と役割分担では開発の工程と発注側企業の役割について解説しました。
今回は納品時に発注側企業が行うシステムの受入テストについて解説します。
受入テストとは? 目的と実施タイミング
受入テストとは、ベンダーによって開発されたシステムが発注側企業の要求通りに動作するかどうかを確認するテストです。
このテストは、ベンダーではなく発注側企業が行います。ベンダー側でのテストが完了し、システムが納品されたタイミングで実施します。
「納品前にベンダー側でしっかりテストしたんでしょ?
それならこちらでやらなくてもいいのでは?」
お客様からそのようなお声をいただくことがありますが、発注側企業による受入テストは必須です。その理由は2つあります。
受入テストの目的は、「運用」の観点から行うもの
ベンダーが行うシステムテストと受入テストでは、目的が異なります。ベンダーが行うのは、システムが設計通りに動作するかどうかを確認するためのテストです。対して発注側が実施する受入テストは主に「運用」の観点から実施するものです。
例えば「提示した要件がそもそも間違っていた」「マスターデータが間違っていた」というような、発注側のミスによる不具合が多々見つかることと思います。
受入テストで見つければ、その時点でベンダーに対応してもらうことができますが、リリース後に発覚すると追加費用が発生するだけでなく、実際の利用者に迷惑がかかることになってしまいます。したがって本番稼働前にシステムを万全な状態にするために、受入テストはしっかり行いましょう。
システムは誰のもの? リリース前に仕様をしっかりと把握しておこう
システムが納品されリリースとなってから、ベンダーに対して「この機能ってどういう使い方でしたっけ」「どういう仕様でしたっけ」という質問を投げかける発注側企業が多くいらっしゃいます。
もちろんベンダーとしては誠実に回答しますが、やはりプロジェクト成功のためには、仕様を把握した上で運用をスタートすべきでしょう。
システムはベンダーのものではなく、発注側企業のものです。受入テストでリリース前に機能や仕様をしっかりと理解しておくようにしましょう。
受入テストの種類
次に、受入テストの種類について解説します。企業によって呼び方は異なりますが、おおよそ次の4種類に分けられます。
機能テスト
システム間連携テスト
システムテスト
現新比較テスト
それぞれの内容と目的を解説します。
機能テスト
受入テスト4種類の中で、最初に行うのが「機能テスト」です。要件定義で定めた機能がすべて実装されているかどうかを確認する目的で行います。システム全体を見て、機能に漏れがないかを総点検します。機能要件一覧の資料を流用して表などを作り、一つひとつ確認していくのがいいでしょう。
システム間連携テスト
出来上がったシステムと連携するシステムの間で、データ連携がきちんとできるかどうかを確認するテストです。
システム間の連携に起因する障害は、よくあることの一つです。必ずしもベンダーのミスが原因とは限らず、むしろ連携するシステム同士の不整合によって起きることが多いです。
正しくデータ連携されているかどうかを検証するには、「データが正しいフォルダに正しいファイル名で格納されているか」「データの取り込みタイミングは適切か」「各データの項目は正しくセットされるか」などいくつかの項目に沿って確認するのが有効です。
システム間連携テストを作成、実施するには、専門知識が必要です。IT部門など、知見のある人に依頼して作ってもらうのがいいでしょう。
システムテスト
ユーザー目線で実際の業務フローに沿ってシステムを使用し、問題なく運用できるかどうかを確認するテストです。
シナリオテストで重要なことを3点解説します。
- 各シナリオパターンのテスト観点を明確にする
- ユーザーがとるであろうシステム上の行動を網羅する
- テストには本番データを使用する
シナリオテストでは、実際の業務の流れを再現するシナリオを何パターンも作り、各シナリオに沿って確認を行います。
シナリオ作成にあたっては、パターンごとのテスト観点を明確にすることが重要です。例えばECサイトでいうと、「ユーザーが新規登録して商品を購入し、カード決済すると、商品はお客様に届くか」「ユーザーが新規登録して商品を購入し、決済後にキャンセルすると、注文は取り消されるか」といったことをテストする必要があるかと思います。そうした確認すべき観点をすべて洗い出して、シナリオのパターンを作成していきます。
シナリオテストでは、ユーザーがとるであろうシステム上の行動を網羅するようにします。
ユーザーが決められた操作方法でシステムを使うとは限りません。イレギュラーな操作をしてもエラーになったり不具合が起きたりすることのないよう、あらゆることを想定してシナリオを作り、テストをしましょう。
テストの際にはできる限り本番データを使用します。ベンダーがテスト用データを使って確認したときは問題なかったのに、本番のデータを入れたらエラーになった、というのはよくある話です。本番に近い環境でテストすればこそ、仕様の思わぬ落とし穴に気づくことができるのです。
現新比較テスト
現行のシステムがすでにある場合には、現行システムと新システムの出力結果を比較し、問題ないかどうかを確認します。このテストによって、正しい仕様に仕上がっているかどうかの答え合わせができます。
例えば「1000の受注のうち、5件だけ請求金額が間違って表示される」「500名の社員の、2名分の給与データだけ金額がおかしい」というような事象が起きないかを確認するテストです。
イレギュラーなケースで発生する障害を見つけるテストなので、データ全件を確認する必要があります。何パターンかのサンプルを比較するだけでは意味がありません。
現新比較を全件でテストすることによって、テストから漏れたイレギュラーの不備を検出することができるほか、マスターデータの検証も可能になります。

受入テスト計画書の作り方
受入テストはどのような手順で行えばいいのでしょうか。
受入テストは社内の関連部門などに協力してもらって実施するため、「受入テスト計画書」を作成し、それを関係者に共有しながら進めます。計画書を作成するのはベンダーではなく、発注側企業です。
以下のステップで必要項目を決めていき、それらを計画書に落とし込みます。
- 受入テストの目的を明確にする
- 受入テストのスケジュールを定める
- 受入テストを実施する範囲を明確にする
- 受入テストを作成する
- 受入テストに必要な環境を準備する
- 参加者リストをまとめておく
- 実施場所を確保しておく
- 利用端末を確保しておく
- システムのテスト環境と参加者用のアカウントを用意しておく
- 役割分担を決めておく
「受入テスト」は、一般的に耳慣れない言葉なのではないでしょうか。テストを担当するのは、開発に携わったことのない人も多いと思います。まずは「受入テストとは何か」から説明するようにしましょう。
その上で、計画書の冒頭には「受入テストの目的」を明記します。
受入テストの目的とは「実際にユーザーがシステムを使用した際に、業務を遂行できるかどうかを確認すること」です。また、「受入テストをもって検収完了となるので、不具合などはこのフェーズですべて洗い出し解決することが必要」ということも記載しておくといいでしょう。
受入テストの日程を明確にし、スケジュールを作成します。
このとき、テスト期間を甘く見積もらないことが重要です。先述したように、受入テストには「機能テスト」「システム間連携テスト」「シナリオテスト」「現新比較テスト」の4種類があり、それぞれにかなりの時間と労力を要します。
さらに、テストデータの準備や不具合の調査、関連部門やベンダーとの調整など多くのタスクもあるため、これらを想定せずに期間を設定してしまうと、テストが進むにつれてスケジュールが遅れていく可能性があります。
精度の高いスケジュールを設定するためには、各タスクを作業レベルに細分化することをおすすめします。実際に行う作業を全て洗い出した上で、期間を設定していきましょう。そうすることで無理のない、現実的なスケジュールを定めることができます。
受入テストで確認する業務とシステムの範囲を明確にします。
上記「受入テストの種類」で紹介した4種類のテストを作成します。各テストの目的に沿って、テスト項目と内容を作成しましょう。
受入テストは社内関連部門に協力してもらうこととなります。テスト当日に慌てることのないよう、以下について準備しておきましょう。
どのテストを誰が担当するか、役割を決めておきます。スケジュール表に担当者名と役割を記載しておくといいでしょう。
受入テストは、原則として実際にそのシステムを利用するメンバーに担当してもらうようにします。IT部門はそのサポートをする立場で参加してもらうのがいいでしょう。
以上、1〜6で決めた内容を受入テスト計画書としてまとめておきます。

今回のまとめ
今回は受入テストについて解説しましたが、いかがでしたでしょうか。
発注側企業にとって負担の大きい工程なので、大変そうだなと心配になった方もいるかもしれません。
しかし、受入テストは避けては通れない、システム開発の最終工程です。もし受入テストで不具合を発見できなかった場合は、リリース後の障害となってユーザーを巻き込むような問題に発展してしまいます。そのようなことにならないよう、発注側企業としてあらゆる観点からシステムを検証しなくてはなりません。
自社のプロジェクト成功のためにも、責任を持って行いましょう。
次回は「システムの運用・保守とシステム導入効果の測定」について解説します。
\実務にお役立てください!/
-
発注者必見の書き方とサンプル例
RFP(提案依頼書)テンプレート