ユーザー受け入れテスト（UAT）の進め方とフィードバックの扱い方

ユーザー受け入れテスト（UAT）は、リリース前の最後のテスト工程です。実際にそのソフトウェアを使う人たちに普段の業務で試してもらい、必要なことができるかを確かめてもらいます。ユニットテストやQAが確かめるのは、ソフトウェアが仕様どおりに動くかどうか。UATが確かめるのは、その仕様が正しかったかどうかです。UATは、最初に合意した基準に照らしたサインオフで終わります。ユーザーの期待と違っていた点は、技術的にバグかどうかに関係なくすべて記録してトリアージし、直すか、あえて先送りするかを決めます。

これまで出した中でいちばん恥ずかしいバグには、共通点があります。テストスイートは全部グリーンだったこと。コードは仕様書どおりに動いていました。ただ、その仕様書が、ユーザーが実際に必要としていたものとずれていたのです。UATは、まさにこのギャップのためにあります。

自分の機能を自分でテストできない理由

#

機能が完成する頃には、私はそのハッピーパスを何百回も歩いています。どのボタンを押せばいいかは知っています。そのボタンを作ったのは自分ですから。この慣れのせいで、私はテストユーザーとして最悪の人選になりますし、QAも半分の解決にしかなりません。QAはあくまで仕様書に対してテストするからです。問いが「設計どおりに動くか」から「そもそも設計は正しかったか」に変わるのは、UATという工程だけです。

UAT、QA、ベータテストは別物

#

この3つはよく混同されていて、誰が何をやるはずなのか、本気で混乱の元になります。

UATはこの2つの間に位置します。QAでまだクラッシュが見つかっているうちは、UATには早すぎます。ユーザーは期間中ずっとバグにつまずき続けて、本当に答えてほしかった問いまでたどり着けません。

始める前に

#

まず計画です。範囲、スケジュール、参加者、そして「合格」の定義。成功基準が曖昧なままだと、UATは何週間もだらだら続きます。

開始条件も決めておきます。大げさな名前ですが、中身は短いチェックリストです。QAを通過していて、重大なバグが残っていないこと。ステージング環境に本物らしいデータが入っていること（「test test 123」みたいなアカウントではなく）。参加者がUATのための時間をきちんと確保していること（「手が空いたときにでも」ではなく）。いちばん大事なのは最後のひとつです。本業の合間に押し込まれたUATには、せいぜい10分ぶんの本気の注意しか向けられません。

次に、実際のユーザーに近い人を選びます。開発に関わっていない同僚は良い候補ですし、製品の目的を理解している協力的な社外ステークホルダーが少人数いれば、なお良いです。たいていの機能なら5〜8人で十分です。それ以上増やしても、ほとんど同じフィードバックが重なるだけです。

迷わずこなせるシナリオの書き方

#

シナリオはエッジケースではなく日常業務を軸に書きます。エッジケースはQAがすでに叩き終わっています。良いUATシナリオは、ストレステストではなく、ごく普通の火曜日のように読めるものです。

各シナリオにはゴールと出発点を書き、手順はあえて書きません。「『新規請求書』をクリックして、次に『取引先を追加』をクリック」と書いてしまうと、テストしているのは指示に従えるかどうかであって、製品がわかりやすいかどうかではなくなります。請求書機能なら、シナリオはたとえばこんな感じです。

シナリオ4：新規の取引先に、作業の一部を請求する

新しい取引先「ハーバー・カフェ」の内装工事の前半が終わったところです。合意済みの$12,000のうち50%を、支払期限14日で請求し、先方の経理用メールアドレスに送ってください。

期待する結果： 取引先に$6,000の請求書が正しい支払期限で届き、ダッシュボードに未入金として表示される。

こういうシナリオが10〜15本あれば、ひとつの機能はたいていカバーできます。最初の数セッションには私も同席し、できるだけ口を挟まずに、参加者がどこで迷うかを見ています。ボタンの前で手が止まる一瞬のほうが、フィードバックフォームに書かれたどんな言葉よりも多くを教えてくれます。

UATフィードバックの記録

#

