一式ができたので、確かめる工程に入った。要件定義書に並べた受け入れ条件の番号を、そのまま試験にした。二十二項目。あわせて、実際のブラウザで四つの画面を通しで操作して回る検査も書いた。こちらは四十三項目。数だけ見れば十分に思えたが、この二つを通しても、まだ出ていない欠陥があった。
通ったことは、できていることの証明ではない
試験を書くときにまず気をつけたのは、判定の出どころだった。呼び出す側が「これは成功として扱う」と渡せる口を作らない。合否は必ず、返ってきた応答と、記録の実際の値から計算する。楽をしようとすると、試験用に結果を差し込める入口をどこかに開けたくなるが、その入口は本番でも開いている。しかもそこを通した試験は、実装ではなく試験自身を見ているだけになる。
そのうえで二十二項目が通ったあと、次にやったのは、実装をわざと壊すことだった。署名の検証をすり抜けるように変える。版の判定を外す。受付の使い捨てをやめる。重複の防止を無効にする。そういう改変を、動く側のコードで七箇所、画面側で四箇所やって、そのたびに検査が落ちることを確かめた。
落ちなければ、その項目は何も見ていない。通っている試験一式を眺めても、それがただ緑になっているだけなのか、本当に条件を掴んでいるのかは区別がつかない。手間はかかるが、仕様を変えたときは同じことをやり直すと決めた。
動いているサーバに、相乗りしない
画面の検査では、一度やり方を間違えた。最初は、自分が立ち上げて触っていたサーバに対して検査を走らせていた。すると前回の操作の跡が残っていて、承認していないはずの店が「もう反映済み」と見え、初回のはずの利用者に同意の画面が出ない、という判定が出た。実装は正しいのに検査が誤る形だ。
直したのは検査のほうで、毎回まっさらな記録を使い、自分でサーバを起こしてから操作し、終わったら捨てる形にした。検査は、前の検査の結果に影響されてはいけない。当たり前のことだが、目の前で動いているものがあると、つい相乗りしてしまう。
手元では速すぎて、見えなかった
そして、公開する住所に置いて外から触ってみたときに、初めて出た不具合があった。利用者が規約に同意した直後、印を並べたカードが一瞬だけ空のまま表示される。手元では、同意の処理と次の読み込みがほぼ同時に終わるので、この空白が現れる余地がなかった。実際の通信を挟んで初めて、二つの処理の順序が見える速さになった。
直し方は、同意の応答に含まれているカードの中身をそのまま控えて先に描く、というものだった。改めて取りに行く必要がなかった、というだけの話でもある。ただ、この種の競合は理屈で見つけようとしても抜ける。実際の経路で測るしかない。
同居している本番を、巻き込まない
置き場所にも気を使った。この提案用のデモは、他の稼働中のサービスと同じ一台に同居させた。その機械は空きメモリが厚いとは言えず、待避領域も常時使われていて、直近の一か月にメモリ不足による強制終了が一度起きていた。同じ場所には、お金をいただいているサービスも載っている。
そこで、このデモにだけメモリの上限と、優先度を下げる設定を付けた。上限を超えたときに落ちるのはこのデモだけで、同居している本番を道連れにしない。動かしたあとで、同居している各サービスがすべて応答することと、異常終了した処理が一つも無いことを実測した。提案のために作ったものが、稼働中のものを止めたら本末転倒だった。
書いたことと、動くものを突き合わせる
最後に、相手に渡す検証マニュアルと実物を機械で照らし合わせた。住所に到達するか、画面に出る表示名は原稿どおりか、店の数は合っているか、項目名やボタンの文言は同じか、受付番号の書式は一致しているか。二十項目ほどを自動で確かめ、資料を直すたびにやり直した。
動くものを作って渡す、と決めた以上、渡す紙と動くものがずれているのがいちばんまずい。そのずれは、相手が最初に触った三十秒で見つかる。