メルペイのテスト自動化にQAエンジニア1人で立ち向かった記録【Merpay Tech Fest 2022イベントレポート】

2022年8月23日～8月25日に開催した技術カンファレンス「Merpay Tech Fest 2022」では、メルペイQAチームの高野純知氏から、よりスピーディーなサービス提供とQAエンジニアの人材不足を背景に、チーム横断で動くテスト自動化チームを1人で立ち上げた苦楽が語られた。メルペイのテスト自動化には、どのような課題があったのか？そして、その課題をどのようにして解決していったのだろうか？

• keyboard_arrow_down 現状打開：テスト自動化を考える時間すらなかった……
• keyboard_arrow_down 現状整理①：バックエンド・フロントエンド・アプリに切り分け
• keyboard_arrow_down 現状整理②：利用ツールから自動化の難易度を分析
• keyboard_arrow_down 自動化ポリシーの策定：「シンプル」なテストを目指して
• keyboard_arrow_down 対応ポリシーの策定：バックエンドのテスト自動化に注力
• keyboard_arrow_down テスト自動化の成果

メルペイは、新規開発や既存機能の改修など、日々スピーディーにリリースしたい機能がたくさんある。ところが、1人のQAエンジニアが複数のプロジェクトを兼任したり、サービスによっては協力会社に品質保証を一任していたりと、QAチームの人的リソースが枯渇している状況にあった。テストの自動化によって人手不足を解消したいが、そもそも自動化に取り組むための時間すら確保できない状況だった。

そんな中で、高野氏が担当しているサービスでは、プロダクトの開発エンジニアの協力もあり、テストの自動化が進んでいる状態だった。その結果として、担当しているマイクロサービスのリリース速度が安定しているという実感もあった。

高野氏は、当時自分の興味がテスト自動化に向いていたこともあり、上司に「チーム横断で動けるテスト自動化の一人チームをつくっても良いか？」と提案したという。その提案は快諾され、早速、テスト自動化のために施策案を考えることとなった。

具体的なアクションを起こす前に、まずはテスト自動化によって得たい「理想の状態」を考えることにした高野氏。その結果として得られた「理想の状態」は以下のようなものだ。

• ・既存案件については、リグレッションテストを実行するだけになっている
• ・新規案件については、テスト計画の段階で自動化戦略が決定しており、かつリリースまでに自動テストが回せる状態になっている

理想の状態を定義したところで、自動化のための基盤づくりに着手しようとした高野氏だが、そこにもう一つの壁が立ちはだかる。メルペイ内のプロダクトでテスト自動化がどの程度行われているのか、そもそも自動化対象のサービスはどれだけあるのか、何も分かっていなかったのだ。これは高野氏だけが抱えている問題ではなく、QAチーム全体で見ても、自動化の現状を把握しているメンバーは誰もいなかった。

高野氏はネクストアクションを定めるため、テスト自動化の現状を整理するところからプロジェクトをスタートした。

まずはテスト対象のマイクロサービスをすべて洗い出し、バックエンド・フロントエンド・アプリの3種類にカテゴリー分けした。これは、メルペイではバックエンド≒マイクロサービスとなっており、メルペイではマイクロサービス単位で品質保証を行っているチームが多いことが理由だ。マイクロサービス単位で品質保証することで、フロントエンド・アプリと結合する前に不具合を発見できたり、マイクロサービス単位でリリースできたりすることが可能になる。この考え方は「テストピラミッド」とも考え方が近いものであり、テストピラミッドにおけるUI テストの前の段階で、品質保証を一部実施しているようなイメージだと補足している。

対象となるサービス数を洗い出してみると、バックエンドが50個以上、フロントエンドとアプリはそれぞれ10個前後と5個前後で、圧倒的にバックエンドの数が多いことが分かった。

そして、ヒアリングで得た各カテゴリーの自動化状況は以下の通り。自動化できている割合でいうと、フロントエンドが最も高く、続いてバックエンド、アプリとなっている。

一部サービスに関して自動化不要となっているのは、規模が小さく自動化するメリットが少なかったり、すでに現在稼働していないサービスだったりであるからだ。

次に、各カテゴリーの自動化ポリシーを策定するため、現在テストに使用しているツールについても細かく分析されている。

・バックエンドについて

対象サービスが最も多いバックエンドに関しては、大きくAPIとジョブに分けて分析を行った。その結果、APIはマニュアルテストを行っている割合が34.4%であったのに対し、ジョブの場合は50.0%となっていた。そのため、APIのテスト自動化よりもジョブのテスト自動化のほうが難易度は高そう、と判断したという。

利用ツールに関して、メルペイアーキテクトチームが提供している内製ツールscenarigoの利用率が30%台であるというのはAPI/ジョブで共通していたが、その他のツールに関しては、APIではPostmanが、ジョブでは内製ツールが使われていた。この内製ツールというのは、ジョブを単発で実行するものが多く、結果を確認するためにDBを目視確認することが求められるものだ。

また、開発エンジニア側もインテグレーション・テストまで実施しており、そのテストでは GO 言語で作られている e2eテストのフレームワークを用いているという。

・フロントエンドについて

