苦痛と神経を使わずに国際決済サービスをテストする方法

こんにちは！



私の名前はサーシャ・ズバルチュクです。私は3年前にジュニアマニュアルQAとしてSolidに来ました。それ以来、私は自動化エンジニアになり、最初に協力したQAスクールを卒業し、プロダクトマネージャーに異動しました。



この記事では、支払いシステムのテストの機能について説明し、チームの経験を共有します。テスト対象、方法、直面する課題、およびそれらへの対応方法です。この経験は、プロジェクトでテストプロセスを構築する人、つまりQAエンジニアと製品/プロジェクトマネージャーの両方に役立ちます。



テクニックや特定のツールについては詳しく説明しませんが、主なアイデアについて説明します。それは、技術的に複雑なサービスをテストするプロセスを可能な限り透過的かつ穏やかにする方法です。



支払いサービスの構成と仕組み



Solidは、世界中の企業が銀行カードや電子ウォレットからPayPalやAlipayまで、さまざまな方法でオンライン顧客支払いを受け入れることを可能にするゲートウェイです。



このストーリー全体には、4人の主要なプレーヤーがいます。

• ユーザー（彼は購入者でもあります）;
• 商人-インターネット上で商品/サービスを販売し、それらのためにお金を受け取りたいと考えている企業。
• 支払いゲートウェイ-堅実。
• 銀行（買収者） -リアルマネーで取引を行う金融機関。

簡単に言えば、 次のようになります。簡単に言えば、私たちは商人が収益を上げてお金を稼ぐのを助けます。



あなたは質問があるかもしれません：彼らが銀行と直接働くことができるのに、なぜ商人はSolidを選ぶのですか？簡単です。1）多くの銀行があり、それぞれに独自の特徴があります。さまざまな国のさまざまな銀行を1つのインフラストラクチャに統合することで、最大のコンバージョンと収益を実現します。 2）支払いロジックと不正防止に関する幅広い専門知識があります。 3）銀行支払いに加えて、特定の地域で人気のあるすべての代替支払い方法を受け入れます。4）より安価です。



最初のポイントから始めましょう-さまざまな国で支払いを行うこれらの機能は何ですか？たとえば、米国では、奇妙なことに、カードデータのみを使用して、ウクライナほど簡単に支払いを行うことはできません。そこで、銀行は請求先住所や郵便番号などの追加の支払人の詳細を確認する必要があります。



同様のニュアンスがたくさんあります。カード支払いの代替手段と同様に。たとえば、オランダとドイツでは、人々は地元のインターネットウォレットを使用するのが好きです。中国で最も人気のある支払い方法は、Alipay、WeChat Pay、UnionPayです。そしてナイジェリアでは、インターネットで商品の代金を支払うために、ユーザーは現金で銀行に行きます！



銀行カードからPayPal、eウォレット、Google Pay、Apple Pay、SMSまで、例外なくすべての一般的な支払いを受け付けます。Solidの助けを借りて、商人は1つの統合ですべてのタイプの支払いを処理するためのアクセスを取得します。さらに、ゲートウェイには、独自の不正防止、支払いルーティングシステム、不当なチャージバックを防止するツールなどがあります。

支払いシステムをテストする理由とテストしないことのリスク

多くの商人がSolidに接続しています。したがって、私たちはビジネスだけでなく、私たちに接続しているすべてのクライアントの収益化にも責任があります。私たちの側で何かがうまくいかない場合、私たちはあまりにも多くの企業を失敗させます。逆もまた同様です。支払いサービスをテストして改善することで、他のビジネスの製品を改善します。



残念ながら、支払いの成功に加えて、システムとユーザーの両方でエラーが発生する可能性があります。支払いの100％がどの場所でも正常に通過することは決してないことを理解することが重要です。しかし、私たちの側では、支払いの変換を可能な限り行うためにあらゆることを行う義務があります。



支払いゲートウェイのテストは、数十のマイクロサービスと相互接続のかなり複雑なメカニズムであるため、日常的な作業ではありません。すべてを3段階でテストします。まず、分離された環境で各タスクをチェックし、次にそれらを組み合わせて、段階でリリース候補でチェックします。統合ですべてがどのように機能するかを確認し、次にすべてをリリースして、本番環境で再度テストします。



具体的に何をテストする必要があるかを詳しく見てみましょう。

支払いシステムのテストの機能

支払いシステムは、APIとWebインターフェイスの両方で構成されています。他の製品とは異なり、支払いシステムのAPIとWebテストに基本的な違いはありません。主な機能は、さまざまな地域の特定の支払いと、すべての補助サービスをテストすることです。



支払いのテストは難しくないようです。支払いを行い、あるアカウントから借方に記入され、別のアカウントに貸方記入されていることを確認する必要があります。しかし、ニュアンスがあります。テスターは、さまざまな国での支払いの詳細、および場合によっては現地の法律や銀行規制の微妙な違いを知る必要があります。



