不具合を未然に防ぐためにテストデータを定期的に自動投稿する仕組みを整備した話

こんにちは！くふう AI スタジオの桃原です。
今年から品質向上部に所属し、テストの運用や追加を行なってきました。
今回は、その中でトクバイのテストデータを追加した際のお話をします。

既存のテストデータの課題

トクバイのアプリの新機能開発時には、開発者がデバッグやコードレビューを行い、その後 QA エンジニアが手動でテストを行うプロセスを経ています。しかし、開発期間中に検知されるバグが一時期増加してしまいました。
発生した不具合を分類したところ、特定のパターンでレイアウトが崩れたり、投稿が無いのに見出しが表示されるといった、一目でわかる考慮不足の不具合が複数発生していることが判明しました。
これらの問題は、仕様策定段階や実装段階、さらには開発者の初期動作確認の際にも確認できる環境が整っていれば、もっと早い段階で防ぐことができたのではないかと考えました。
このような背景から、本ブログで実施した対応のきっかけとなりました。

トクバイの開発環境では、本番のデータベースから個人情報を除いたデータを一定間隔でレプリケーションすることで、常に本番環境に近い検証が可能となっています。また、各自でテスト目的に応じたコンテンツを自分で投稿可能となっています。
実際に使われているデータや好きなデータで素早く検証することができます。しかし、チラシや特売品の情報といった賞味期限が短いコンテンツの性質上、滅多に使われなかったり、設定に手間がかかるものは確認が難しい状況となっていました。

トクバイアプリの品質保証においては、MagicPod による E2E テストをビルド作成毎に実施しています。MagicPod を使用して自動化された E2E テストを実施するために、再現性の高いテストデータを常時作成するバッチ処理のノウハウは既にありました。
しかし、MagicPod 向けのデータを拡充するのはテストの不安定さを増すリスクがありました。そこで、そのノウハウを応用して、新たに開発チームがいつでもすぐに触れる様々な種類のデータを作成することにしました。

様々なパターンを網羅したテストデータを作成

対策として、様々なパターンの店舗を用意しました。以下のように、それぞれの店舗ごとに用途を決めてデータを追加していきました。

• 全てのコンテンツを様々なパターンで追加した店舗

• 文字入力があるコンテンツを最大文字数で追加した店舗

• 画像追加が任意のコンテンツで画像無しで追加した店舗

• それぞれのコンテンツを1件のみ追加した店舗

掲載期間に限りがあるコンテンツについては、一度追加しても掲載期間を過ぎると表示されなくなるので定期的に追加しなおす必要があります。
MagicPod のために使っているバッチ同様に、Playwright をヘッドレスブラウザで使用してトクバイの入稿機能を利用する仕組みを取り入れています。

直接的な SQL や Cloud Storage の操作と言った高速かつ安定した手段を取らない理由は、トクバイサービスの入稿やデータ方式が複雑で、開発コストが莫大になってしまうためです。また、ブラウザテストのノウハウを用いることでメンテナンスが可能です。

苦労した点

実装に際して苦労した点としては、既存のテストデータに比べて多くのパターンやデータを扱う必要があったため、不安定な要因によって失敗するケースが増えたことが挙げられます。
既存のテストデータは自動テストでも使用しているので、処理が失敗した場合、データを1から追加し直す必要があり、データが削除されたタイミングで MagicPod による E2E テストが実行されると、テストが失敗する問題が生じました。そこで、CircleCI で実行スケジュールを分け、新しいテストだけ再実行できるようにしました。
また、ローカルでは成功するが CircleCI での実行時に失敗するケースへの対応として、CircleCI 上でのログを詳細に確認できるよう、Verbose オプションを追加する対策を行いました。

パターンが増えたことにより、データ投稿の確認テストも複雑になりました。複数の要素を検知されてエラーになるケースが出てきたので、投稿する際のファイル名や文字列が被らないように調整し、それらに対してテストするようにしました。
文字数最大まで入力する店舗に関しては、最大で1000文字のコンテンツも存在し、それぞれ別の文字列を入力する必要がありましたが、そこは ChatGPT による文字列生成に助けられました。

品質向上部に所属して初めてトクバイの開発に関わったので、把握できていないサービスの仕様がありました。また、実行する順番によっては追加したはずのデータが依存関係で削除されることもありました。

これらの問題を解決し、様々なパターンを網羅したテストデータを用意することができました。
作成したデータを社内で利用しやすくするために、社内でタスクやドキュメント管理として使用している Notion に店舗ごとの用途やリンク、注意点をまとめました。
仕様の問題でテストデータでは用意が難しい店舗もありました。そのデータについては、Redash を使用して該当のデータを検索できるようにすることでアクセスしやすくしています。

最後に

エンジニアからは好意的なリアクションをもらっており、やってよかったと改めて実感しています。
これからも品質向上部として、業務や品質の改善に努めてまいります。
最後までこの記事をご覧いただき、ありがとうございました。