Shreyansh Pandey

こちらはAutomateシリーズのパート6です。パート1、パート2、パート3、パート4、パート5も読むことができます。モバイルテストの自動化を始めると、多くの人はテストの精度や端末とOSの組み合わせ、テスト範囲、使いやすさ等複数の課題に直面します。これらは、モバイルテスト特有の課題です。テスト範囲はWebテストに似ているものの、テストの対象はモバイルであり、範囲が多岐に渡るからです。 statcounter.comが行ったモバイル、タブレット、デスクトップの利用に関するグローバルリサーチによると、最近のモバイル利用率は全体の50%を超え、今も増え続けているそうです。Android市場は細分化されており、iOSも負けじと新しいデバイスをどんどんリリースしています。扱うデバイスの種類の多さという点において、モバイルテストは現在最も難しいテストと言えます。 モバイル上で実行できるアクションやジェスチャーの種類も増えており、開発者にとっては新しい思い切ったソリューションを構築するまたとないチャンスとなっていますが、自動テストを行うことはますます困難になっています。 これを課題と呼ぶのか、機会と呼ぶのかはさておき、様々なデバイスで自動テストを実行したいという強い思いは決して変わりませんが、できれば端末ごとにコードやスクリプトを維持するのは避けたいものです。そこで、PayPayの特許取得済みのシングルインターフェイスプログラムとロジックが活躍します！ 一度書けば、いつでも、どこでも、毎回、全ての場所で実行できます! 基本的なNLPを使用してAndroidやiOSなど、対象のOSに基づいて一度だけテストを作成するようにします。ステップファンクションとアシスタントファンクションを使って、異なるコンポーネント間の役割を厳密に分離し、テストを簡単に書いたり、さまざまなデバイスで快適にテストを実行できるようにします。 モバイル自動化テストは、1年で何千ものバグを見つけるのに役立ちます。私たちは常にアイデアと経験溢れる人達と一緒に仕事をしたいと思っています。フルスタックのテスターとして、PayPayで働いてみたい方は、是非お気軽にお問合せください。次回のブログでは、PayPayの開発ワークフローを使ったテスト連携方法についてさらに詳しく解説します。お楽しみに！

This is Part 5 of our automation series. Read Part 1 to understand of how to…

This is Part 4 of our automation series. Read Part 1 to understand of how to…

This is Part 3 of our automation series. Read Part 1 to understand of how to…

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

PayPayはいま日本で最も知られているQR決済サービスで、同時に、もっとも急速に成長を遂げているサービスでもあります。PayPayではアジャイルに動くことを心構えとして、継続的開発、継続的インテグレーション、継続的デプロイメント、継続的テストに努めています。このうち、本ブログシリーズでおもに扱う内容は継続的テストです。さて今回のトピックは何でしょうか。 どんなソフトウエアや開発フレームワークを構築する時も、小規模で開始し、シンプルな設計で維持することが非常に重要です。Automation testインフラを作るときは、特にこの点に注意しなければなりません。特に、Automation testチームが属するのは開発チームなのか、それともプロダクトマネージメントチームなのか、よく誤解されることがありますが、このアイデンティティ・クライシスがそもそもの問題の始まりであると言えます。 アジャイル開発がホットな昨今、最終的なプロダクトの品質保証が目的であれば、どこに所属しているかは全く重要ではありません。テストスクリプトを大量に作成するスピード感が求められ、開発者がアプリケーションを作ったり、プロダクトマネージャーが新機能を考案して展開したりする速さに匹敵する迅速な作業スピードが必要です。もし新しいものを作ったことでより一層問題が増えたのであれば、それは作り方を間違えたということです。Automation testは誰もが貢献できるよう、シンプルであることが重要です。また、どんなテストもこなせるよう、柔軟性と安定性が求められます。 さて、みなさん、ここから本題です。Automation testインフラを構築するにあたり、当然数多くの問題に直面することが予想されます。そこで、PayPayが実際に辿ってきた道のりをご紹介したいと思います。ここに書かれていることはすべて、PayPayがアジャイルなテスト環境を構築するにあたり、実際に経験してきた話を基にしています。 Baby Steps いつでもどこでも、どのようなインフラでも実行できるスクリプトを書くことが目標だと思いますので、テストスクリプトを作成する時はそれが1回目であっても 1,000 回目であっても、必ずこの手順を念頭に置いてください。これで必ず実行できる頑丈なテストスクリプトを作成することができ、テストを実施しているアプリケーションの正常な動作を保証できます。 間違ったテストや時間がかかりすぎるテストを実行しないようにするために、テストスクリプトは、失敗しないことがわかる既知の状態かまたは既知の場所でスタートしましょう。最初のステップが完了したら、次のテストポイントは特定のポイントに絞り、各テストステップでは一つのことだけを行うようにします。最後にクリーンアップを行い、テストを終了する時は、次のテストを開始するために今のテストを停止しなければならないことがわかる、既知の状態で終了するのが良いでしょう。 例えば、アプリケーションにログインページやサインアップページがあり、テストケースはログインやサインアップのテストに関連していないというような場合は、アプリケーションAPIを使用したり、事前に定義されたクッキーを設定したりして、ログインやサインアップが失敗しないように、必ずその特定のステップ用の別の自動化スクリプトを作成してください。また、各実行後にブラウザやモバイルアプリケーションを必ず閉じることで、常に分離させながらかつ相互に依存してテストを実行することができます。…