2番目のポイントは、さまざまな種類の支払いです。サブスクリプション、最初の支払い、承認（アカウント内のお金の凍結）、電子ウォレットを介した支払いです。それぞれに独自のテストの詳細があります。



通貨の操作には特に注意を払う必要があります。すべての通貨に部分的な部分があるわけではありません。たとえば、hryvniaにはペニーがありますが、Chileanpesoにはありません。ウクライナで支払い金額100を送金すると、銀行は1 UAH、つまり100コペックを償却します。そしてチリでは、それは100ペソを意味します。ご覧のとおり、そのような瞬間を見逃してはなりません。

支払いシステムでテストする必要があるもの

すべてのクライアント（Web、モバイルアプリケーション、およびバックエンドサービス）は、SolidAPIを使用して通信します。ゲートウェイ自体は別のクラスターに配置され、さまざまなシステム（不正防止、トークナイザー、銀行など）と通信します。



堅実な開発者は、いくつかのタイプの問題の解決に取り組んでいます（そして、これらのタスクはすべて、QAチームが自由に使えるようになります）。

• ( , , , , );
• (PayPal, Alipay Visa Mastercard);
• : API, ;
• ( , );
• , (, , -);
• .

開発者から直接行われるタスクに加えて、新しいマーチャントに接続するときのすべてのデータとUATのチェック、DevOpsチームからのタスクのチェック、不正防止ルールの設定など、他のタスクも受け取ります。



要約すると、私たちがテストするものはすべて、次のカテゴリに分類できます。



堅牢なバックエンドサービス：

• 不正防止;
• サブスクリプションサービス;
• 支払いルーティング;
• 会計および財務管理システム。
• 外部サービスとの統合。

銀行との統合：

• 通貨での作業の正確さをチェックする。
• さまざまな種類の支払いの検証（カードデータによる最初の支払い、トークンによる支払い、払い戻し、お金の凍結など）。
• 通知の処理。

代替（カード以外）の支払い方法：

• 支払いの確認;
• 場所の特徴を確認します。

管理者：

• 内部管理パネル（Solidアナリストが支払いフォームの変換に関するA / Bテストを実行し、不正防止のルールを設定するのに役立つすべてのもの）;
• 商人のための管理パネル。

ユーザーインターフェイス：

• 支払いフォームとページの外観。
• フォームが特定の地域の言語で表示されているかどうか（Solid支払いフォームは世界中のすべての言語で利用できます）;
• 金額と通貨の正しい表示。
• フォームでのユーザーアクションの追跡。
• ページステータス。

その他：

• 新しいマーチャントをSolidに接続するときのUAT。
• 新しい構成をチェックするためのリスク部門からのタスク。
• 機能的健康調査（たとえば、Apple PayはWKWebViewで機能しますか）。

成功をテストする手順

オートメーション

支払いプロバイダーなどの大規模なITソリューションを使用する場合は、機能の個々の要素の動作だけでなく、それらの相互作用も常にテストする必要があります。自動化なしでは機能しません。一部のサービスが自動テストでカバーされていない場合、失敗を回避することはできません。可能な限り自動テストを実行します。タスクを環境に注ぎました-テストを実行します。いくつかのタスクをリリース候補にマージしました-テストを実行します。



私たちの場合、次のようになります。

• 開発者は、タスクを実装するときに独自にテストを実行します。
• テスターは、隔離された環境でタスクをテストするときにテストを実行します。
• 新しいバージョンのビルドがビルドされると、テストが自動的に開始されます。
• 自動テストは、Prod環境で常に実行されています。

自動テストの実行には時間がかかるため、常にこのプロセスを可能な限り最適化するよう努めています。テストはマルチスレッドで実行され、重要度によってタスクに分割されます。



Solidのコア支払い処理機能を検証する最小限のテストセットがあります。1分以内に実行されます。 Solid APIおよびその他のマイクロサービスの他のすべてのテストには、約3〜4分かかります。もちろん、UIテストは少し遅くなります。しかし、ここでも改善と最適化に取り組むことをやめません。



支払いをテストするときに、分離テストが最良のオプションではないのはなぜですか？詐欺防止のケースについてお話しします。



各Solidマーチャントは、ルールの設定、それらの動作方法に関連する不正防止アカウントを持っています。たとえば、ユーザーがマーチャントと1日に3回を超える支払いを行った場合、4番目の支払いをブロックします。または、5人を超えるユーザーが同じカードで支払いを行う場合は、ブロックしてブラックリストに追加します。自動テストでカバーしましたが、問題が発生しました。







