Engineering

As our product becomes more popular, the number of transactions that we handle daily keeps…

Paypay uses different data storage solutions in it’s microservices, such as SQL Database, NewSql Database,…

  As you can imagine, PayPay deals with a lot of information and data, which…

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

Like PayPay, other cashless payment services each have their unique QR code, with their own…

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

こちらはAutomateシリーズのパート4です。パート1、パート2、パート3、パート5、パート6も読むことができます。テストには様々な専門用語が使われますが、中には直接テストと関係ないものまで存在します。今までの投稿を読まれた方はお気づきかもしれませんが、このブログでは分かりやすい言葉や、見て楽しんで頂けるような図を用いて、複雑な内容を説明するように心がけています。このブログシリーズを始めるにあたって、分かりやすく内容を解説する、ということを私たちの方針として心がけています。一つ一つこういった小さな努力を積み重ね、それを実行することで大きな結果につなげることができると信じています。 テストには様々なレベルが存在します。一回のブログでそのすべてを語ることはできませんので、今後のブログで少しずつ説明していきたいと思います。 まず、フルスタック・テスター（PayPayの場合はこちら）としては、API自動化テストが最小レベルのテストであることを認識しておきましょう。アプリケーション・プログラミング・インターフェイス（API）は、徐々に様々な製品やサービスの基盤となってきました。PayPayでも、これらのREST APIがあるからこそ多くのマイクロサービスが一体となって機能しています。 AUTの構造 ウェブやモバイルに関わらず、多くのアプリケーションがこのREST APIによって動いているので、テストでこのAPIをターゲットにするのは妥当な方法です。このテストでは、バックエンドサービスにリクエストする際、AUT（テスト対象アプリケーション）と同じ挙動をエミュレートしなければなりません。 各画面のリクエストのシーケンスを判断し、画面、もしくはユーザーシナリオに基づいてテストを分類します。フロントエンドを開発している同僚にAPIのスペックを共有してもらうか、もしくはアーキテクチャの設計図があれば内容を把握できるはずです。準備ができたら、AUTと同じリクエストのシーケンスに基づいて自身のテストを作ってください。例えば、AUTにログイン画面があれば、それに必要なすべてのAPIとリクエストのシーケンスを洗い出しましょう。この例の場合、ペイロードがコールされるので、おそらくユーザー名とパスワードでログインするAPIリクエストが一つあるだけだと思います。 日々の小さな積み重ねこそが、最も重要な意味を成す。 APIの自動化テストのおかげで、PayPayでは本番環境よりも前の段階（ステージングやサンドボックス環境）でバグを見つけることができています。また同時に、本番環境においてモニタリングシステムの強化にもつながっています。では、次のテストレベルに関しては、来月のブログでお話しすることにしましょう。

こちらはAutomateシリーズのパート３です。パート1『自動化の進め方』はこちらあります。パート2 『自動化テストのFlakiness（不安定性）をなくすには？』はこちらあります。 ある夏の夜心地よい眠りから一気に現実に引き戻される事象が発生。自動モニタリングシステムの「本番環境のABCシステムに問題発生」のアラートにすぐ飛び起きて手動で確認したところ、ABCシステムは特に問題なさそう。 調べたところ、誰かが修正を反映したために自動モニタリングシステム自体に何らかの不具合が発生しただけだと知り、拍子抜けしたことがあります。あなたも同じ経験がありませんか？ 自動テストを扱うエンジニアなら誰でも「あるある」と頷いて頂ける話だと思います。ローカルで変更を行い、そこでは正常に動くのに、同じ変更をマージしてサーバーで実行すると問題が発生してしまうケースです。これを解決するための1番お勧めの方法は、テストのフレームワークに、継続的インテグレーション（CI）を実装することです。 The ✅ of clean code 最近のバージョン管理システムでは、実際に変更をマージする前に、変更に対してテストが実行されます。そこで是非皆さんに試してみて欲しいことがあります。もしもコードが別のコードをテストするだけのものである場合、もしくはテスト中のアプリケーション（AUT）に対してのみテストを実行する場合、ちょっと細かいですが、次の工夫を加えてみてはいかがでしょうか。 まずAUTの最も安定した部分を特定し、そこにCIテストの照準を当てます。そして、コードベースに何者かが変更をマージしようとした時に、CIテストを走らせます。テストがもし失敗したら、危険な変更のマージであるか、バグなどの理由でAUTが正常に動いていない、ということになります。どちらにしても、自動テストのエンジニアとしてはWIN-WINになります。  例：もしもAUTにログインページやホームページがある場合は、ページの読み込みをCIテストのターゲットに設定しましょう。 　　　　　　　　失敗もOK。ただ、いつも新しい失敗をするように！ PayPayでは、これらのチェックをしっかり行うことで、安眠を確保できるだけでなく、継続的テストフレームワークを全てのレベルで間違いなく実行することに繋がっています。レベルと言えば、エンドツーエンドのテストには複数のレベルがありますね。それについては、また来月ご紹介します。それまで、サヨナラ！