June 2020

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