「バックアップ完了」の裏に残ったファイルまで: 展示画像データの整合性検証

バックアップでは、何を「同じ」と見なすかを先に決める必要があります

原本と複製を比較するには、同じだと判断する基準が必要です。ファイル名が見えるという理由だけで内容が保たれているとは言えず、ファイル数が合っていても個々のファイルの状態が異なることがあります。

今回の検証では、ファイル数とサイズ、チェックサムを突き合わせの基準として使いました。チェックサムはファイルの内容から計算した値を比較する方法で、内容が変わっていないかを確認するのに活用できます。

ファイル数

比較対象に含まれる原本と複製の数は合っているか

ファイルサイズ

個々のファイルの保存サイズは一致しているか

チェックサム

ファイルの内容から計算した比較値は一致しているか

各基準は互いを補います。一つの値が合っているだけで、バックアップ全体のすべての条件を確認したとは見なしません。比較対象とその対応関係も併せて定まっている必要があります。

正常に終わった転送だけでは十分ではありませんでした

バックアップは、始まって終わる過程です。その途中で接続が切れたり、同じファイルが再び送られたりすると、最初の正常な経路とは異なる条件に出会います。

G社では、転送中断と同じファイルの再アップロードの条件を再現しました。その結果として保存されたデータを原本と突き合わせ、欠落や重複が生じ得る箇所を確認しました。

こうした条件を見る理由は、利用者が常に一度の試行で作業を終えるとは限らないからです。再実行できる機能であれば、再実行した後のデータについても説明できなければなりません。

正常な動作を確認するテストと、途中で食い違った流れを確認するテストは、異なる問いを立てます。バックアップでは最終的に残る複製が重要なので、二つの経路を一緒に見る必要があります。

データの差異を、開発が再現できる問題に変えました

複製が原本と異なるという結果だけを伝えても、修正の出発点としては足りないことがあります。どの条件でどの対象が変わったのかが分かってこそ、開発チームは同じ状況を改めて確認できます。

検証で確認した差異は、再現条件とともに整理しました。原本と複製を比較した結果を、修正の順序を決められる欠陥記録に変えたのです。

ここで重要なのは、画像が見えるかどうかだけではありません。利用者が開ける複製であっても欠落したファイルが残っている場合があり、一部のファイルの状態が異なる問題も別途見る必要があります。

検証結果が実際の修正につながるには、データの差異と、その差異を生んだ条件がつながっていなければなりません。

テスト結果とともに、改めて確認するための基準を残しました

プロジェクトを通じて、データが食い違う条件と突き合わせの基準が残りました。ファイル数・サイズ・チェックサムという比較基準は、バックアップ結果を改めて確認するときに使える出発点になりました。

欠陥一覧は、特定時点の問題を説明します。比較基準は、その後の結果を同じ問いで見られるようにします。この二つを一緒に残すことが、今回の検証の意味です。

ただし、データの突き合わせと災害復旧体制全体の検証は範囲が異なります。この事例は画像バックアップの整合性を検証したプロジェクトであり、サービス全体の復旧時間やあらゆる障害からの復旧を保証する事例ではありません。

検証で確認したことを正確に説明してこそ、その結果を使う運用者も、何を根拠に判断できるのかを知ることができます。

確認の対象を画面から資産へ移しました

G社の事例は、機能テストの対象をどこに置くかによって検証の内容が変わり得ることを示しています。バックアップボタンと完了案内を中心に見れば、画面の流れを確認することになります。保存すべき画像を中心に置けば、原本と複製の関係を確認することになります。

このプロジェクトでは、大量の画像データを突き合わせ、転送過程の例外を再現しました。その結果を、修正可能な問題と、繰り返し使う比較基準として残しました。

バックアップ検証の最後の問いは、作業が終わったかどうかではありません。必要なデータが意図した状態で残っているかどうかです。