QAテスターのためのプロキシ：出張なしで20か国からウェブアプリケーションをテストする方法

新しいリリースを展開したところ、1時間後にバグレポートが届きます。「ドイツではページのバージョンが異なる」、「アメリカでは支払いが機能しない」、「ロシアではコンテンツがブロックされている」。ローカルマシンで再現することは不可能です。ここでプロキシは「アービトラージャーのツール」からQAエンジニアの本格的な作業ツールに変わります。

この記事では、アプリケーションの地理的依存性をテストするためにプロキシを正しく使用する方法、QAのさまざまなタスクに適したプロキシの種類、地理コンテンツの確認から支払いゲートウェイのテストまでのステップバイステップのシナリオを示します。

QAテスターにプロキシが必要な理由: 実際のシナリオ

多くのチームは、ローカルマシンからのみ「国際的」なアプリケーションの動作をテストしており、時折VPNを使用しています。これにより、大きな盲点が生まれます。VPNはIPアドレスを変更しますが、特定の国のユーザーの実際のネットワークをシミュレートすることはできません — プロバイダー、接続タイプ、モバイルオペレーター。プロキシは、必要な地域またはネットワークタイプの実際のIPアドレスを介してインターネットにアクセスする機会を提供します。

以下は、QAテスターが日々直面する具体的なタスクです:

• 地理的コンテンツとローカリゼーション。 アプリケーションは、ユーザーの国に応じて異なるコンテンツを表示します: 現地通貨での価格、地域のプロモーション、ブロックされたセクション。プロキシなしではこれを確認することはできません。
• 地域の支払いシステム。 StripeはEUと米国で異なります。ブラジルのPayPalは別のケースです。支払いフローをテストするには、必要な国から行う必要があります。
• CDNとキャッシング。 コンテンツ配信ネットワークは、異なる地点から異なるバージョンのリソースを提供することがあります。QAは、静的コンテンツがアジア、ヨーロッパ、アメリカのユーザーに対して正しく読み込まれることを確認する必要があります。
• ブロックと制限。 一部の国では、アプリケーションの機能の一部が法律により利用できません。ブロックが正しく機能し、ユーザーが理解できるメッセージが表示されることを確認する必要があります。
• 地理的A/Bテスト。 実験がイギリスのユーザーのみに対して開始された場合、QAはイギリスのIPでアクセスし、必要なバージョンが表示されることを確認する必要があります。
• SEOテスト。 メタタグ、hreflang、地域のページバージョン — これらはすべて、対応する国のIPから確認する必要があります。さもなければ、検索エンジンと実際のユーザーは異なるものを見ることになります。
• 異なる地域からの速度テスト。 シンガポールとモスクワからのページの読み込み時間は、3〜5倍異なることがあります。プロキシを使用することで、これを1つの作業場所で再現できます。

テストに適したプロキシの種類

すべてのプロキシがQAにとって同じように便利であるわけではありません。プロキシの種類の選択は、何をテストしているかによって異なります。主要な3つのタイプとそれらのテスターのタスクへの適用性を見ていきましょう。

レジデンシャルプロキシ

これは特定の国や都市の実際の家庭ユーザーのIPアドレスです。ウェブサイトは彼らを通常の人々として認識し、データセンターや企業ネットワークとしては認識しません。 レジデンシャルプロキシは、ほとんどのQAタスクに最適な選択です: 地理的コンテンツのテスト、A/Bテスト、支払いフロー、ローカリゼーションの確認。彼らは必要な国の実際のユーザーを最大限に正確にシミュレートします。

QAにとっての利点: サイトやアプリケーションからの高い信頼、広範な地理的カバレッジ（100か国以上）、特定の都市やプロバイダーを選択する機会。欠点は、データセンターのプロキシよりも若干遅いことがあり、パフォーマンステストの際に考慮する必要があります。

モバイルプロキシ

モバイルオペレーターのIPアドレス（3G/4G/5G）。モバイルユーザー向けのアプリケーションの動作をテストする際に非常に重要です。多くのウェブサイトやアプリケーションは、モバイルIPからのアクセス時に異なる動作をします: モバイルバージョンを表示したり、異なるコンテンツを表示したり、地理的位置を異なる方法で処理したりします。 モバイルプロキシは、エミュレーターを介してモバイルアプリケーションをテストする際や、ウェブバージョンの適応性を確認する際に欠かせません。

