連載コンテンツ

  1. Qbook+
  2. 連載コンテンツ
  3. 「受け入れテスト(UAT)」の基礎知識と勘所

「受け入れテスト(UAT)」の基礎知識と勘所

2018.08.22 堀 明広
「受け入れテスト(UAT)」の基礎知識と勘所

システムの稼働直前に行う受け入れテスト(UAT:User Acceptance Test)は、システムがトラブルなくスムーズに運用できるかに影響する重要なテストですが、十分な時間をかけられないことも少なくありません。限られた時間の中で、効率良く受け入れテストを実施するためには、どのようにすれば良いのでしょうか。
今回は、受け入れテストの基礎知識と、受け入れテストの効率化を図るためのポイントをご紹介します。

「受け入れテスト」とは

そもそも、受け入れテストとはどのようなものなのでしょうか。
JSTQB(Japan Software Testing Qualifications Board)が公開している「ソフトウェアテスト標準用語集 日本語版 Version 2.3.J02」の定義を見てみましょう。

受け入れテスト(acceptance testing): システムが、ユーザのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト。このテストにより、システムが受け入れ基準を満たしているかどうかを判定したり、ユーザ、顧客、その他の認可団体がシステムを受け入れるかどうかを判定したりすることができる。
工場受け入れテスト(factory acceptance testing): コンポーネント又はシステムが要件を満たすかどうかを確認するために、製品開発の場所で供給者組織の従業員により実行される受け入れテスト。要件には、ソフトウェア要件だけでなく、ハードウェア要件も含む。

サイト受け入れテスト(site acceptance testing): ユーザや顧客が自分のサイトで実施する受け入れテスト。コンポーネントやシステムが、ユーザや顧客のニーズを満たしているかどうか、ユーザや顧客のビジネスプロセスに適合するかを判定するために実施する。通常、ソフトウェアだけでなく、ハードウェアも含める。

引用元:ソフトウェアテスト標準用語集 日本語版 Version 2.3.J02

このように、一口に受け入れテストと言っても色々なものがあります。上記の定義を俯瞰してみると、アウトソーシングしたソフトウェア・システム開発の成果物を、「どんなシチュエーションで、何を目的に行うか」が共通したポイントと言えるでしょう。

本稿では、「システムの稼働直前に行う受け入れテスト」を例に取って解説していきます。

「受け入れテスト」はどこまでやるか

balance

受け入れテストの悩みどころとして、「受け入れテストをどこまでやるか」があります。

外注した成果物に対し、自社開発と同じように発注元できっちりテスト設計して受け入れテストを行うのであれば、品質面のケアはある程度確保できるかもしれません。しかしそれではテストケースが多くなってコストがかさみますし、開発元でテスト済のものに対して、受け入れテストでまた同じようなことを実施してはムダが生じてしまうことになります。

また現実問題として、受け入れテストに十分な時間を割ける余裕が無い、という状況にあるところも多く、受け入れテストの件数を絞って出来るだけ少なくしたい、という要求が生じることになります。

「出来るだけしっかりテストしたい」 「出来るだけテストにかける時間は少なくしたい」
この相反した要求に対し、どのように考えれば良いのでしょうか。次節で解説していきます。

「受け入れテスト」で考慮すべき項目

前述したように、受け入れテストのポイントは、「どんなシチュエーションで、何を目的に行うか」です。
ここで考えるシチュエーションは、「システムの稼働直前に行う受け入れテスト」です。
それではその目的は? その目的を満たしつつ、テスト件数を出来るだけ少なくするにはどうすればいいのでしょうか?
「受け入れテスト」で考慮すべき項目として列挙してみましょう。
考えの軸は、「リスク管理」です。

特に重要な機能を優先してテストする

ここで考察しているシチュエーションは「システムの稼働直前」で、「あまり時間がかけらない」のですから、全ての機能を念入りにチェックする余裕はありません。そうであれば、どの機能をテストするのか、という観点に立てば、「特に重要な機能を優先してテストする」より他に方法はありません。
よって、ポイントは、受け入れテストする「特に重要な機能」をいかに適確にチョイスするか、ということになります。そのシステムの基幹的な機能、絶対に不具合を出してはならない機能などの軸を定め、それを関係者と合意形成することが必要になるでしょう。

「特に重要な機能」を定めたら、次に、それをどんな条件でテストするかを決めることが必要になります。「大きな漏れ抜けが無いことを確認する」という観点に立てば、通常の利用状況はもとより、例えば業務系システムで言えば定期的なイベント日などをテスト条件に採用することが望ましいでしょう。
ここでの考えの軸は、「特に重要な機能が、通常の使い方なのに誤動作してしまい、致命的な事態になってしまうようなリスクを軽減させる」というスタンスに立っているものです。

仕様変更した機能とその周辺機能を優先してテストする

