システム開発では、修正が入るたびに以前の機能が壊れていないかを確認する必要がある。いわゆる回帰検証だ。今回、開発を続けている「DX経営ゲーム」の個人編についても、最新版を検証環境へ反映した後、機能面の回帰検証を行った。
検証に入る前には、どのファイルを最新版として扱うかも明確にした。開発中は、手元の作業場所や検証用の複製など、似たファイルが複数の場所に残りがちだ。古い版を検証して「直っていない」と判断してしまえば、検証そのものが誤りになる。今回はDropbox配下の開発フォルダーを正本と定め、そこから仮想マシンへ反映し、再起動後にアプリの応答が200になることを確認してから検証を始めた。
この準備は地味だが重要だ。検証結果を信頼できるものにするには、テスト項目だけでなく、対象が本当に修正版なのかを保証しなければならない。「何を試したか」と同じくらい、「どの版を試したか」を残す必要がある。
最初に実行したのは、既存の広域自動検証スクリプトだった。このスクリプトは、ゲームの作成、参加者登録、開始、意思決定、ターン終了、計算といった一連の処理を自動で進める。人が一つずつ画面を操作するより速く、複数の条件をまとめて確認できるため、継続開発では有効な道具だ。
ところが、実行結果は9シナリオ中2シナリオだけが成功というものだった。数字だけを見れば、かなり深刻だ。最新版には多数の不具合があり、まともにゲームを完走できないようにも見える。
しかし、ここで「7件の不具合が発生した」と結論づけるのは早計だ。自動テストが失敗したという事実と、製品に不具合があるという判断は同じではない。失敗した場所と理由を一つずつ切り分ける必要がある。
調査すると、警告には大きく二つの要因が混ざっていた。
一つは、検証スクリプトが古い画面仕様を前提としていたことだ。スクリプトは「振り返り」という名称のタブを探していたが、現在の画面構成は変更されている。製品側の画面が正常でも、テスト側が以前の名称や構成を探し続ければ失敗になる。これは製品の退行ではなく、検証手順が現行仕様に追随できていない状態だ。
もう一つは、自動操作で採用していた経営戦略だ。広域検証では複数の展開を試すため、資金や在庫に余裕のない攻めた意思決定も含まれていた。その結果、終盤で会社が破綻し、次の意思決定を受け付けられず、APIが400を返すケースがありた。
ゲームのルール上、無理な経営を続けた会社が進行不能になるのであれば、それは必ずしもシステム障害ではない。むしろ、経営判断の結果が正しく反映された可能性がある。テストは通信の成功だけを見ていたが、製品は経営シミュレーションとしての整合性も守らなければならない。この違いを考慮せず、400という応答だけを不具合に数えることはできない。
そこで、広域検証とは別に、個人編の主要機能を確認するための素直なシナリオを実行した。ゲームを新規作成し、参加者を登録して開始する。ログイン後、各ターンで意思決定を登録し、ターンを締め、計算する処理を6回繰り返した。
この基本シナリオは6ターンを完走した。終了後には、ランキング、会社履歴、個人レポートを取得できることも確認した。また、従業員の採用についても、別々の検証で従業員数が3人と2人になることを確認し、意思決定の結果がデータに反映されていた。
画面についても別の監査を行っている。以前に残っていた静的ファイルの404エラーは解消され、ブラウザのコンソールエラーは0件になりた。スマートフォン幅で問題になっていた比較表や推移表の横方向のはみ出しも0件だ。新しく追加された「AI相談」タブが実画面に表示されることも確認した。
以上から、今回の結論は「自動テストで7件の製品不具合が見つかった」ではない。個人編の主要な利用経路は正常であり、広域自動検証スクリプトの一部が現在の仕様に合わなくなっている、というのが正確な判断だ。
自動テストは、実行すれば機械的に正解を教えてくれるものではない。テスト自体もプログラムであり、仕様変更の影響を受ける。期待値が古ければ、正しい製品を誤って失敗と判定する。反対に、確認項目が不足していれば、不具合があっても成功と判定する可能性がある。
今回の検証で次に必要なのは、製品を闇雲に修正することではなく、広域自動検証スクリプトを現行の画面構成に合わせることだ。さらに、ゲーム上の正常な破綻とシステム異常を区別できるよう、失敗理由を判定する仕組みも必要だ。
テスト結果を見るとき、私は成功数や失敗数だけで判断しないようにしている。どの条件で、どの処理が、なぜ失敗したのか。製品の問題なのか、テストの問題なのか、それとも仕様どおりの結果なのか。そこまで確かめて初めて、検証結果を開発判断に使える情報にできる。
自動化によって検証は速くなる。しかし、結果の意味を判断する仕事まで自動化されたわけではない。今回の回帰検証は、そのことを改めて確認する機会になりた。