更新したのに最新版か分からない｜表示した版と確認時刻を記録する

Webアプリを更新した後は、どの公開先を、いつ、どの版として確認したかを記録します。修正した側の説明と、利用者が見ている画面を結び付けるためです。

私も自作のWebアプリについて、最新版を見て改善するよう依頼したり、更新後の表示を確認したりしてきました。版を識別する表示も使っています。ここでは特定のアプリ名や公開方式を出さず、確認情報をそろえる方法を紹介します。

コードの更新と公開画面の確認を分ける

作業中のコード、公開されたファイル、利用者が開いた画面は、確認する対象が異なります。「更新した」という報告を受けたら、どの段階を確認したのかを整理します。

公開したという情報だけで、利用画面でも同じ版を見ていると決めつけません。一方、表示が違うという理由だけで、更新そのものが失敗したとも断定しません。

版を示す目印を用意する

識別の方法には、版番号、更新日時、公開した変更の説明などがあります。どの方式を使うかは、そのアプリの運用に合わせます。

重要なのは、公開した側と確認する側で、同じ目印を参照できることです。作業用の番号と画面上の番号が別なら、その対応も分かるようにします。数字を付けただけで、機能の動作が確認できたわけではありません。

確認メモを同じ形式で残す

開いた公開先：
確認した日時：
画面で確認できた版：
使用した端末と画面：
確認した機能：
行った操作：
実際の結果：
期待する結果：

日時を記録しておくと、修正前後のどちらを見たのかを確認する材料になります。公開先や画面に秘密情報が含まれる場合は、共有範囲に合わせて伏せます。

表示が違うときは原因を決めつけない

古い版を見ているように感じた場合も、表示だけで原因は確定できません。まず公開先の違い、版の識別、確認時刻、操作条件を照合します。

同じ名前の別環境を開いていないか、修正した機能が期待した場所にあるかを確認します。そのうえで、公開結果や実際の取得内容を調べる必要があります。未確認の状態で「保存データが消えた」「端末の問題だ」と決めつけないようにします。

確認する機能を一つ決める

画面の見た目が変わっただけでは、修正した動作まで確認できたとは限りません。対象の入力と操作を決め、結果を記録します。

不具合が残っている場合は、実際の表示と期待を分けた不具合報告の書式で依頼をまとめます。画面操作の自動化を含む場合は、少量での確認と例外処理も確認できます。

まとめ

最新版の確認では、修正内容、公開先、版の目印、確認時刻、操作結果をそろえます。私は自作アプリの更新確認を依頼してきましたが、版を見たことと動作が確認できたことは別です。

表示が合わないときは原因を推測で決めず、同じ公開先と条件を見ているかを確認します。修正後の報告にも、何を確かめたかを具体的に残します。