ソフトウェア開発で難しいものの一つとして「仕様変更」があります。
程度の話はありますが、本来、要求や要件は変化するものと捉えるべきもので、開発側は仕様変更に柔軟に適切に対応することが求められるものです。 しかし、特に開発の途中で仕様を変更すると、開発側としては限られた時間の中でどのように機能を実装するかに傾いてしまい、設計変更が既存の設計部分への考慮漏れや対処漏れを生じさせてしまうこともあるのが実情です。
また、構成管理のミスで、仕様変更に対処済のバージョンでなく、誤って異なるバージョンをリリースしてしまうことも可能性としてはゼロではありません。
これを踏まえて、ユーザの目線で、仕様変更した機能がリクエストどおりに実装されているか、その周辺に悪影響が及んでいないかを確認すると効果的です。
ここでの考えの軸は、「仕様変更に関連した不具合が多いため、そのリスクを軽減させる」というスタンスに立っているものです。

実環境と実データでテストする

外注先では、疑似環境や疑似データを使って開発・テストを行うことが多いため、受け入れテストでは実際に運用する環境で、実際に扱うデータを使ってテストするようにしましょう。
例えば、別のシステムに接続する機能があったとしましょう。開発中は接続先をシミュレータに設定し、最終リリースでは本番の接続先に書き換える必要がありますが、これをうっかり漏らしてしまうこともあります。 こうなってはその機能は絶対に誤動作してしまうことになり、しかもそのミスを発見するのは受け入れテストしかない、ということになります。よって、開発環境と実環境の違いに着目し、そこに絞って受け入れテストを実施するというのも効果的です。
ここでの考えの軸は、「疑似環境から本番環境に移行した際の処理漏れのリスクを軽減させる」というスタンスに立っているものです。

どんなシチュエーションで、何を目的に行うか

ここまでいくつか受け入れテストで考慮すべき項目を列挙してきました。
繰り返しになりますが、「どんなシチュエーションで、何を目的に行うか」、ここが非常に大切です。そのシチュエーションでどんなリスクが考えられるか、どんな事態を回避したいのか、そのリスクに対処するには、どんな受け入れテストが必要なのか、この順番で考えるのがポイントです。

「受け入れテスト」をするから一安心、というわけではない

8607-00018-03

先に例示したものは、「システムの稼働直前」に、「受け入れテストに十分な時間を避ける余裕が無い」シチュエーションの元で、如何に妥当なテストを実施すべきか、というものをいくつかピックアップした例です。
これら例示したものは、リスクを想定してそれに沿ったテストの指針を導出した、必要最小限のものです。

当然のことながら、「受け入れテスト」の対象から外れたものは、「システムの稼働直前」よりもっと前のフェーズで検証されていることが前提になります。それは開発側で行うのか、発注元で行うのかはケースバイケースですが、もし開発側で行うとしたら、開発側で行うテストの計画を関係者で合意し、そのテストの途中経過をモニタリングすることがとても重要です。
特に、「受け入れテスト」はブラックボックステストで行うことになるでしょうから、ソフトウェアの内部構造に沿ったホワイトボックステストは開発元で行うことは必須です。契約上の制約が許せば、発注元は開発側に対し、ホワイトボックステストの計画を立案してもらい、それを実施したエビデンスと分析結果を示してもらうのを受け入れ条件にするのが望ましいでしょう。

また、使い勝手の良さ/悪さを検証するユーザビリティテストは、発注元で行うべきものですが、それは最終の受け入れテストで行うものではありません。たとえ使い勝手が悪い、システムの本来の目的から外れている、という結果が出たとしても、「システムの稼働直前」に修正するのは不可能なためです。

このように、受け入れテストを部分的に切り出して考えるのではなく、発注する機能の品質管理・進捗管理の全体を考え、その中で、受け入れテストの役割をデザインするのが大切です。

まとめ

本稿では、「システムの稼働直前に行う受け入れテスト」を例に取り、受け入れテストで考慮すべき点を、リスク管理をベースにしながら解説しました。
全体をまとめると、ポイントは、ソフトウェア開発の品質管理・進捗管理の全体を考えて、その中で、受け入れテストを、どんなシチュエーションで何を目的に行うかデザインする、ということになります。
何事においても言えることですが、「どうやるか」よりも先に、「何のために何をやるのか」、目的が大切ということになるかと考えます。

資料ダウンロード

  • 事例資料:ドキュメントインスペクション

    オフショア開発の課題と解決策、発注品質を改善したドキュメントインスペクションの事例とコツをご紹介します。

  • ソフトウェア開発データ白書記載データとの比較資料

    一般的なテストプロジェクトとバルテスのテストプロジェクトを比較した冊子です。1000Hあたりの不具合検出数、実施テストケース数などを算出し、どの程度の差があるのかを比較しております。

  • 大手50サイトの診断結果から見る最新Webセキュリティの傾向 2018年版

    バルテスがセキュリティ診断を行った50サイトにおける脆弱性傾向をまとめた資料です。どういったレベルの脆弱性が見つかっているのか、その割合はどういったものなのかなどを具体的な数値としてまとめています。

堀 明広
ライター:
堀 明広

バルテス株式会社 R&C部 担当部長 兼 上席研究員

組込み系プログラマー、ソフトウェア品質管理を経て、現職では人材育成、品質コンサルテーション、検証・分析の技術開発を担当。主な著作は「ソフトウェアテスト293の鉄則(共訳)」「ソフトウェア見積りガイドブック(共著)」「続・定量的品質予測のススメ(共著)」。論文発表・講演多数。IEEE正会員。得意分野は欠陥分析。

関連記事