今回はタイトルの内容について纏めようと思います。
前置き
WEBシステムでよく見かける登録・編集・詳細画面のようなページ構成での、保存時の試験の粒度として
１．保存後の画面を見て登録データの正誤を判断する
２．DBを見て登録データの正誤を判断する
という段階をそれぞれ考えてみます。
※より細かく段階を分けられますが、今回は上記で考えます。
粒度1：保存後の画面を見て登録データの正誤を判断する
メリット
- テストの消化スピードが早い
画面操作だけで完結するため、SQLの発行やDBクライアントツールの確認、ログの監視といった作業が発生せず、スムーズにテストを進められます。 - 「ユーザーの体験（UX）」を直接担保できる
システムを利用するエンドユーザーと同じ目線でテストするため、「画面上に正しく表示されているか」という最終成果物を保証できます。 - テスト担当者のスキルセットを選ばない
SQLの知識やDBの閲覧権限がない非エンジニアでもテストを実行できます。
デメリット
- 設計（データ構造）と実装の乖離を見逃す（保守性の低下）
画面上は正しく見えても、DBには設計書（例：区分値01）と異なる値（例：文字列そのものや、別の区分値99）が保存されているケースを見落とします。 - 画面に表示ロジックがあると、正確なテストとならない
値が未設定のときに変わりの文字列が表示されるロジックがある場合、代わりの文字列と同じ内容が設定されたデータがあると、DBが空となっているのか値が入っているのかが判別できません。 - 画面側の制御によって、サーバー側のチェック漏れが隠れてしまう
画面（ブラウザ）側にて文字数の制御が入っていることは確認できますが、サーバー側でのチェックを行っていないケースを検知できません。
※難易度は高くなりますが、ブラウザの開発者ツールで調整することで検知可能な部分はあります。
粒度2：DBを見て登録データの正誤を判断する
メリット
- データの「正真性」を保証できる
画面の表示ロジックに依存せず、システムが保持する「生データ」そのものが正しいかを検証できるため、データ連携やバッチ処理の安全性が担保されます。 - 不具合の「原因特定（切り分け）」がスムーズになる
もし画面の表示がおかしかった場合、「DBのデータが不正（バックエンドのバグ）」なのか、「DBは正しいが画面の出し方が悪い（フロントエンドのバグ）」のかが、テストの段階で明確に判明します。 - 設計書との整合性が取れる
型、桁数、区分値、タイムスタンプ、作成者IDなど、画面には見えない内部ステータスの正しさを検証できます。
デメリット
- テストのコスト（時間・手間）が増加する
「画面で保存 ➔ DBツールに切り替え ➔ SQL実行 ➔ データの目視確認」という手順を踏むため、1ケースあたりの消化時間が長くなります。 - 環境構築や権限管理の手間が増える
テスト環境のDB接続情報の共有、ツールの用意、本番に近い環境であれば個人情報・マスキングの配慮や閲覧権限の管理など、テスト前段のハードルが上がります。 - 「DBが正しければOK」と思いこむリスク
（意識していないと）DBには正しく保存されているものの、「画面へのマッピング漏れで、詳細画面を開くと正しく表示されない」というようなフロント側の不具合を見落とすリスクが生まれます。
まとめ
それぞれの粒度のメリット・デメリットをまとめてみました。これらを意識してテスト作業を進めていきます。
また、発展形としてどちらか一方にこだわらず、「基本は粒度1、ただし重要機能は粒度2」などのハイブリッド運用も検討します。
例：マスタ登録や、他システムと連携するコアデータ（売上、ユーザー基盤、ステータス変更）は必ずDBまで見る。単一システム内で完結する簡易なメモ機能や、デザインの確認に近いものは画面のみにする。など