また、モバイルIPは動的アドレスであり、1つのオペレーターが数千の加入者に配布します。これは、テストトラフィックが集中的なリクエストでも疑わしく見えないことを意味します。

データセンタープロキシ

最も速くて安価です。負荷テスト、大量のリクエストを伴う自動テスト、APIエンドポイントの確認に適しています。 データセンタープロキシは「家庭用」でないユーザーとして簡単に検出されるため、ユーザーエクスペリエンスのテストにはあまり適していませんが、技術的な確認や負荷テストには最適な選択です。

地理的依存コンテンツのテスト: ステップバイステップ

地理的依存テストは、QAにおけるプロキシの最も一般的な使用シナリオです。以下は、コードを書くことなく、通常のブラウザを介して実行する方法です。

ステップ 1. プロキシのデータを取得する

サービスに接続すると、接続データが提供されます: ホスト（IPまたはドメイン）、ポート、ログイン、パスワード。レジデンシャルプロキシの場合、通常は個人用アカウントまたは接続文字列のパラメータを介して国と都市を選択できます。

レジデンシャルプロキシの接続文字列の例は次のようになります: ホストには国のパラメータが含まれています（例えば、country-deはドイツ用）、ポートは標準、ログインとパスワードはあなたの認証情報です。

ステップ 2. ブラウザでプロキシを設定する

手動テストには、システム設定を変更せずにプロキシを迅速に切り替えることができるブラウザ拡張機能を使用するのが最も便利です。人気のオプション: Proxy SwitchyOmega（Chrome/Firefox）、FoxyProxy（Firefox）。

Proxy SwitchyOmegaを介したステップバイステップの設定:

1. Chrome Web Storeから拡張機能をインストールします。
2. 拡張機能の設定を開き → 「新しいプロファイル」をクリック → 「プロキシプロファイル」を選択します。
3. プロキシのデータを入力します: プロトコル（SOCKS5またはHTTP）、サーバー（ホスト）、ポート（ポート）。
4. 認証が必要な場合は、対応するフィールドにログインとパスワードを入力します。
5. プロファイルを保存し、ブラウザのツールバーの拡張機能アイコンを介して有効にします。
6. whatismyip.comまたは2ip.ruにアクセスし、必要な国のIPが表示されていることを確認します。

ステップ 3. 地理的依存要素を確認する

必要な地理的プロキシに接続した後、確認します:

• インターフェースの言語（IPによる自動検出）
• 価格の通貨と支払い方法
• 特定のウェブサイトのセクションの有無
• 特定の地域向けのバナーとプロモーション
• hreflangタグの正確性（ページのソースコードを開く）
• 地域のサブドメインへのリダイレクト（例: de.site.comではなくsite.com）
• クッキーバナー（EUではGDPRにより必須）

異なるタイプのネットワークからのテスト

地理に加えて、ユーザーのネットワークタイプに応じたアプリケーションの動作をテストすることも重要です。これは、グローバルなオーディエンスを持つ製品にとって特に重要であり、ユーザーの大部分がモバイルデバイスを介してオペレーターのネットワークからアクセスしています。

企業ネットワークとファイアウォール

企業ネットワークのユーザーは、しばしば企業のプロキシサーバーやファイアウォールを介して作業し、特定のリクエスト、WebSocket接続、または外部CDNをブロックします。このような条件をシミュレートするために、テスターは制限された設定のデータセンタープロキシを使用します — これにより「厳しい」企業環境を再現できます。

このシナリオで確認すること: プッシュ通知が機能するか、Google Fontsからフォントが読み込まれるか（企業のファイアウォールによってしばしばブロックされる）、OAuthによる認証が正しく機能するか。

モバイルネットワーク（3G/4G/5G）

モバイルプロキシを介して、テスターはモバイルIPだけでなく、モバイルネットワークの実際の条件を取得します: 遅延、NATの特性、モバイルオペレーターからの特定のリクエストヘッダー。いくつかのアプリケーションは、モバイルIPからのリクエストを異なる方法で処理します — たとえば、ウェブバージョンの表示の代わりにアプリのダウンロードを提案します。

