これまで出した中でいちばん恥ずかしいバグには、共通点があります。テストスイートは全部グリーンだったこと。コードは仕様書どおりに動いていました。ただ、その仕様書が、ユーザーが実際に必要としていたものとずれていたのです。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人招き、シナリオは手順ではなく日常のゴールとして書き、期待と実際のずれはすべて記録します。フィードバックはバグ、変更要望、文言の問題、対応しないものに振り分け、一つひとつに判断をつけて、最後は名前のある人のサインオフで締めます。