公開前の点検は、他人の端末で一度開くまで終わらない

この製品を最後まで使った人は、まだ一人しかいない

公開日まで数日しかない。機能はそろい、デザインの確認も終わり、サーバーにも上がっている。あとは開けるだけに見える。ところが、この製品を最初の画面から最後まで実際に通った人は、まだ作った本人一人だけである。

作った人は自分が引いた道を通る。登録フォームに入れる値はいつも使っているその値だし、決済画面までの順路も自分が組んだとおりだ。その道は何十回も歩いているのだから詰まるはずがない。問題は、最初の利用者がその道から来ないことにある。検索結果から詳細ページに直接入り、登録の途中で窓を閉じて一時間後に戻ってきて、決済の最中に戻るボタンを押す。

だから公開前の点検は、項目をいくつ確認したかより、誰がどの道を通ったかに近い。リストを長くするより、リストになかった道を一度歩くほうが引っかかるものが多い。

一本の線としてつないで歩く

画面を一枚ずつ確かめると、画面はどれも問題ないのにサービスとしては使えない、という状態ができあがる。利用者が実際にするのは画面一枚ではなく、入ってきて目的を果たすまでの一本の線だからだ。その線を切らずに通しで歩いてみる。登録して、確認メールを受け取り、ログインし、商品を入れ、支払い、履歴を見にいくところまで。

引っかかるのは、たいてい成功した後ではなく失敗した後である。カードが拒否されたとき、確認メールが届かないとき、決済の途中で戻るボタンを押したとき、同じボタンを続けて二回押したとき。うまくいく場合は作りながら何十回も見ているが、失敗の経路は一度も通らないまま公開されることが珍しくない。注文が二件入る、決済は済んでいるのに注文がない、という状態はここから出てくる。

アカウントも新しく作ってみる。開発中に使ってきたアカウントには権限もデータもすでに積まれていて、空の画面を見たことがない。今朝はじめて登録した人に何が見えているかは、新しいアカウントでしか確認できない。

外に出ていくものは、届いて初めて確認できる

画面に送信しましたと出ることと、そのメールが相手の受信箱にあることは別の事実だ。問い合わせフォーム、登録確認、パスワード再設定、注文確認、通知。実際のアドレスに送って実際に開いてみるまで、確認したことにはならない。

開発中はテスト用の受信ツールで確かめて先に進むことが多いが、あの手のツールはメールを外に出さない。本番の送信に切り替わった瞬間に、送信ドメインの認証が関門になる。主要なメールサービスが送信ドメインに SPF、DKIM、DMARC の設定を求める方向でそろってから何年か経っていて、これがないとメールは迷惑メール扱いになるか、そのまま拒否される。ドメインの設定は開発ではなくドメイン管理側の仕事なので、誰がやるかを決めていないと公開してから見つかる。

受け取る側も一度は確かめる。問い合わせフォームが送るメールが担当者の迷惑メール箱に積まれていれば、フォームは正常なのに問い合わせだけが来ない状態になる。

古い端末、遅い回線、ログインしていない窓

作った人の環境はいつも最新で、画面は大きく、回線は速く、ブラウザにはすでにログインしている。この四つが全部違う状態を一度は作ってみる。何年か使っている実機で開き、ログインしていない窓で最初の画面から入り、回線が遅いときに画面がどの順番で描かれるかを見る。画像の重いサイトは、この条件ではじめて素性が出る。

公開設定もここで一緒に見る。開発中は検索エンジンに拾われないよう止めておくのだが、その設定がそのまま公開されると、サイトは普通に開くのに検索には出てこない。逆にテスト用のアドレスが開いたままで、同じ内容が二か所にある場合もある。どちらも画面を見ているだけでは分からず、公開して数週間後に、なぜ検索に出ないのかという質問になって戻ってくる。

元に戻せる状態か

いくら点検しても、公開してから出てくるものはある。だから最後の問いは何を確認したかではなく、間違えたときに戻る場所があるかだ。直前の版に戻す手順を知っている人がいるか、その作業が数分で終わるか、データベースに触れた変更ならバックアップはいつのものか。

戻せない作業には印をつけておく。画面やコードは戻せば済むが、利用者のデータを移したり消したりした作業、すでに出ていったメール、すでに承認された決済は戻らない。この種のものを公開日に一度に寄せないことも点検のうちだ。

開ける時刻も判断のひとつである。金曜の夕方に開けると、何かあっても見る人がいない。異常を知らせる仕組みは開ける前に入れておく。利用者から電話で知らされる前にこちらが先に気づけるかどうかで、初日の見え方が変わる。

動かない、はまだ点検結果ではない

届いた報告が決済ができないの一行だけなら、直す側は最初から再現をやり直すことになる。何をどの順で押したか、どの端末とどのブラウザか、どのアカウントでいつだったか、画面に何が出たか。この四つが付いていればたいていその場で原因が絞れるし、なければ再現だけで一日が消える。画面を録っておくのがいちばん早い。

点検する人と直す人が別なら、この書き方を先に合わせておく。公開直前の数日は発見が集中する時期なので、整理されていない報告がたまると、直す時間が読む時間に変わる。

はじめて見る人の役は、こちらが引き受けます

Weple の公開前品質点検は、作った側が一度も通らなかった道を代わりに歩く仕事です。壊れては困る流れを実際のブラウザがなぞる自動テストにして、ブラウザと画面サイズの組み合わせを変えながら回し、空の値や長すぎる入力、遅い回線、二重クリック、戻るボタンのように実際の利用で出る条件をわざと入れてみます。リポジトリへの権限は必要なく、開けるアドレスとテスト用アカウントがあれば始められます。何を引き受けるか、どんな単位で金額が付くかは料金案内に書いてあります。開発がまだ終わっていない時点で呼んでいただいてかまいませんし、そのほうが直す時間が残ります。見つけたものは再現手順と画面の記録、深刻度まで付けて整理してお返ししますので、そのまま開発者に渡していただけます。