モバイルプロキシをChrome DevToolsのデバイスエミュレーターと組み合わせて使用します（デバイストールバーのモード） — これにより、実際のユーザーに最も近い環境を得ることができます。

アクセス制限のあるプロバイダー

一部の国では、インターネットプロバイダーが特定のリソースをブロックしたり、競合他社へのトラフィックを遅くしたりします。あなたの製品が制限されたインターネット市場（中国、イラン、ロシア）で機能する場合、これらの国からのレジデンシャルプロキシを介したテストは、サービスの可用性の実際の状況を示します。

支払いゲートウェイと地域機能のテスト

支払いテストは、国際製品におけるQAの最も困難な領域の1つです。支払いシステムは、詐欺チェックのために地理的位置を積極的に使用します: ユーザーのIPが支払いアドレスやカードの国と一致しない場合、トランザクションは拒否されるか、疑わしいものとしてマークされる可能性があります。

QAテスターは、テストカードが発行された国のIPからアクセスし、支払いフロー全体を通過するというシナリオを再現する必要があります。プロキシなしでは、1台のマシンから複数の地域でこれを行うことは不可能です。

支払いテストでプロキシを介して具体的に確認すること

• 地域ごとに異なる支払い方法の表示（PayPal、Stripe、Klarna、SEPA、PIX）
• 通貨の変換と手数料の表示の正確性
• 異なる国からの3DS認証の動作
• IPとカードの国が一致しない場合の動作（正しいエラーメッセージが表示されるべき）
• 地域の税金（EUのVAT、オーストラリアのGST） — 正しく計算されているか
• 地域の支払い方法の動作: オランダのiDEAL、ドイツのSofort、ブラジルのBoleto

地域機能のテスト（GDPR、CCPAなど）

製品に対する法的要件は、ユーザーの国によって異なります。QAにとって重要なのは、アプリケーションが管轄権を正しく特定し、必要なルールを適用することを確認することです:

• EU (GDPR): ヨーロッパのIPからアクセスすると、トラッキングを拒否するオプションを持つクッキーバナーが表示されるべきです。
• カリフォルニア (CCPA): カリフォルニアのユーザーに「私の個人情報を販売しないでください」というリンクが表示されるべきです。
• ロシア: ロシアのユーザーのデータがロシアのサーバーに保存される必要がある場合 — ローカリゼーションが正しく機能していることを確認してください。
• 中国: 中国のIPからアクセスすると、外部サービス（Google Analytics、Facebook Pixel）がブロックされているか、ページが壊れないか確認してください。

プロキシをサポートするQAツール

プロキシは、ブラウザで手動で使用するだけでなく、自動化テストやQAツールに統合することもできます。主要なオプションを見てみましょう。

Postman

Postmanでプロキシを介してAPIをテストするには: 設定に移動 → プロキシ → システムプロキシを使用するか、プロキシを手動で指定します。これにより、異なる国からのリクエストに対するAPIエンドポイントの応答を確認できます — 地理的に依存するAPIにとって重要です。

Charles Proxy / Fiddler

これらのツールはHTTP/HTTPSトラフィックをキャプチャし、自身がプロキシです。外部プロキシサーバー（アップストリームプロキシ）を介してトラフィックを通過させるように設定できます。これにより、リクエストを同時にキャプチャして分析し、必要な地理的IPでテストできます。

Charlesでは: プロキシ → 外部プロキシ設定 → 外部プロキシを使用するを有効にし、プロキシサーバーのデータを指定します。

PlaywrightとSelenium

自動化テストでは、プロキシはブラウザの設定レベルで接続されます。Playwrightでは、ブラウザコンテキストを作成する際にproxyパラメータを介して行います。Seleniumでは、プロキシサーバーを指定してChromeDriverのオプションを介して行います。これにより、手動設定なしで数十の国からテストスイートを並行して実行できます。

BrowserStackとSauce Labs