最初は、テストアカウントのすべてのルールを複製し、不正行為をシミュレートしましたが、テストは機能しているように見えました。しかし、商人自身が不正防止ルールを組み合わせる状況がよくあることが判明しました。たとえば、そのうちの3つが機能しました。



特定のルールごとに各支払いを分離することで、ルールの組み合わせの可能性や、支払いプロセスに対する他のサービスの影響を排除しました。



各支払いの方法：テストデータをクリアし、支払いが特定のルールに該当するためのすべての条件を作成し、それが機能しました。しかし、支払いが1つのルールに該当する理想的な状況は決してないため、職場環境ではそうなるというのは事実ではありません。



私たちは、クライアントの実際の不正防止ルールをテストマーチャントに接続することにしました。それから彼らはより明確に解決し始めました。つまり、分離されたルールを作成するのではなく、特定のクライアント用にまとめてテストする必要がありました。



現在、堅実なお客様は、不正防止ルールを自分でカスタマイズできます。ある商人にとっては詐欺のように見える取引が、別の商人にとっては当たり前のことかもしれないからです。

オンラインストアで1日に5回購入する場合、これが標準です。最初はモバイルのケースが好きで、次にノートブックなどが好きでした。しかし、フィットネスアプリケーションの場合、これはすでに異常です。人が1日に5つのトレーニングプログラムを購入する可能性は低いです。



自動化は本当にバランスを構築するのに役立ちます。新しい機能と人間の注意を必要とするシナリオのみが手動でチェックされ、その他はすべて自動化されます。自動化は、テストコストと人的リスクの両方を削減するのに役立ちます。

技術仕様の段階でのテスト

機能の機能を直接チェックすることに加えて、開発者と管理者が実装された機能を同じように認識できるようにすることに多くの時間を費やしています。当たり前のようですが、多くの人がそれを無視しています。



すべての構成サービスは非常に複雑であり、さまざまな可能性があり、細部が細かい場合でも、サービスが期待どおりに機能しない可能性があります。



「早期テスト」手法には、一度にいくつかの利点があります。

• 開発チームはタスクを正しく理解し、修正に時間を無駄にすることはありません。
• 適切に記述された技術仕様は、優れたドキュメントの70％です。
• テストチームは事前にTORに精通しているため、テストシナリオも事前に検討され、実装されたタスクがテストに到達した瞬間に、プロセスが高速化されます。

優れたテストドキュメント

本当に優れた構造化された内部ドキュメントは、テスト時の戦いの半分です。ほとんどすべての機能を自動化する必要があるという事実にもかかわらず、手動作業が無駄になることは決してありません。



さまざまな機能のテストプロセスの説明、考えられる問題の解決策が記載された記事、さまざまなマニュアルにより、テストチームの作業がスピードアップします。



Solidは、独自のナレッジベースを作成しました。各銀行と代替の支払い方法がさまざまな場所でどのように機能するか、銀行がサポートする支払いの種類、および原則として特定の地域で支払いが行われる方法について説明します。



このような基盤は、私たちにとって課題となっている大規模で複雑なタスクです。すべてのドキュメントをまとめて、アクセス可能な方法でプロセスを説明する必要がありました。でも今は新入社員が来ても問題ありません。何かが最初にどのように機能するかを思い出すのは難しく、テストドキュメントがある場合、間違いを犯す可能性は最小限です。明確な文書により、テスターは支払いが行われない理由を正確に判断できます。それは間違いであるか、このタイプの支払いはこの銀行では機能しないはずです。



別の例を挙げましょう。支払いフォームの国際支払いシステムのロゴを変更した後。クライアント向けに200以上の異なるデザインがあります。デザインごとに、フォーム上のフィールドの構成がいくつかあります。たとえば、ブラジルの場合、追加のCPFフィールドが追加されます。これは識別コードの類似物です。



ロゴの新しいサイズにより、フォームの一部のフィールドが移動したり、消えたり、クリックできなくなったりする可能性があります。Solidテストチームの誰も、200個のフォームすべてがどのように見えるかを物理的に知っているだけです。



このタスクのテストは神経質になりましたが、その結果、各販売者の参照フォームを使用してナレッジベースを作成し、自動テストでカバーしました。現在、設計に関連する変更を恐れていません。

***

最後に、処理の世界から少し興味深い事実をお話しします。ウクライナでの制限付きカードの減少の割合は非常に低く、1〜2％です。ウクライナの銀行は不正防止に優れているか、ウクライナのユーザーのカードデータを盗もうとは思わないかのどちらかです...



それでも、理想的な開発およびテストプロセスを備えた製品はありませんが、改善することはできます。結局のところ、すべてのビジネスのタスクは、高品質の製品をリリースすることです。QAエンジニアでない場合、他に誰がこれを手伝ってくれるでしょうか？



コメントで良いテストプロセスの原則を共有していただければ幸いです。