こちらは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では本番環境よりも前の段階（ステージングやサンドボックス環境）でバグを見つけることができています。また同時に、本番環境においてモニタリングシステムの強化にもつながっています。では、次のテストレベルに関しては、来月のブログでお話しすることにしましょう。