web制作やwebシステムなどをアウトソーシングしている会社は多いですよね。システムを内製ですべて作るのには、限度がありますし。
それゆえ、システム開発後、自社にて、そのシステムやwebサイトの受け入れテストをしないと、いけませんよね。
物理的な物の納品であれば、検品という内容になります。
しかし、この受け入れテストもノウハウがないと、そこそこやっかいなことになります。
そこで、今回は、その受け入れテスト（UAT）についての方法、ノウハウなどを解説していきます。
まずは、受け入れテストについての解説からします！
受け入れテスト（UAT）とは
受け入れテストは、UATと呼ばれます。UATは、User Acceptance Testの略称です。
要は、検品です。
受け入れテストは、システムが、発注者のニーズ、要件、ビジネスプロセスを満足する内容になっているかどうかをチェックするためのテストです。
ということは、受け入れテストでやるべきことは、以下の3つです。
- システム開発の要件とシステムがあっているか
- 発注者側のニーズとシステムがマッチしているか
- システムがビジネスプロセスを満たせる内容か
上記の確認ということになります。
uat 正式名称 読み方
UATの正式名称は、User Acceptance Testで、その頭文字をとって、UATです。
UATの読み方は、ユーエーティーといいます。
そのため、上述のように、UATは、
ユーザー受け入れテスト
のことを、指します。
UATは、クライアント側（発注元）が行う受入テストなので、通常は、同意語として
- 検収テスト
- 完了テスト
- 承認テスト
とも呼ばれることがあります。
uat 総合テスト 違い
UATは、ユーザー受入テストなので、総合テストとは異なります。
通常、システム開発における、テストは、
- 単体テスト
- 結合テスト
- 総合テスト
- ユーザー受入テスト
の順番で行われます。
UATと、総合テストは、そもそも、違うテストであることを認識しましょう。
総合テストは、依頼したクライアントの要望、求める要件がシステムで反映されているか、対応できているかをチェックするものです。
すなわち、システム開発の上流工程で、要件定義した内容が、開発したシステムで実現できているかを確認、テストします。
ただ、要望がかなっているだけでは、甘くて、実際に、システムの動く速度、処理速度が、現実的な運用に間に合っているかも確認しましょう。
また要件定義と適合する開発でも、そもそも、要件定義自体が間違っている可能性もあるので、そこも含めて、確認するようにしましょう！
uat 運用テスト 違い
UATと運用テストも、違うテストになります。
運用テストは、通常、総合テストと同じタイミングで行われて、先程、少し触れた、開発したシステムのスピードが運用に耐えうるものか？などをチェックします。
運用テスト(Operations Test)は、システム開発会社が行うことが多いですが、運用理解をしていないケースがあるため、現実的には、クライアントと協力して行うケースが多いです。ここがＵＡＴと異なる点の1つですね。
要件定義書に書かれている要件を満たしているだけでは、システムは使えません。現実の課題を処理できるようなレベルになっているかを、運用テストで確認していきましょう。
運用テストでは、
- 性能テスト
- 負荷テスト
- 安定性テスト
といった機能要件にはない項目の検証を行います。
ＵＡＴと運用テストでは、テスト内容が異なるので、ここも、運用テストとＵＡＴと違う点になりますね。
受け入れテスト（UAT）の目的
受け入れテスト（UAT）の目的は、基本、ちゃんと企画、設計どおりに、システムやwebサイトが稼動するか、という点になります。
そのため、システムやwebサイトの設計が最初の段階でできていないと、受け入れテスト（UAT）も機能しません。
実例として、ある広告代理店が、ユーザーが投稿したら、動画が表示される仕組みを作って欲しいと、フリーランスのプログラマーに依頼しました。
プログラマーは、消費者が、webサイトにコメントを投稿したら、そのコメントに関連するyoutubeにあがっている動画を表示する仕組みを作って納品しました。
はたして、広告代理店の担当者は、受け入れテストできるでしょうか。
言葉上は、マッチしそうですが、おそらく、広告代理店の担当者が求めるシステムではないでしょうね。
このように、受け入れテストで重要なのは、最初の設計、企画をきちんとまとめているか、まとまっているか、という点になります。
そして、それが反映されていて、現実的に動く！というのを確認するようにしましょう。
受け入れテスト（UAT）の方法
受け入れテスト（UAT）の方法は、大きくわけると３つあると思います。
- 事前にチェック表を作り、仕様と見比べて、システムを試していく
- 利用者心理で、システムを動かす。実データを使っていく
- 画面上部から機能を使っていく
各方法は、以下の各段落で解説していきます。
ちなみに、よく担当者の方が悩む受け入れテスト（UAT）の範囲ですが、基本全部やってください。ただし、まとめられるところはまとめていく、このスタンスは大事です。
りんご１ダース買って、検品するのは容易ですが、りんごを１００ダース買って、１つ１つ見ていくのは難しいです。
ただ、出荷時期が同じりんごは、１グループでチェックしていくなどができると思います。検品と同じ考え方でいいと思います。
事前にチェック表を作成。仕様と見比べて、システムをテスト
これは、テスト表を作って、テストをしていくというシンプルな方法です。計画的にできて、テスト自体のチェックもできるので、正しいですね。
ちなみに、このテスト表のことをテストケースと呼んだりします。
ただ、この方法の場合、細かい仕様の把握ができていることが前提です。
細かい仕様を把握していない場合、精度は下がります。
また、デメリットとしては、時間もかかります。
どの機能をテストするか、を明確にわかっている人がやるときのテストの方法だと思います。
利用者心理で、システムを動かす。実データを使っていく
個人的には、このテストの方が、システムの仕様バグも取れるし、実際の利用者にとって幸せなことではないかと思っています。
デメリットは、仕様バグの修正で、コストがかかることです。
ただ、多少のコストがでても、サービスレベルをあげるのであれば、システムの利用目的から落としたテストができるので、この方法が最適です。
その際、実際にシステムで使う実データでテストをしていくといいですね。外国人の利用者がいるのであれば、外国人の名前で登録をしてみたり。
アップロードするデータを実際に手元に集めて、それをアップロードしてみたり。
テストにおける時間もかかるかもしれませんが、いいです、このテスト方法。
だいたい、テストケースなどを設けて、受け入れテストをしても、もともとの仕様バグがあった場合は、直せません。
システムの利用目的から、テストをすることが１番重要だと思いますし。
画面上部から機能を使っていく
実はこのテストの方法も、地味にオススメです。
というのも、時間がないときに、人海戦術でテストができるからです。
システムを使ったことのない人を集めてきて、2～3時間と時間を決めて、画面の上のほうからテストをしていきます。
おかしな挙動を見つけたら、箇条書きで残してもらいます。
そして、最後に、そのテスト結果をまとめて確認して、修正をしていくという方法です。
この方法も、実は、利用者ニーズに対して、うまくはまりやすい方法です。
仕様バグも見つかりますし。
ただ、この方法の欠点は、モレが発生しうることです。
画面上部からテストをしていくことで、画面内にはない機能があったときに、そのテストがもれてしまうことがあります。
あらかじめ、画面内にはない機能については、仕様等をまとめておき、テストをする人にその情報を提供しておく必要があります。
当たり前？テストケースを作る
何をテストをするのか、最初の段階でまとめておいて、テストするケースを作っておくことです。
当たり前といえば、当たり前ですが。
仕様書から、テストケースを作るときは、
主語をきちんと入れて、テストケースを作っていきましょう。
アクションごとに、主語を入れて、何をするかを、エクセルなどで、まとめておきましょう！
UATで、大切なことです。
UAT 忘れがち！？ スマートフォン テスト
多くのシステムで、スマートフォン対応はされています。
webサイトであれば、なおさらです。
しかし、UATで、忘れがちなテストが、このスマートフォンでのテストです。
実際、面倒なケースが多いから！という理由もあると思います。
スマホの場合、basic認証などの場合、複雑なキーワードをコピーしにくかったりしますからね。
また、スマホでのテストをしていても、実際の端末でのテストをし忘れるケースもあります。
あえてしないケースもありますが。
実機検証は、重要なUATの項目です。
工数はかかるかもしれませんが、しっかりと、UATの１つとして、スマートフォンでのテストはしましょう。
予算と合わない場合は、chromeの検証機能などで、スマホでの表示確認などをするのも１つの方法です。
スマホは、いまや、重要なツールなので、UATでは、しっかりと取り組みましょう。
まとめ：受け入れテストは難しいので、時間は取るべき
受け入れテストについて、まとめてきました。
そもそも、受け入れテストとは何か？
その上で、どう受け入れテストをしていけばよいかを3点解説しました。
基本は、システムの目的です。
何を果たすシステムなのか、誰にとって、何をクリアしてくれるシステムなのか？といった利用者のこと、利用の目的を意識しながら、受け入れテストをしないと意味がありません。
これらテストは、軽んじられがちですが、時間をとって、きっちりやるべきタスクです。1歩ずつ、答えに近づけるようにテストをしていきましょう。
