データアナリストがソフトウェアテストを使ってデータ品質のテストをしてみた

こんにちは。データアナリストの田代です。
データを分析していて、「SQLのロジックは合っているはずなのに、集計結果にどうも違和感がある…」そんな経験はありませんか？
最近、まさにそのような課題に直面しました。システムから連携されるデータを使った分析で、原因のわからない数値のズレが見つかったのです。調査を進める中で、「データそのものの品質」に体系的に向き合う必要がある、という結論に至りました。
今回は、システムの内部が見えない「ブラックボックス」を相手に、どのようにデータ品質を検証していったのか、その際に役立った「ソフトウェアテスト」の考え方と具体的なアプローチについてお話しします。

はじめに：テスト方針

まず、今回のテストにおける方針とスコープを明確にしました。
私たちはソフトウェアのQAエンジニアではないため、システムの動作そのものではなく、あくまで「システムから連携された後のデータが、期待通りかどうか」を検証の対象としました。
このため、データの生成プロセス自体はスコープ外とし、データが格納されたBigQuery上で全ての検証を行う、というシンプルな方針を立てました。この線引きが、限られたリソースの中で効率的にテストを進める上で非常に役立ちました。

1. テーブル単体テスト

最初のステップとして、個々の機能をテストする単体テストを行いました。今回は単体テストを「個々のテーブルが健全か」を検証するテストと位置づけました。

確認したこと
- ユニークキーの重複：ユーザー数のような重要指標を誤って集計することを防ぎます。
- 必須項目のNULL値：計算や分析の対象から意図せず漏れてしまうレコードがないかを確認します。
- 値の妥当性：年齢がマイナスになっている、マスタにない値が入っているなど、ありえないデータが混入していないかを確認します。
確認しなかったこと
- 構造の妥当性：期待通りのカラム名やデータ型、順序になっているかは、ETLツールによってカラム名やデータ型、順序が異なる可能性があるため今回はテストのスコープから外しました。
- データ生成のロジック確認：どのようなプログラムでデータが生成されたか？いわゆるホワイトボックステストに該当するテストは検証ができないため、こちらもスコープから外しました。

2. 複数テーブル結合テスト

次に、複数の機能を連携させた際の結合テストを行います。今回は結合テストを「複数のテーブルを跨いで見たときの整合性」を検証するテストと位置づけました。

確認したこと
- 参照整合性：実在しない利用者に紐づく行動履歴といった、データ間の矛盾がないかを確認します。
- 結合後のレコード数：意図しない重複が発生し、数値が過大に集計されるリスクがないかを検証しました。
- ビジネスルールとの整合性：サービス利用者の登録日より前に行動履歴が存在するなど、時系列や業務の流れとして矛盾するデータがないかを見つけ出します。
確認しなかったこと
- 更新頻度の確認：期待している更新頻度についてもETLツールによるため、今回のテストスコープから外しました。
- システムのパフォーマンステスト（DB負荷を含む）：各テーブルがどれくらいのレコードに耐えられるのか、レコード生成や更新に何秒かかるのかといった内容はシステムの中身に関するテストのためスコープ外としました。

3. E2E（End-to-End）テスト

最後に、より大きな視点で、一連のビジネスシナリオがデータ上で矛盾なく再現できるかを確認します

確認したこと
- ユーザーライフサイクルの追跡：特定のユーザーが「登録」してから「サービスを利用」し、「有料プランへ移行」するまでの一連の流れをデータで追い、ステータスの遷移や日時に不整合がないかを確認しました。
確認しなかったこと
- UI/UXテスト：システムの画面の使いやすさはデータの出力とは関係がないためテストのスコープ外としました。
- 機能の網羅的テスト：システムにある全てのボタンや機能が正しく動くかといった機能もデータの出力とは関係がないためテストのスコープ外としました。

この取り組みで得られたこと

この一連のテストを通じて、これまで「何となくおかしい」と感じていた問題を、具体的なデータとして特定できるようになりました。
そして、技術的な発見以上に大きかったのが、システム開発チームとの連携がスムーズになったことです。
これまでは曖昧だった問題報告が、「このテーブルのこのレコードが、このルールと矛盾しています」という客観的な事実に変わったことで、建設的な対話が生まれ、問題解決が迅速に進むようになりました。
また、テストケースの一覧を書き出して結果をオープンにすることでデータ分析をするマーケターや他の職種の方たちが該当システムのデータを使う時の安心材料にもなりました。

図：テストケースを記載した際のテンプレート