テスト用のクラウドプラットフォームには、異なる地域からのテスト用の組み込みツールがあります。ただし、特定のプロバイダーやネットワークタイプ（モバイル/家庭用）を選択する機能は制限されています。プロキシはより柔軟性を提供します: 国、都市、IPタイプ、プロバイダーを自分で選択できます。

k6とJMeter（負荷テスト）

異なる地域からの負荷テストでは、データセンタープロキシがHTTPクライアントの設定を介して接続されます。これにより、異なる国からの実際のユーザーによる負荷をシミュレートし、CDNや負荷バランサーが地理的に分散したトラフィックにどのように対処するかを確認できます。

チェックリスト: リリース前にプロキシを介して確認すること

国際的なオーディエンスに影響を与える各リリースのために、このチェックリストを使用してください。製品の主要な地域を最低3〜5個確認することをお勧めします。

プロキシを介したテストでの一般的な間違い

経験豊富なテスターでも、プロキシを使用する際に間違いを犯すことがあります。最も一般的な間違いを見てみましょう。

間違い 1: プロキシが実際に機能しているか確認しない

テストを開始する前に、必ず独立したリソース（whatismyip.com、2ip.ru、ipleak.net）で現在のIPを確認してください。プロキシが設定されているが、ブラウザが直接接続を使用し続けることがあります — 特に拡張機能がアクティブでない場合や、システム設定との競合がある場合です。

間違い 2: DNSリークを無視する

DNSリクエストがプロキシをバイパスして、テスターの実際のIPを明らかにすることがあります。これは、地理的ブロックのテスト時に特に重要です — ウェブサイトはDNSを通じて実際の国を特定できる場合があります。IPアドレスが変更されていてもです。DNSリークをipleak.netやdnsleaktest.comで確認してください。

間違い 3: すべてのタスクに1つのプロキシを使用する

データセンタープロキシはユーザーエクスペリエンスのテストには適していません — ウェブサイトはCAPTCHAやブロックされたページを表示する可能性があり、実際のユーザーは決して見ることはありません。各タスクに適切なプロキシタイプを使用してください（上記の表を参照）。

間違い 4: ブラウザのキャッシュを忘れる

地理的位置を切り替える際、ブラウザは前のセッションからキャッシュされたコンテンツを提供することがあります。新しいプロキシに切り替える前に、常にキャッシュとクッキーをクリアするか、各新しい地理テストのためにインコgnitoモードを使用してください。

間違い 5: テストセッションを文書化しない

プロキシを介してバグを見つけた場合は、必ず記録してください: プロキシの国と都市、プロキシのタイプ（レジデンシャル/モバイル）、テストの時間、ブラウザのバージョン。これらのデータがないと、開発者は問題を再現するのが難しくなります。バグレポートにIPの確認を含むスクリーンショットを追加してください。

間違い 6: ドキュメントでプロキシとVPNを混同する

チームでは、バグレポートに「ドイツからVPNを介して再現しました」と書くことがよくありますが、VPNとプロキシは異なる方法で機能します。VPNはすべてのトラフィックを暗号化し、OSレベルでIPを変更しますが、プロキシはアプリケーションレベルで機能します。いくつかのバグにとっては、これは重要な違いです。ドキュメントで正確な表現を使用してください。

結論

QAテスターにとってのプロキシは、国際的なオーディエンスを持つ製品にとって基本的なツールであり、エキゾチックなものではありません。彼らは、異なる国のユーザーの実際の条件を再現し、地理的依存コンテンツ、支払いゲートウェイ、法的要件、CDNの動作を確認することを可能にします — すべてテスト担当者のデスクトップから、出張やリモートマシンなしで行えます。

重要な結論: ユーザーエクスペリエンスのテストにはレジデンシャルプロキシを使用し、モバイルシナリオにはモバイルプロキシを使用し、負荷テストやAPIテストにはデータセンタープロキシを使用してください。テストを開始する前にIPを常に確認し、DNSリークに注意し、地理パラメータを指定してテストセッションを文書化してください。

アプリケーションの地理的依存性のテストを開始したい場合は、レジデンシャルプロキシを試してみることをお勧めします — 彼らは必要な国からの実際のユーザーを最大限に正確に再現し、都市やプロバイダーまでの柔軟な地理的位置の選択をサポートします。