自動化できている割合が一番高いのは、フロントエンドであった。フロントエンドでは、テストツールとしてCypressを使っているプロダクトが多い。これには、以下のような理由があるという。

• ・セットアップが簡単
• ・テストコードが書きやすい
• ・公式ドキュメントが充実している
• ・多くの人が利用しているOSSである

Cypressで自動化が難しい部分はマニュアルテストが実行されている。また、開発エンジニアもインテグレーション・テストのフェーズでCypressを利用していることがわかった。QAエンジニア・開発エンジニアがお互いに近い環境でテストコードを書けるようになると、自動化が進む傾向にありそうだ。

参考：​メルペイフロントエンドのテスト自動化方針

・アプリについて

アプリは、iOSにおいてはXCUIが、AndroidにおいてはEspressoがそれぞれ100%採用されている。ここには、メルペイの親会社であるメルカリでのアプリ開発の歴史も関わっている。

メルカリでは、開発側でテストコードを書いていこうという流れがあった。そのため、開発エンジニア主体でテストが書きやすいツールが選定されている。メルペイでもそれにならい、現在の使用ツールを決定した経緯があるという。現状として、アプリのテストコードは開発エンジニアのみが書いている状況で、QAエンジニアはほぼ関わっていない。

現状の分析を踏まえて、どのように自動化を進めるとより価値の高い自動化になるかを考え「自動化ポリシー」の策定が行われた。

まず、ツールは基本的に一つに絞ることが定められ、そのツール選定の際には、開発エンジニアもテストを実行できるように、利用しやすいものをなるべく選ぶようにすることが決まった。

テストコードについては、「シンプル」に書いて保守性・可読性を重視することが定められた。「シンプル」をどう定義するかは各人によって議論が分かれそうではあるが、ここでは「振る舞い」という単位をベースにすることとしている。

具体的な例として、バックエンドのテストコードにおいては、「ユーザーを作成」「メルペイスマート払いで商品を購入」など、それぞれ意味のある「振る舞い」の単位でテストが行われる。フロントエンドの場合、「アドレスを入力する」「パスワードを入力する」「ログインボタンを押す」など、ユーザーの操作単位ベースに記載するイメージだ。

ツール選定について、フロントエンドではCypressを、アプリではXCUIとEspressoを引き続き利用することとなった。しかし、バックエンドについては使用ツールが複数あるため、基本的にはscenarigoに統一していくことがポリシーで定められた。

scenarigoを利用することになった理由として、以下の要素が挙げられている。

• ・Go言語でプラグインを記述できる
• ・シナリオをYAMLで記述できる
• ・シナリオの一部を振る舞い単位でまとめられる

一方で、内製ツール拡張を用いたほうが、総合的に低コストで実行できる場面もある。その際は、内製ツールの利用を妨げないポリシーとなっている。

自動化ポリシーに引き続き、「対応ポリシー」が策定された。

まずは、施策のインパクトがもっとも大きいバックエンドに対象を絞ることにした。その中でも、自動化の基盤が整っていないサービス、リグレッションテストが定期的に発生していて自動化ができていないサービスについて優先的に対応を行うこととした。

また、ツールの使い方に対する理解を深める需要はどのチームにもあったため、個別サポートと並行して勉強会も開催することになった。

個別サポートの内容として、まずは自動化の基盤作成を行うことに。具体的な作業としては、scenarigoのセットアップ作業を請け負うこととなる。また、テストに内製ツールでの実行が含まれる場合は、scenarigoのプラグインを用いて実装し、scenarigoで自動化が完結するような調整も行っていった。

その後、事前に定めたポリシーに沿って、実際に自動テストを作成したり、作成した内容をベースに勉強会を開催したり、相談いただいた内容をもとに自動化テストの作成サポートを行ったりしたという。しかし、やはり1人では対応できることに限界がある。そこで、より優先度の高いプロジェクトにフォーカスしたり、QAはケースのみを考え、テストコードの実装は開発エンジニアに任せたりするなどの手段を取っているという。

テスト自動化プロジェクトを実施したことで、いくつか成果が見えてきた。

まず、事前準備としてテスト自動化状況を可視化できたことが、重要な成果の一つだ。その上で、テスト自動化の基盤づくりを行い、複数のチームでテスト自動化のための第一歩を踏み出せている。

一方で課題も山積しているという。テスト自動化を行ったのは良いものの、テストケースを追加したり、継続的にメンテナンスを行ったりといったことがなかなか難しい。また、バックエンドやフロントエンドについてはある程度の改善を行えたものの、アプリのテスト自動化改善にはまだ全く手を付けられていない。

1人チームで膨大なプロダクトのテスト自動化を推進するのはあまりに困難だ。「テスト自動化を推進してくれる仲間を募集しているので、気になる方はご連絡ください」というメッセージで発表は締めくくられた。

関連リンク

・QA Engineer1年生の1年間で取り組んだことの紹介
・【書き起こし】リグレッションテストの自動化を段階的に実装した話 – 高野 純知【Merpay Tech Fest 2021】
・QA Engineer2年生がQA的技術的負債と立ち向かった話

文：伊藤祥太