期間中は、ユーザーの期待と違っていた点をすべて記録します。技術的には「仕様どおり」の挙動でも、です。ある結果を期待して別の結果が返ってきたなら、仕様書に何と書いてあろうと、それは貴重な情報です。

記録に専用ツールは要りません。共有スプレッドシートでも、普段使っているイシュートラッカーに専用のボードを作るのでも十分です。ただし、どのエントリーにも同じいくつかの項目を揃えておきます。

いちばん効くのは「期待していたこと」の項目です。これがないと「請求書の画面がわかりにくい」のような、誰も手の打ちようがないフィードバックが集まります。

フィードバックのトリアージ

#

毎日の終わりに、小規模なUATなら一通り終わった時点で、プロダクトオーナーと一緒に記録を見直し、すべての項目を4つの山に振り分けます。

バグは、何かが壊れているもの。合計金額が間違っている、エラーページが出る、など。深刻ならサインオフ前に直し、そうでなければ予定に組み込みます。

変更要望は、仕様どおりに動いてはいるけれど、仕様のほうが間違っていたもの。上のパーセント指定がない件がそうです。UATが見つけるためにあるのはまさにこの種類のフィードバックで、扱いもいちばん難しい。直すとなるとスコープが増えるからです。今直すか、受け入れて後の予定に組むか、決めるのはプロダクトオーナーです。

文言・使い方の問題は、機能自体は問題ないのに、使う人が理解できなかったもの。ラベルやヒント、ヘルプに一行足すだけで解決することがよくあります。安上がりなので、やる価値があります。

対応しないもの（Won’t fix）は、スコープ外のアイデアや、ほかの全員と食い違うひとりの好みなど。理由を書き残し、挙げてくれた人に伝えます。返事をもらえなかったテスターは、次のUATではフィードバックをくれなくなります。

いちばん避けたいのは、すべての項目をリリース前に直すべきバグとして扱うことです。2週間のUATが2か月に膨らむのは、だいたいこれが原因です。UATフィードバックのゴールは、項目をゼロにすることではありません。すべての項目に判断がついていることです。

サインオフ

#

終わったら、直すべきものを直し、変更が大きかった場合は、うまくいったはずだと思い込まずに短いUATをもう一回やります。そのうえで、最初に合意した基準に照らして、きちんとサインオフをもらいます。グループチャットに「いいね」の絵文字がひとつ付くことではなく、名前のある誰かが「よし、リリースしよう」と言うこと。先送りした項目の一覧も添えてです。

UATでやってしまった失敗

#

始めるのが遅すぎた。リリース日が動かせないのにその2日前にUATを始めると、変更要望が出るたびに延期するかどうかの議論になり、答えは毎回「しない」です。見つけたことに手を打てる余裕を残しておきましょう。

間違った人でテストした。製品を知りすぎている社内スタッフは、開発者と同じ動きをします。どこに何があるか、わかってしまっているんです。

沈黙を承認とみなした。何も記録しなかったテスターは、おそらくちゃんとテストしていません。合格扱いにする前に、一度声をかけて確認しましょう。

そして、UATをスプリント末尾のチェックボックスにしてしまったこと。UATは最後の関門として扱ったほうがいい。リリース前に、自分ではない誰かがそれを使ってみる最後の機会なのですから。

得られるもの

#

一番大きいのは、問題がまだ安いうちに見つかることです。リリース後のパッチと謝罪ではなく、リリース前に。地味な効果もあります。フローが実際の仕事の流れに合っているので、トレーニングやサポートが楽になります。そして、テストに参加したステークホルダーは承認が早い。その時点で半分は「自分たちの製品」になっているからです。私が見てきた中では、きちんとUATを回したリリースほど、静かに終わる傾向があります。

要するに

#

UATは、リリース前に実際のユーザーが「必要なことができるか」を確かめる場です。QAがきれいになってから始めること。ユーザーに近い人を5〜8人招き、シナリオは手順ではなく日常のゴールとして書き、期待と実際のずれはすべて記録します。フィードバックはバグ、変更要望、文言の問題、対応しないものに振り分け、一つひとつに判断をつけて、最後は名前のある人のサインオフで締めます。