どのQAエンジニアに「一番いやらしいバグはどこに潜んでいるか」と尋ねても、返ってくる答えは同じです。一人のユーザーのハッピーパスの中ではなく、ユーザーとユーザーのあいだの空間だ、と。二人が同じ瞬間に登録する。招待メールが違う人に届く。管理者と閲覧専用メンバーが同じページを開いたとき、片方が見えてはいけないものを目にする。こうしたことは、自分自身のメールアドレスで一人でテストしていても再現できません。データベースの中では、あなたは常にたった一人のユーザーでしかないからです。
本物のプロダクトは、その性質上たいていマルチユーザーです——チーム、ワークスペース、権限、招待、紹介、テナント。こうしたフローを正直にテストするには、同時に使える、互いに独立して到達可能な受信箱がいくつも必要になります。まさにここで、使い捨て受信箱は気づけばテスターの道具箱の中でもかなり頼れる存在になります。しかもこの使い方は、迷惑メールから身を隠すこととはまったく関係ありません。
本物の受信箱ひとつ（または共有のQA用Gmail）では足りない理由
自分自身のアドレスの問題は単純です。すでにシステムに存在しているのです。自分のレコードがすでにデータベースにある状態で「まだ一度も見たことのない、まっさらな新規ユーザー」を再現することはできませんし、ましてや三人の異なる新規ユーザーに同時になることなど到底できません。そこでチームはよく、共有のQA用Gmailアカウントに手を伸ばし、プラスアドレス方式——[email protected]、[email protected] など——に頼ります。これは通用するうちはいいのですが、いつも通用するわけではありません。多くのアプリは + タグを削除したり正規化したりしますし、まったく受け付けないものもあります。たとえ受け付けられたとしても、結局すべてのメッセージは一つの受信箱に届くため、どの「ユーザー」が何を受け取ったのかを後からほどいて突き止める作業が必要になります。
本当の意味でのマルチユーザーテストには、実際に分離された受信箱が欲しくなります——分離されたアドレス、分離された受信箱、共有された状態がないこと。それこそが、タブをいくつか開くだけで手に入るものです。
使い捨て受信箱がQAのどこにはまるか
Temp Mailのタブはそれぞれが完全に独立した受信箱で、固有のアドレスを持っています。タブを三つ開けば、送受信できる本物のユーザーが三人分手に入ります——アカウント作成も不要、後片付けが必要な共有受信箱もありません。しかも各アドレスは毎回新しく生成されるので、昨日のテスト実行の残りが今日の結果を濁らせることもありません。終わればすべて1時間後に自動削除されるので、個人のメールアドレスに紐づいたテストアカウントの墓場を積み上げることもありません。
本当にテストする価値のあるマルチユーザーシナリオ
複数の稼働中の受信箱を横に並べておくことが報われるフロー——リリース前には誰も簡単に再現できなかったせいで、本番環境でひっそり壊れるものたち——を挙げます。
- チーム・ワークスペース招待: ユーザーAがワークスペースを作成し、BとCを招待する。それぞれの招待は、正常に機能する、安全に生成されたリンクとともに正しいアドレスに届かなければならず、承諾すれば各人が正しいワークスペースに正しい権限で入る必要がある。三つの受信箱を同時に見張っていれば、誤ルーティングされた招待に瞬時に気づける。
- 権限とロール: オーナー、管理者、閲覧のみのメンバーを、それぞれ別々のユーザーとして登録する。そのうえで、各人が自分のロールに許された範囲だけを正しく見えて——そして見えないように——なっているか確認する。権限のバグは、実際に低権限のユーザーとして、理想的には高権限のユーザーと同時にログインしてみるまで見えないままだ。ここで何を突くべきかについてはOWASP Authorization Cheat Sheetが良いチェックリストになる。
- 重複アカウントの処理: 異なるアドレスで二つのアカウントを登録し、そのうえで一方を再利用しようとしてみる。アプリは期待どおりに重複を検出するか。大文字・小文字だけが異なる同一アドレスや、末尾に余計なドットが付いた場合はどうか。新鮮なアドレスがあれば、こうしたエッジケースは造作なく用意できる。
- 紹介・招待報酬フロー: 紹介者への報酬は通常、被紹介者がサインアップして認証を完了して初めて付与される。両方が発火する様子——招待が送り出される様子と、二人目のユーザーがフローを完了したときに報酬が届く（あるいは正しく届かない）様子——を見届けるには、本物の受信箱が二つ必要になる。
- マルチテナントの分離: 二つの別々の組織でアカウントを作成し、一方のテナントのデータがもう一方の画面・通知・メールに決して漏れ出さないことを確認する——まさにNISTのクラウドマルチテナンシーに関するガイダンスが明確に指摘している類の不具合だ。間違った受信箱に紛れ込んだアドレスは、データ分離のバグの最初の目に見えるサインであることが多い。
- 同時サインアップ: 複数のユーザーを同じ秒内に登録し、トークン生成における競合状態（レースコンディション）、一意制約の衝突、そして一部の認証メールが他より大幅に遅れて届くようなキューの遅延を洗い出す。
- シートとプランの上限: あるプランを、異なるユーザーでシート上限まで埋め、そのうえでもう一人追加しようとしてみる。上限は守られるべきで——さらに、あふれたユーザーが遭遇するエラーは、500ではなく明確なものであるべきだ。
- 通知の一斉配信: あるアカウントでアクションを実行し、正しいチームメイト——そしてその人たちだけ——が通知メールを受け取ることを確認する。うっかり全員に、あるいは誰にも送ってしまうことは起こりやすい。
手に負える範囲に収めるワークフロー
実用的なコツは、各タブをテストの中の名前付きの登場人物として扱うことだ。ユーザーごとに一つずつタブを開き、どれがどれか——オーナー、管理者、メンバー——を先に決めてから、各アドレスをそれぞれのサインアップにコピーする。タブは一目で見渡せるように並べておく。配信は事実上即座なので、招待は送った瞬間に届くのが見え、共有受信箱をポーリングするやり方では決して得られないほど、原因と結果がはっきりする。
どのランダムなアドレスがどのロールに対応するかを、テスト手順の横にメモしておこう——アドレスは選ぶものではなく生成されるものなので、ちょっとしたメモが後の混乱を防いでくれる。そして見返りはこうだ。メールが間違ったタブに現れたその瞬間に、それがサポートチケットになるずっと前に、ルーティングや分離のバグをその場で捕まえたことになる。
メールが届いたら確認すべきこと
メールを受け取るのは、まだ半分でしかない。メッセージが届いたら、数秒かけて実際に検証しよう。
- 正しい宛先: 招待は招待したアドレスに届いたか——そして他のどこにも届いていないか。
- 正しいリンク: 承諾・認証用のURLは正しい環境を指し、正しいワークスペースとロールのコンテキストを持っているか。ハードコードされた本番リンクになっていないか。
- 正しい結果状態: 承諾後、新しいユーザーは正しい組織に、そのロールが持つべき権限をぴったり備えた状態で入っているか。
- 表示: メールは本物の受信箱で正しく見えるか——ボタンはクリック可能か、受信者の名前は差し込まれているか、「Hi {{firstName}}」のようなプレースホルダーが残っていないか。
- 分離: あるユーザーのメールが、誤って別のユーザーのデータを参照していないか。それは追いかける価値のある危険信号だ。
- タイミング: すべては数秒以内に届くはずだ。一定の遅延は、あなたの本物のユーザーも感じることになるキューやDNSの問題を示している。
きれいなテストデータが、無料で
見過ごされがちな利点がある。どの使い捨てアドレスも空の状態で始まり、1時間で消えるので、各実行は「既知のきれいな状態」から始まる。「確実に空の受信箱、まっさらな新規ユーザー」から始まるテストは、先週の残り物が結果を歪めていないかと気を揉むことなく、本当に信頼して何度でも再実行できるテストだ。再現性は良いQAの半分を占めるが、それをここでは何の後片付けもせずに手に入れられる。
探索的テストとリリース前のリグレッションに最適
この方法が真価を発揮するのは、探索的テストと、リリース前の手動リグレッションチェックだ。ほんの数分で、現実味のある小さな配役のユーザー——オーナー、数人のメンバー、外部からの招待者——を用意し、実際のチームがするようにプロダクトを一通り歩き、進めながらメールが発火するのを見届けられる。五つの本物の受信箱を用意することなく、「五人の別々の人物として同時にアプリを使う」に最も近いことができる。シングルユーザーの部分もテストしているなら、メール認証のテストとパスワードリセットフローに関する私たちのガイドが、これと自然に組み合わさる。
限界について正直であるべきところ
正直に言っておくべき点がいくつかある。ごまかしてもただ時間を無駄にするだけだからだ。一部のアプリケーションは、サインアップ時に既知の使い捨てメールドメインをブロックする——登録フォームがそのアドレスを拒否するなら、それはそのアプリ自身のポリシーであり、そうした特定のテストには、代わりに許可リストに登録された社内ドメインが必要になるかもしれない。またこれは手動の探索的なワークフローでもある。あなたはAPIを呼ぶのではなくブラウザを操作しているので、CIでの自動化されたエンドツーエンドのメールテストを置き換えるのではなく補完するものだ。そして出荷前には、GmailやOutlookのような本物の受信箱で最終チェックを行おう——配信まわりの細かな挙動や迷惑メールフォルダの振る舞いは、本物のプロバイダを相手にしなければ姿を現さないからだ。
手短に言えば
受信箱ひとつでのテストは、シングルユーザーのバグを見つける。実際に本番までたどり着くバグは、ユーザーとユーザーのあいだの隙間——招待、ロール、テナント、上限、そして競合——に潜んでいる。使い捨て受信箱を使えば、一人のテスターがチーム全体を一度に演じられ、しかも実行のたびにきれいな状態から始められる。かかる時間は、タブをいくつか開くのとほとんど変わらない。temp-email.aiにアクセスし、ユーザーごとにタブを開いて、本当に重要なシナリオのテストを始めよう。