これまで出した中でいちばん恥ずかしいバグには、共通点があります。テストスイートは全部グリーンだったこと。コードは仕様書どおりに動いていて、その仕様書がユーザーの実際のニーズとずれていたのです。ユーザー受け入れテスト（UAT）は、まさにこのギャップのためにあります。リリース前に実際のユーザーにソフトウェアを触ってもらい、ユニットテストやQAでは答えられない問い——「使う人にとって本当に機能するのか」——に答える工程です。
自分の機能を自分でテストできない理由#
機能が完成する頃には、私はそのハッピーパスを何百回も歩いています。どのボタンを押せばいいかは知っている。そのボタンを作ったのは自分ですから。この「慣れ」のせいで、開発者はテストユーザーとして最悪です。QAも半分の解決にしかなりません。QAはあくまで仕様書に対してテストするからです。「設計どおりに動くか」から「そもそも設計は正しかったか」へ問いが変わるのは、UATだけです。
実際の回し方#
まず計画。範囲、スケジュール、参加者、そして「合格」の定義です。成功基準が曖昧なままだと、UATは何週間もだらだら続きます。
次に、実際のユーザーに近い人を選びます。開発に関わっていない同僚は良い候補ですし、製品の目的を理解している協力的な社外ステークホルダーが少人数いれば、なお良いです。シナリオはエッジケースではなく日常業務を軸に書きます。エッジケースはQAが叩き終わっているはずなので。良いUATシナリオは、ストレステストではなく「普通の火曜日」のように読めるものです。
テスト中は、参加者にシナリオをこなしてもらい、期待と違った点はすべて欠陥として記録します。技術的には「仕様どおり」の挙動でも、です。終わったらフィードバックを集めて修正し、変更が大きければ、うまくいったはずだと思い込まずにもう一周回します。最後に、最初に合意した基準に照らして正式なサインオフをもらいます。
得られるもの#
一番大きいのは、問題がまだ安いうちに見つかることです。リリース後のパッチと謝罪ではなく、リリース前に。地味な効果もあります。フローが実際の仕事の流れに合っているので、トレーニングやサポートが楽になります。そして、テストに参加したステークホルダーは承認が早い。その時点で半分は「自分たちの製品」になっているからです。
仕事でも、きちんとUATを回したリリースほど静かに終わる気がします。UATはスプリント末尾のチェックボックスとして扱いたくなりますが、最後の関門として扱ったほうがいい。リリース前に、自分ではない誰かがその機能を使ってみる最後の機会なのですから。