「受け入れテストってなんだろう…」
「受け入れテストと他のテストの違いは…？」
「受け入れテストって外注化できないのかな…？」
など受け入れテストについて疑問を持たれている方は多いでしょう。この記事では受け入れテストの概要、注意するポイント、外注化を中心に説明していきます。
受け入れテストについて理解することで、他のテストとの違いや受け入れテストの重要性を把握できます。システム関連の業務をする上で役立てたり、指示をするときに必要になったりします。
また、外注化するメリットを知ることで作業の工数を減らしたり、テストの精度を上げたりすることができます。
システムの改修や新規開発を考えているシステム担当者の方は、理解すれば業務の幅が広がります。ぜひ最後まで読んで、仕事に活かしてください。
受け入れテストとは
受け入れテストとは、開発されたソフトウェアなどのシステムが、発注者の要求通りに動作するか確認するためのテストを指します。
基本的に発注者側が実際にテストを行い、疑問点や不具合があればシステムを開発した受注者側に問い合わせする流れになります。
実際に運用する前の最後のテストとして受け入れテストは行われ、ここで不具合や疑問点などをすべて洗い出しておくことが目的です。
また、受け入れテストは発注者が他の業者に委託することもできます。作業の工数を減らしたい場合や精度の高い受け入れテストを行いたい場合は、外部の専門業者に委託することを選択肢に入れることをおすすめします。
受け入れテストの目的
先述の通り受け入れテストは、開発されたソフトウェアなどのシステムが発注者の要求通りに動作するのかをテストすることです。最終テストを実施することで、成果物として適切かどうか、見極めることが受け入れテストの目的です。
発注者が実際にシステムを動かしてみて不具合や疑問点があった場合にシステム開発側に問い合わせ、疑問や不具合を解消をしてきます。開発会社との契約にもよりますが、納品した後の修正を受け付けない契約や企業もあるため、しっかりと最終確認を行い、要望通りのシステムであるか確認することが大切です。
受け入れテストを行うタイミング
受け入れテストが行われるのは基本的に本番リリースの直前です。従って、受け入れテストが行われた後に本番稼働が行われ、実際にシステムが運用されるという流れとなります。
ただし受け入れテストが最後に行われるとは限らず、すでにインストールしているソフトウェア、開発中のソフトウェアと結合する時点で行われることもあります。
運用テストとの違い
基本的に運用テストと受け入れテストの違いはこちらです。
・運用テスト
開発者の作成したテスト計画書とテスト仕様書、テストデータを用いてテストを行います。テスト環境の定義が妥当か、開発者側の責任範囲の設定が適切かについて確認しましょう。
応答時間、処理時間、障害発生時の動作やエラー処理手順、障害対策フロー確認についても運用テストで見極めることができます。
・受け入れテスト
ユーザーの作成した要求仕様書に従って、要求定義書が作成されます。その際、運用環境や想定される動作を考慮し作成されます。その後、要求仕様の内容が実際に正しく反映されていることをユーザー側が判断する必要があります。そのため、検収の判断として受け入れテストを実施します。
この受入テストは、大規模なシステムや複雑なシステムに多く取り入れられています。
受け入れテストとその他のテストとの違い
受け入れテストとその他のテストの異なる点は、システムの発注者側が行うか、受注者側がテストを行うかです。受け入れテスト以外のテストは、開発者側が開発環境でテストを行い不具合を検出します。一方で受け入れテストは、先述の通りシステムの開発を発注した会社が、その会社の環境で行うのです。
ここからは、受け入れテストではないその他のテスト（コンポーネントテスト、結合テスト、システムテスト）の詳細について説明していきます。
コンポーネントテスト
コンポーネントテストとは、別名単体テストと呼ばれており、テスト工程の最初に行われるテストとなります。コンポーネントテストの目的は、モジュール単体で正しく動作するか、想定通りのエラーが発生するかどうかを確認することです。
大きく正常系、異常系のテストに分かれており、正しい値が入力された場合は予想した結果が返されるかどうか、正しくない値が入力された場合でも、予想した結果が返されるかどうかを確認します。この時点で発覚したバグや不具合は修正し次の開発工程へ進みます。
結合テスト
結合テストはモジュールを組み合わせて動作させたときに、正しく動作するのかをテストします。モジュール間でやりとりするデータの整合性すなわち、モジュール間インターフェースの整合性について詳細にチェックします。基本的に上位モジュールから順にテストを行い、動作に問題がないかどうかを確認します。
システムテスト
システムテストとはシステムが設計仕様を満たしているかどうかをテストします。外部設計、内部設計工程の誤りの発見を行います。
システムテストでは主に以下のテストが行われます。
・機能テスト
仕様で定められた機能がすべて備わっているかどうかをテストします。
・性能テスト
仕様で定められた性能（レスポンスタイム、スループット）が出るかテストします。
・負荷テスト
負荷をかけた場合でも正しくテストできているかをテストします。
受け入れテストで注視するポイント
受け入れテストはテスト工程において最後に実施する工程です。開発段階で多くのテストを実施しエラーなどがない状態で、実際に稼働する環境下にシステムを移し、正常に稼働するかをテストする流れとなります。
ここからは受け入れテストを実際に行う際に注視するポイントを説明していきます。
各機能の動作
受け入れテストでは発注者のニーズを満たしているか、またリリースする環境でも想定通りに稼働するかどうか、仕様通りに動作するかなど機能的なテストを行うことが重要です。
各機能のテストは受け入れテストの前に行ってきたコンポーネントテスト、結合テスト、システムテストの中で確認されているはずですが、発注側の要望に応えられているか受け入れテストの段階で発注者側が最終的に判断する流れとなっています。
変更した箇所
受け入れテストでは新規で作成したシステムのテストだけではなく、これまで運用していたシステムを改修し、テストを行っていく場合があります。
その際は新しく機能を追加した箇所、すでにある機能を改修した箇所、これまで存在していた機能を削除した箇所をテストしていくことになります。
また、システムが複雑になると変更した箇所とは、別の箇所に影響が出るケースもあり、システムの改修を行なっていない部分に不具合が発生していないか（デグレ）検証するテストも行わなければなりません。忘れがちですが、これもしっかりとテストし確認することが大切でしょう。
テスト環境
受け入れテストを行う際、実際の環境ですぐにテストを行うのではなく、テスト環境を用意することを忘れてはいけません。
実際に稼働する環境でテストを行うと、不具合が発生したときに、現在運用しているシステムに影響が出てしまい、ユーザーの信頼を失う可能性があります。
そのため、本番に近い環境であるテスト環境でテストを行なわなければなりません。テスト環境と本番環境の大きな乖離がある場合、本番環境で稼働したときに重大な障害につながる場合があるため注意しましょう。
業務シナリオ
業務シナリオとは、開発したシステムの実際の使われ方を想定したものを指し、ある業務をシステム上で行ったときの流れを業務シナリオと呼ぶのです。
受け入れテストのシナリオ作成は、実際にユーザーが使用している前提で作成しなければなりません。ユーザーが日々行っている業務、週末の処理、月末の処理を想定してシナリオを作成し、テスト環境でテストします。
そのため、ユーザーが日々行なっている業務を細かく洗い出し、シナリオを作成しておく必要があります。いざ本番稼働した際に、「この業務のテストが抜けてしまっていた…」とならないようにシナリオの内容を洗い出しておきましょう。
連携システムの挙動
受け入れテストではこれまでテストしてきたシステムと連携しているシステムも想定通りに動作するのかを確認する必要があります。開発したシステム単体で不具合が生じなかったとしても、他のテストと連動させることで不具合が発生する場合があるからです。
開発したシステム単体だけを見るのではなく、連携しているシステム全体で運用ができるかどうかを見ていきましょう。
受け入れテストの実施方法とは
ここからは、実際に受け入れテストを分解して見ていきます。以下6種類のテストをそれぞれ解説します。
機能テスト
機能テストとは、それぞれの機能の仕様をすべて網羅したシナリオに従って、本番環境でも問題なく動作するのかを確認するテストとなります。
システムによって規模も違うため、テストする機能も変わってきますが、主に新しく改修した機能や新規で開発した機能を重点的にテストすることになります。
また、改修した機能に関連する他のシステムに影響がないか確認するテストも必要になります。
疎通テスト
疎通テストとは、システム間でリクエストとレスポンスが成立するかを検証するテストです。例えば、ネットワークを経由するシステムA、システムBでデータの行き来が可能かどうか、レスポンスの時間はどれくらいかかるかを確認するテストです。システム同士の連携するためのテストとなります。
性能テスト
性能テストは、実際のユーザーの利用に耐えられるかを検証していきます。意図的にサーバーのアクセスに負荷をかけ、実際に想定される以上の負荷をかけても問題ないことを確認します。万が一のことも考え、想定以上の負荷をかけるのです。性能テストはシステムテストですでに確認済みであることも多く、優先順位は低くなっています。
回帰テスト
回帰テストとは、リグレッションテストや退行テストとも呼ばれます。
今回改修した機能が、既存の機能に影響されていないかを確認するテストです。バグを修正したときに、今まで正しく動作していた機能がエラーを起こさないか、バグがでないかといったことを確認します。
セキュリティテスト
悪意のあるユーザーにシステムが攻撃されても問題がないか、また攻撃されにくくなっているかを検証するテストです。入力される値に対して攻撃コードを入れて実行します。セキュリティテストは本番環境に影響が出ないテスト環境で行うように注意してください。
ユーザビリティテスト
開発されたソフトウェアで実際に業務をおこなったり、シナリオを想定してユーザーの操作感や使用感を検証したりすることがユーザービリティテストになります。
実際に日々行われている業務から、週末のみ行われる業務、月末のみ行われる業務など、稼働した際に想定されるシナリオを全て網羅しテストを行う必要があります。
ここでシナリオの抜けが発生してしまうと、本番稼働した際に大きな障害につながってしまう危険性があります。
受け入れテスト外注化が可能である
受け入れテストの内容や重要性をこれまで説明してきました。しかし、スケジュール、コストの面で最終テストである受け入れテストを省いてしまう、または疎かにしてしまうケースも少なくありません。いくらシステム開発を発注した会社に丁寧に教えてもらっても、自社で受け入れテストができる会社は少ないでしょう。
重要なのにも関わらずテストを蔑ろにしてしまうと本番稼働などで重大なインシデントにつながる可能性があります。そこで提案したいのが、受け入れテストを外注化するという選択肢です。
受け入れテストに慣れていない発注者がテスト実行するより、専門に受け入れテストを行なっている企業にテストを委託すれば、コストも下げることができ、また精度も担保した上でテストすることができます。
まとめ
この記事で説明してきた内容をまとめると以下のとおりです。
-
- 受け入れテストは本番稼働前に行う最後のテスト
- 受け入れテストは他のテストと違い、発注者側がテストを行う必要がある
- 受け入れテストで注視するポイント
- 受け入れテストの実施方法
- 受け入れテストを外注化するという選択肢も考えるべき
受け入れテストは重大なテストであるため、確実に行う必要があります。受け入れテストを専門的に行なっている企業にテストを外注化すれば、安全確実なテストを実現させることができるでしょう。
株式会社エイチビーラボでは、ベトナムに特化したオフショア開発サービスを提供しております。受け入れテストには豊富な実績があります。クラウドやITインフラ、システム関連でお困りの方は、ぜひお気軽にお問い合わせください。ご相談から、開発、運用まで親身にサポートいたします。
