July 2020

Since being jointly established by SoftBank, Yahoo! Japan, and Paytm in 2018, PayPay has become…

Hello, I’m Masaki from the PayPay product team. This year, PayPay participated in the hackathon…

こちらはAutomateシリーズのパート2です。パート1はこちらあります。 自動化テストを実行している皆さん、こんな経験はありませんか？ローカルデバイス上では完璧にテストスクリプトが実行できるのに、サーバーや他のデバイスで同じスクリプトを実行してもうまくいったりいかなかったりする。これはテストの「Flakiness（不安定性）」と呼ばれ、誰もが直面する課題です。Flakinessの要因には様々なものがあります。本ブログシリーズではこれらの要因を一つずつ取り上げていきたいと思います。では、皆さんリラックスしてしっかり聞いてください。冷静さと忍耐力で、問題解決を図っていきましょう。 Flakinessを引き起こす原因として最も多いのが、テストシンクロナイゼーションです。テストスクリプトが、テスト対象のアプリケーション（AUT）と正しくシンクロナイズできていないことが原因です。テストスクリプトがAUTでアクションを実行しようとすると、AUTの準備がまだできていないか処理中かのどちらかでうまく作動しないことがあります。さて次に「忍耐力」によってテストの信頼性を高め、より強固にする方法を説明します。 Patience Flow Diagram（忍耐力フロー図） 各ステップでAUTとのやり取りが発生する時、上記のフロー図の指示通りに処理を行う必要があります。スタートしてから処理が完了するまでの時間の上限を予め定義し、AUTとのやりとりが発生する度に一定のインターバルを設けます。インターバルの中でAUTが処理やロードを行う時間を確保することで、テストがその処理に耐える力が強くなります。処理時間の上限はセット単位でもスクリプト単位でも定義することが可能ですが、具体的な数値はSLA（サービスレベル合意書）の記載に合わせるか、もしくはプロダクト管理部門と相談して特定のアクションに対して顧客の待ち時間の上限をどの程度に設定すべきか決める必要があります。 では例をみてみましょう。Webアプリを扱っていてログインページがある場合、テストシンクロナイゼーションの障壁となるのがネットワークの接続性とページロードです。上述のロジックの通りに例えば20秒の上限時間を設定したとします。その間にテストスクリプトが、ログインに必要な入力フィールドの可用性をブラウザでチェックし、同じアクションを1秒のインターバルを空けてポールまたはクエリして、最大20秒の間に処理するようにします。モバイルアプリを扱っている場合も同じで、この場合はアプリ内のスクローリングや処理がテストシンクロナイゼーションの障壁となります。 この「忍耐力フロー図」を使用して、PayPayはステージングと本番環境で毎日、毎時間、毎分テストを実行し、テストコードがいつでも正しく実行できることを保証しています！そのために、いくつかのテストコードメカニズムをビルドしましたが、これは来月のブログでご紹介したいと思います。お楽しみに！ このブログテーマは、Automation test（サービスの開発段階でのテストをマニュアルではなく自動で行う仕組み）についてです。おもしろい情報のアレコレ、テスト中によくある誤解や、迅速にスケールアップを実現し継続的なテストを行うインフラをどうやって作るかなどを、PayPayがこれまでに辿った道のりから、体験談として共有します。