コラム
ソフトウェア開発において、テストの実施は品質を担保するうえでも重要な工程です。 ソフトウェアテストは確認対象の粒度によって以下の4つの段階（レベル）に分けることができます。
・コンポーネントテスト（単体テスト、ユニットテスト）
・結合テスト
・システムテスト
・受け入れテスト
本記事ではそのような「受け入れテスト」に注目し、重要な考え方と実施の際に気をつけるべきポイントについてご紹介します。
受け入れテストでは、ソフトウェア開発などの発注を行った側が実際の運用環境またはそれに近しい環境で、使用されるプロセスに沿ってソフトウェアを使用します。その結果を受けて、発注側のニーズを満たしているかどうかや、納品後またはリリース後にソフトウェアが運用可能な状態にあるかどうかなどを検証します。
受け入れテストのなかで、仕様通りに動作するかなど機能的なテストを行うことはもちろん必要ですが、ソフトウェアを介して実際の運用環境で使用することを想定して検証します。例えば、特定の画面でエラーが発生した場合、エラーを見たユーザーが次の行動に移れるかなどがあげられます。
なお、受け入れテストの計画はプロジェクトの初期工程で行います。受け入れテストをプロジェクトの初期工程において計画することで、ソフトウェアの完成形を発注者側と供給者側の両者で共通認識をもちやすくなります。結果的に、コンポーネントテストや結合テストなどの他のテストレベルの計画を実施しやすくなるというメリットもあります。
このような受け入れテストは、実際の運用環境を念頭に置いたうえで発注者側が計画し実行することが理想的です。しかし実際には、発注者側で受け入れテストに対するリソースが不足している場合や、ユーザーひとりひとりの使用状況を網羅したテストの計画や実行が難しい場合などが考えられます。
そのため、発注者側の代表者数名が担当したり、第三者のパートナー会社へ依頼したりすることにより受け入れテストを実施するケースもあります。
前述の通り、受け入れテストはテスト工程において最後に実施する工程です。すでに開発とテストが最終段階に入っているソフトウェアを、開発を発注した側が実際に使用する環境やそれに近い環境で検証を行います。
仕様書に沿ったソフトウェア開発であったとしても、実際の利用環境においてそのソフトウェアが機能しなければ、利用されなくなってしまう可能性やそのソフトウェアを利用した業務が進行しない可能性などもあります。
そのような事態を防ぐため受け入れテストを行い、「発注側が求めている要件は満たしているか」や、実際に使用するユーザーや場面を想定したうえで「快適に利用できるか」「使用するうえで不都合はないか」など実際の利用を見据えた検証結果を得てから、それを基に最適化することが重要です。
出典：株式会社SHIFT、日経BP「駄目パターンに学ぶ 失敗しない ソフトウェアテスト 実践ノウハウ」114ページ 図3 「Ｖ字モデルを用いたテストレベルの説明」を基に作図
ソフトウェアの品質を保つためには、各開発工程に対して行うテストを明確にしておく必要があります。V字モデルを参考にできるプロジェクトであれば、漏れなどを減らすことができます。
V字モデルとは、開発の上流工程とテスト工程を対に並べたモデルです。上流工程ですり合わせた粒度を流用できるため、共通の認識が得やすくなります。
V字モデルにおいて、受け入れテストとシステムテストは要件定義と対になります。
要件定義の際に決めた「システムをつくった目的」「特定の業務の処理が簡略化されること」「ある処理の機能をつくる」といった大まかな区分が達成されているかを確認します。
改めて受け入れテスト以外のテストレベルでテストしたい領域を確認してみましょう。
コンポーネントテストは、機能ごとに独立したプログラムを単体でテストする段階です。プロジェクトによっては、単体テストやユニットテストといわれているケースもあります。機能A、機能B、機能Cのように各機能が正常に動作するかを検証します。
例えば、
機能A:：パスワードが伏せ字で表示される
機能B:：パスワードが送信される
などです。
結合テストは、コンポーネントテストの後に実施されるテストレベルです。
機能ごとに動作するようになった部品を組み上げてから、一連の機能が動作するかどうか確認します。
ユーザー認証の一部を例にあげてみましょう。
・入力フォームが表示される（画面X）
・パスワードが伏せ字で表示される（機能A）
・パスワードが一致した場合認証に成功する（機能B）
このように「画面X=>機能A=>機能B」を一括りにして表示やデータの入力が仕様通りに動作するかテストを行います。
システムテストでは、あらかじめ実務で想定されるようなシナリオを設計しておく必要があります。そのうえで実際に本番環境で使用するハードウェアを利用したり本番と同等の環境で動作させながら行います。
例えば、ユーザーがパスワードを忘れてしまったと想定しテストを行ったり、実際にアクセスが集中することを想定して負荷をかけるなどのテストを実施します。
テストタイプ別に、受け入れテストを実際に実施する例をご紹介します。
テストタイプとは、テストで確認したい目的別に分類したものです。一般的によく用いられる代表的なテストタイプは以下の6種になります。
（テストタイプはさまざまなものがありますが、ここでは一部を紹介しております）
・機能テスト
・疎通テスト
・性能テスト
・回帰テスト
・セキュリティテスト
・ユーザビリティテスト
受け入れテストでは、実際に使用が想定されるユーザーが中心となってソフトウェアが存在する目的を達成できているかを確認することが重要です。そのため、「機能テスト」や「ユーザビリティテスト」を主に行います。
反対に、開発者が中心となって行う「性能テスト」「疎通テスト」はあまり行われないケースが多いです。なぜなら、前のテストレベルでほとんど完了していると考えられるためです。
これらをふまえて、それぞれのテストタイプを確認してみましょう。
ソフトウェアの機能が、上流工程やプロダクトマネージャーが決めた仕様通りに動作するか検証するテストです。
実際の利用の流れやデータを使用して、ソフトウェアを操作するテストを行います。
特に、例外処理やエラー発生時の挙動に注目して機能を確認するとよいでしょう。なぜなら、受け入れテストにおける機能テストでは、例えば実際にユーザーがエラーメッセージを確認して次の行動がとれるかという視点が重要となるためです。
エラーを発生させるための条件やテストデータをあらかじめ準備しておくと効率のよいテストが可能です。
システム間でリクエストとレスポンスが成立するかどうかを検証するテストです。
例えば、ネットワークを経由するシステムA、システムBでデータの行き来ができるか確認するようなテストが該当します。
受け入れテストを実施するまでの前のテストレベルで、すでに該当する内容が完了されているケースがほとんどです。
受け入れテスト以前のテストレベルにおける疎通テストにてデータの行き来などを確認できていなければ、ユーザーが実際にソフトウェアを操作することはできないためです。
実際のユーザーの利用に耐えられるかどうか検証を行います。
システムテストで実施されているため、受け入れテストにおいて優先度は最後と捉えるケースがほとんどです。もし行う場合は、同時アクセスといったケースを検証します。
回帰テストは、リグレッションテストや退行テストとも呼ばれます。
システムが複雑になってくると変更を行った場所とは別のところに影響が出るケースもあるため、システムの改修を行っていない部分に不具合が発生しないか（デグレ）検証するテストです。
受け入れテストでは、特別に意識して回帰テストを実施する必要はありません。
回帰テストは、デグレの有無を検証するために実際にソフトウェアを操作して実施します。そのため、内部構成までは把握していないと考えられるユーザーがソフトウェアを操作することで、回帰テストを代替しているといえます。
悪意のあるユーザーにシステムが攻撃されても大丈夫かどうか、検証を行うテストです。パラメータに対して、攻撃コードを入れて実行します。セキュリティテストは、必ず本番で使用するデータから切り離された環境で行ってください。
実際のユーザーが利用する範囲で不正な値を入力して、エスケープ（ここでは入力値を打ち消すという意味）されるかどうかを確認します。
ソフトウェアで実際に業務を行ったり、シナリオを想定してユーザーの操作感や使用感などを検証したりすることなどが、ユーザビリティテストです。
ユーザーの使用感を把握することを目的としたユーザビリティテストは、実際の運用環境を想定したうえでソフトウェアが使用しやすいかどうかなどのテストを依頼します。
実際のユーザーがソフトウェアを操作することで使用者としての素直な意見を集められるため、受け入れテストの品質を向上させることにつながります。
例えば、あるソフトウェアにおいてデータ入力に不備があった場合に「入力情報が不足しています」というエラーメッセージのみが表示されるというシナリオがあるとします。この場合、ユーザーは入力箇所のどこにエラーが発生しているのかが分からずに、カスタマーサポートへ問い合わせなどをすることが考えられます。
しかし、あらかじめ「どの入力にエラーがあるのかを示すエラーメッセージ」が表示されるシナリオであれば、ユーザーは自身で問題を解決することができる可能性もあります。
そのため、受け入れテストでは「どの入力にエラーがあるのかをユーザー自身が把握し、対処できる」ところまでをテストする必要があります。
ソフトウェアテストは4つのテストレベルに分割されますが、受け入れテストはテスト工程の最後に実施される工程です。開発したソフトウェアがユーザーのニーズを満たしているかを確認するために、主に発注側が実際にソフトウェアを使用した際のユーザーの動きまでを含めてテストを行います。
特にエラー発生時にユーザーが適切に次の行動に移せるかどうかまで確認しておくことで、リリース後のスムーズなソフトウェアの運用につながるため、テスト工程において受け入れテストは重要な工程になります。
