はじめに

最近のシステム開発では、メール配信や決済、認証などをSaaSと連携して実装することが珍しくなくなりました。
すべてを自分たちで作る必要がなくなるので、開発効率はかなり上がります。

一方で、外部サービスと連携するシステムでは、自分たちのシステムだけを見ていると気づきにくいポイントもあります。

今回は、メール配信サービスと連携するシステムのテスト計画を考えていたときに、少し気になったことがありました。
結果的にそれが SaaS連携ならではの落とし穴だと感じたので紹介したいと思います。

負荷テストの計画

このシステムでは、将来的に一度に数万件〜10万件程度のメール通知を送る可能性がありました。
そのため、リリース前に負荷テストを行う予定でした。

テストの内容としてはシンプルで、

「大量の通知データを作って一気に送信し、問題なく処理できるか確認する」

という、よくある負荷テストです。

ここまでは特に違和感はありませんでした。

ふと気になったこと

テスト計画を考えているときに、ふと気になったことがありました。

「この負荷テストで送るメールデータは、最終的にどこに保存されるんだろう？」

今回のシステムでは、メール配信を外部のサービスに任せています。
つまり、システムから送信されたメールの情報は、その外部サービス側で管理されます。

ここで確認してみると、そのサービスには 開発環境と本番環境が分かれていませんでした。

テストデータも本番データと同じ場所に入る


環境が分かれていないということは、

開発環境から送信したメールも
本番環境から送信したメールも

すべて同じ場所で管理されるということになります。

もし何も考えずに負荷テストを実施すると、

数万件〜10万件のテスト用メール送信データが
そのまま外部サービス側に記録されることになります。

場合によっては

  • 本番の配信ログと混ざる
  • エラー通知が大量に発生する
  • 運用側の監視に影響する

といったことも起こり得ます。

システムとしてはテストのつもりでも、
外部サービスから見ると「普通のメール送信」と区別がつかないからです。

システムの外側を見る必要がある

負荷テストというと、

「APIの処理が遅くならないか」
「データベースが耐えられるか」

といった、システム内部の性能に意識が向きがちです。

ただ今回のケースでは、

  • 外部サービスの環境構成
  • 本番運用との関係
  • テストデータが残る場所

といった システムの外側の部分を考える必要がありました。

SaaSと連携するシステムでは、こうした部分まで含めてテスト計画を考える必要があるのだと改めて感じました。

AIでも気づきにくいポイントかもしれない

最近は、設計レビューやテスト観点の整理でAIを活用する場面も増えてきました。
実際、コードや仕様からリスクを指摘してくれることもあり、とても便利だと感じています。

ただ今回のように、

  • 外部サービスの環境構成
  • 実際の運用方法
  • テストデータがどこに保存されるか

といった プロジェクト固有の前提が関係するケースは、AIだけではなかなか気づきにくいかもしれません。

「このデータは最終的にどこに行くのか？」

といった視点は、システム全体の構成や運用を理解しているからこそ出てくる疑問だと思います。

まとめ

SaaSと連携するシステムでは、自分たちのアプリケーションだけを見ていると見落としてしまうポイントがあります。

特にテストを計画するときは、

テストデータが
最終的にどこに保存されるのか

という視点を持つことが大切だと感じました。

SaaSを活用することで開発は効率化できますが、その分、
システムの外側まで含めて考えることが重要になるのかもしれません。

今回の経験を通して、テスト設計ではシステム単体だけでなく、
周辺の仕組みや運用も含めて考えることの大切さを改めて感じました。