稼働の当日、決裁の画面で否決のボタンを押すと「決裁の内容が不正です」と弾かれた。承認のボタンも同じだった。通し試験は百四十八件が通っていた。それでも、ブラウザから押すと動かない。
無効にした瞬間に、値が落ちる
原因は二重送信よけだった。送信の処理の中で、押されたボタンを無効にしていた。ボタンを無効にすると、そのボタンの名前と値が送信内容から外れる。承認か否決かは、押したボタンの値で決まる。値が届かないので、サーバは不正と判断していた。
通し試験が気づけなかったのは、サーバへ直接データを送っていたからだ。ブラウザの経路を通らない。直し方は、押された要素の名前と値を隠し項目に写してから無効にすること。それと同時に、実際のブラウザでボタンを押す試験を新設した。送信ボタンの値で処理が変わる画面を足したら、この試験にも足す、と決めた。
タブレットの試験も同じ考えで作った。タッチは本物のタッチとして送る。マウスで代用すると、触った経路を通らず、確かめたことにならない。横向きの試験で、縦長の書類が画面の下にはみ出し、スクロールしないと触れない場所ができるのが見つかった。後日、電話の幅で上の帯が五行に折り返し、画面の四割近くを占めるのも分かった。タブレットで合格は、電話で大丈夫ではない。使う端末が増えたら、測る幅も増やす。
第三者の監査で六件
通し試験が四百二十三件、ブラウザの試験が二十八件、タブレットの試験が六十四件、すべて通っている状態で、別のAIに監査を頼んだ。重大な穴が六件出た。見つけ方は三つで、どれもそれまでの試験に無かった。境界値、同時実行、不正な送信だ。
小口現金の箱に領収書を切れた。窓口の箱から仮払を出せた。収受に支出の科目を付けられた。伝票はできるのに残高が動かない。検証を一か所に集めて全経路から呼ぶ形に直した。仮払の追給が出納帳から抜けていて、帳簿の四万円に対して出納帳が四万二千円になった。補給を二つ同時に走らせると二重に補給された。取得も更新も同じ排他の中に入れ、更新件数を確かめる。添付が無くても回覧を始められた。要件には添付必須と書いてあり、仕様書同士も矛盾していた。復旧手順に書いてあるパスが実装と違っていて、書いたとおりに戻しても直らない。定数にして機械で見張るようにした。
壊して、落ちるかを見る
直したあと、九通りに壊して試験が落ちるかを見た。四つは落ちなかった。書き漏らしの検査しか反応していない。その振る舞いを、試験は何も見ていなかったということだ。塞いでから再実施して、八つが落ちるようになった。
残る一つは補給の守りで、二重になっている。取得を排他の中に入れることと、更新件数の確認だ。片方だけ外しても結果は正しいまま動く。両方外して初めて四件が落ちた。守りが重なっている所は、一つずつ壊しても落ちない。落ちない理由が、守られているからなのか、見張れていないからなのかを分けないと、試験が有効だとは言えない。
同時実行は、確実にぶつける
再監査で、同じ種類の穴が三件残っていた。一段目の承認が済んだ後でも添付を差し替えられた。仮払の同時精算で支出伝票が二件できた。預け入れの同時実行で、手元の一万円に対して二万円を預けられた。状態の名前で許可を書くと、状態が増えたときに穴が空く。何が起きたら触ってはいけないのかで書き直した。
同時実行の試験も作り直した。前の試験はスレッドを並べて始めていただけで、たまたま直列に走れば合格していた。足並みをそろえてから撃つ形にした。導入直後に両方失敗し、原因は試験側の取り込み漏れだった。例外を握りつぶす試験は、通っても落ちても意味がない。
次の回は、本番のデータを私が壊した話を書く。