Merpay Tech Fest 2022 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りで、2022年8月23日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
この記事は、「QA自動化チームの立ち上げとテスト自動化の現状」の書き起こしです。
それでは、「QA自動化チームの立ち上げとテスト自動化の現状」というタイトルで、QAエンジニアの高野が発表させていただきます。よろしくお願いいたします。
簡単に自己紹介させていただきます。
新卒時には金融系システムのQAを担当していました。その後ゲーム業界へ転職し、クライアント開発でUnityやCocos2d、バックエンド開発でPerlやRubyの開発を経験。2019年12月に再度QAエンジニアとしてメルペイにジョインさせていただきました。
QA業務の中でも自動化周りに興味が強いです。趣味はアプリ開発。自分が英語が苦手なこともあり、英語が苦手な人向けの英語学習アプリを作成しています。本日は、テストの自動化周りの話をさせていただきます。よろしくお願いいたします。
本日はQAチームの課題に始まり、自動化チームをどう発足していったか、またどのようにアクションを取っていったかについて紹介させていただきます。その中でも、特にメルペイにおけるテスト自動化の現状に興味を持っている方がいらっしゃると思いますので、そこも厚めに紹介できたらと考えております。
課題
それでは「課題」から説明させていただきます。
全社的に、今でも新規でリリースしたい機能・サービス、または改修案件が多くあり、それぞれの案件をできれば早めに出したい、といった状況です。そんな状況下で、QA組織的にはQAエンジニアが不足気味という課題感があります。
実情としまして、1人のQAエンジニアが複数のプロジェクトを兼任していたり、特定のプロジェクトは丸々協力会社の方々にご協力いただいていたりと、メルペイQAチームだけでは担当できる許容量を超えている状況です。
そのため、テストを一部自動化することで、少しでも人不足に対して緩和しつつスピーディーにリリースをしたい。しかし、テストの自動化をしている時間すら確保できないといった課題感がありました。
自動化チームの発足について
次に「自動化チームの発足について」紹介させていただきます。
自動化を進めたい状況がQAチーム内である中、自分の担当していたチームは開発エンジニアさんのご協力も多々あり、比較的スムーズに進んでいる状況でした。こちらに過去の記事にもありますので、よろしければご参照ください。
- QA Engineer1年生の1年間で取り組んだことの紹介
- リグレッションテストの自動化を段階的に実装した話
- QA Engineer2年生がQA的技術的負債と立ち向かった話
内容的にはAPIの自動テストとジョブの自動テストについて紹介させていただいております。
このように自動化を進めていくことで、担当のマイクロサービスのリリース速度が安定していたことや、個人的なWILLが自動化周りにあったことから、チームを横断して動いてみたいと考えておりました。
QAチームと自分の状況を合わせて当時のマネージャーに相談したところ、快くOKをいただきました。
そこから、どのように自動化チームを作ってどのように動こうかを具体的に考え始めることにしました。
具体的なアクションを起こす前に、まずは理想の状態を考えてみました。
既存案件に関しては、リグレッションテストは自動テストを実行するだけ。新規案件、改修案件に関しては、テスト計画の段階で、テストの自動化戦略が決定している状態、またリリースまでに自動テストが回せる状態になっている。それが理想的な状態だろうと考えました。
これらの理想状態に行き着くため、自動化チームとしてのミッションは、まずは自動化の基盤を整えること、また、各QAチームが自動テストをかけてメンテできる状態に持っていくことと定めました。
しかし、そこで問題が発生…。
いざ自動化を推進しようとしたとき、どのチームがどれだけテストの自動化ができているのか、また、そもそもサポートすべき対象のサービスはどれだけあるのか、わからないことだらけでした。さらに、そういった内容をQAチーム内でヒアリングしたところ、全体を把握しているQAメンバーは誰もいませんでした。
これではどのサービスを、いつまでに、どこまでサポートするのか計画すら立てられません。そのため、まずは状況整理をしようと考えました。
初手の動きとしては、まずは現状整理・現状整理をした後、サポート対象のチームを選定。そして、自動テストのサポートをしていこうと考えました。
アクション
次に、具体的な「アクション」を紹介していきたいと思います。まずは現状整理をどのようにしたかと、結果どうだったかを紹介させていただきます。
現状整理のヒアリングのポイントです。まずはそもそも対象のマイクロサービスが全然わからなかったため、対象のマイクロサービスを全て洗い出すことから始めました。
また、テスト対象の単位でバックエンド、フロントエンド、アプリのカテゴリ別に整理を行いました。他には現状の自動化状況、テストに利用しているツール、また今後そもそも自動化をしていきたいのか、などを中心にヒアリングを行いました。
これらの結果は去年時点のもののため、少し古いです。その点はご了承願います。
ここでテスト対象に関する補足情報です。バックエンド、フロントエンド、アプリとカテゴリ分けしているのには理由があります。これはバックエンドがほぼイコール（＝）マイクロサービスとなっており、メルペイではマイクロサービス単位で品質保証を行っているチームが多いためです。
理由は、フロントエンド、アプリとの結合前に見つかるべき不具合を発見するため、また、マイクロサービス間の結合で見つかるべき不具合を発見するため。マイクロサービスごとに品質保証ができるのであれば、マイクロサービス単位でリリースも可能であるからです。そのため、バックエンド、フロントエンド、アプリとで品質保証のスコープをカテゴリ分けしております。
この考え方は、一般的に知られているテストピラミッドと考え方が近いかと思います。テストピラミッドをご存知の方であれば、UIテストの前の段階で品質保証を一部実施しているようなイメージとなります。
現状整理の話に戻らせていただきます。対象のサービスを洗い出した結果がスライドの通りです。単位がQAチーム単位となり直感的ではないかもしれませんが、バックエンドに関しては、＝マイクロサービス数となり、フロントエンドに関しては、加盟店などに関するWebベースのサービス、そしてアプリに関しては、アプリから利用するマイクロサービス数となりました。メルペイでは圧倒的にマイクロサービスが多く、QAの対象もバックエンドが比較的多いです。
自動化状況の結果はこのようになりました。バックエンドはマニュアルで実施しているサービスが35.4%、できる範囲で自動化が完了しているサービスは30.8%。自動化不要としているサービスが26.2%。一部自動化ができているが、まだ自動化できる部分があるサービスが7.7%となりました。
フロントエンドに関しては、自動化できているサービスが72.7%、マニュアルが18.2%、自動化不要としているところが9.1%となりました。
アプリに関しては、マニュアルが42.9%、自動化不要としているところが42.9%、一部自動化できているところが14.3%となりました。
これらの結果から見えた傾向といたしましては、自動化済みであるサービスの割合はフロントエンドが一番高く、次にバックエンド、アプリと続きました。
補足情報として「自動化不要」となったものの理由を紹介します。規模が小さく、自動化するメリットが少ないことや、QAがそもそも関与していない社内サービスなどがあること、そもそも現在稼働してない役割を終えたサービス、そしてNFCなど実機を使わないと確認できないサービスが自動化不要としてカウントされていました。
次に、利用ツールに関してです。スライドのような結果になりました。バックエンドはPostmanが過半数を占め51.2%、次にメルペイArchitectチームが提供している内製ツールscenarigoが39%。残りはマイクロサービスで実装している内製ツールが9.8%となりました。
フロントエンドに関してはほぼCypressで9割を占めていて、一部内製ツールを利用しているという状況でした。
アプリに関しては、OSでは利用率それぞれ100%なのですが、iOSはXCUI、AndroidはEspressoをそれぞれ利用しているといった状況でした。
scenarigoについては下記をご参照ください。
- https://github.com/zoncoen/scenarigo
- Scenario-Based Integration Testing Platform for Microservices – 森 健太【Merpay Tech Fest 2021】
バックエンドをもう少し噛み砕いていくと、バックエンドは大きくAPIのテストとジョブのテストでカテゴリが分けられたりするので、API、ジョブ別でもそれぞれグラフ化していきます。自動化状況の結果に関しては、APIはマニュアルが34.4%、自動化済みのサービスは29.5%、自動化不要としているサービスは27.9%、一部自動化済みのものは8.2%となりました。
ジョブはマニュアル50%、自動化済みが25%、一部自動化が25%と傾向が別れました。APIテストよりもジョブのテストの方がマニュアル実行の割合が多いことから、ジョブのテストの方が自動化の難易度が高い傾向が見受けられます。
利用ツールも同様に見ていくと、APIはPostmanが61.8%、scenarigoが38.2%。ジョブはマイクロサービスごとのオリジナル内製ツールが66.7%、scenarigoが33.3%。APIはPostman、ジョブは内製ツールが過半数を超え、一部をそれぞれscenarigoを利用しており、こちらも傾向が分かれました。
バックエンドの内製ツールがどういったものかというと、ジョブを単発で実行するものが多くありました。そのため基本的に結果の確認は、DBのテーブルを目視確認しているチームが多かったです。
ジョブのテストで内製ツールを絡めた自動化を行えているケースは珍しいと言えます。しかしゼロではなく、ジョブの実行、期待値のチェックまで実施するケースもあります。過去の記事で紹介していますので、ご興味ありましたら参照いただけると嬉しいです。
- バッチ処理のリグレッションテスト自動化のトライ
- 【書き起こし】リグレッションテストの自動化を段階的に実装した話
また利用ツールに関して、バックエンドのマニュアルテストをしているサービスに対してのみ集計したところ、面白い傾向が見られました。Postmanの利用率が92.9%、内製ツールが7.1%と、圧倒的にPostman利用率が高かったのです。
これはPostmanが利用しやすいという点から、スピード感をもって対応する際にPostmanが採用されやすく、このような結果になっているのではないかと推測します。
scenarigoがマニュアルテストで使われていない状況に関しては、おそらくscenarigoがテストシナリオを実施するためのツールという性質上自動化をする前提で使われているため、マニュアルテストでは使われていないのではないかと考えております。
テスト自動化の傾向のまとめです。まずはバックエンドについて。APIテストはPostmanかscenarigoを利用しているケースがほとんどでした。また、APIテストのマニュアル実行ではPostman用いられるケースがほとんどでした。
ジョブのテストについては、マイクロサービスごとの内製ツールかscenarigoを利用していました。また整理していくうえでわかったことですが、開発エンジニア側でもIntegration testまで実施していますが、そのテストではGo言語で作られているe2eテストのフレームワークを用いているということです。その後のAPIテストからはQAチームが実施していますが、そのテスト以降は異なるツールを用いています。開発エンジニアが利用しているe2eテストフレームワークについては、こちらの記事で紹介されているので、こちらもご興味ありましたらご参照ください。
- マイクロサービスの開発とテストファースト／テスト駆動開発 【Mercari Gears Lecture Series】
次にフロントエンドの傾向についてです。フロントエンドは基本的にCypressを利用しています。セットアップが簡単なことや、テストコードが書きやすい、公式ドキュメントが充実している、多くの人に利用されているOSSであるなど…他のテストツールと比較して、様々な理由でメルペイでやりたいことの要件をより満たしている、という理由で採用されています。
Cypressでの自動化が難しい部分に関しては、マニュアルでテストを実施しています。また、バックエンドと少し異なるところとして、フロントエンド側はIntegration testのフェーズでQAフェーズでも利用しているCypressを利用している点があげられます。フロントエンドチームのテスト自動化の方針の詳しい内容については、こちらの記事で紹介されているので興味がありましたらご参照ください。
- メルペイフロントエンドのテスト自動化方針
次に、アプリの傾向についてです。アプリ側もツールははっきりしていて、iOSはXCUI、AndroidはEspressoを利用しております。理由としましては、メルカリ側では開発エンジニア側でテストを書いていこうという流れがあります。そのため、開発エンジニア主体で使いやすいツールを選定し、それにならってメルペイ側も使用しているからです。以前はappiumベースでQA管理で自動化をしていた時期もあったのですが、管理コストが高かったなどの問題があったのでやり方を変えたとお聞きしております。
最後に全体的な傾向についてです。これはフロントエンドチームの自動化が一番進んでいることから、開発・QAエンジニアが共に近い環境でテストコードが書けると自動化が進む傾向があるのではないかと考えました。
改めて羅列するとスライドのようになります。フロントエンドは開発・QAエンジニア共々Cypress、バックエンドは開発エンジニアはGo言語、QAエンジニアがPostmanかscenarigo、アプリは開発エンジニアのみXCUI・Espressoでした。
これまでの自動化の傾向から、どのように自動化を進めるとより価値の高い自動化になるかを考え、自動化チームとしての自動化ポリシーを定めることにしました。
内容としましては、基本的にツールを一つに絞るということ。ツールの選定の要素として、開発エンジニアでもテストを書ける状態にするため、開発エンジニアが利用しやすいものを考慮するということ。また、開発・QAエンジニアが誰でも書けることを目指し、テストコードは保守性・可読性を重視してシンプルに書くようにするということです。
シンプルという言葉の捉え方によって変わりそうですね。一つの要素として、「振る舞いをベースに記載する」という考えを持っています。
Autify社の末村さんの記事になりますが、「E2Eテストに求められることは、振る舞いが変わっていないことで、振る舞いの仕様変更は対テストで検知されるべきもので、振る舞いこそ正義（参照：Auyify Blog）」と紹介されております。これにとても共感し、振る舞いという単位が人によって把握しやすく、可読性を自然に上げるものと考えております。
具体的な例を挙げていきます。まずはバックエンドの場合、ユーザーを作成する、スマート払いで商品を購入する、月次ジョブを実行し清算可能状態にする、清算する、清算が正常に完了したかをチェックする…のように、テストコードのワンステップをそれぞれ意味のある振る舞い単位にすることで、わかりやすいものとなると思います。
フロントエンドの例です。一般的なWebサービスを思い浮かべていただきたいのですが、アドレスを入力する、パスワードを入力する、ログインボタンを押す、サービスのトップ画面に遷移することを確認するなど、操作単位になるようなイメージです。
自動化ポリシーの話に戻ります。次は、利用ツールに関する具体的なポリシーです。バックエンドに関してはGo言語でプラグインも記述できるということもあり、シナリオ自体もYAMLで書けたり、シナリオの一部を振る舞い単位にまとめる機能もあったりするため、基本的にはscenarigoを用いる方針としました。
scenarigoではバッチの実行の仕方は違えど、実行自体はできるのでバックエンド全体でツールを統一するようなポリシーに。ただ、内製ツール拡張の方が総合的にコストが安く済みそうな場合は、内製ツールを用いるポリシーとしました。
フロントエンドとアプリは基本的に現状を踏襲する形としました。
自動化の傾向が見えポリシーも定めたところで、次に対応のポリシーを考えます。
考えた結果、自動化で良くなりそうなことはバックエンドのチームが多かったため、ひとまずバックエンドのチームにサポート対象を絞ることにしました。
また、数あるチームの中でも自動化の基盤が整っていないサービス、また、リグレッションテストが定期的に発生しているけれど自動化ができていないサービスを優先的にサポートすることに。ツールの使い方はどのチームも需要があったことと、運用時にも利用する必要があることがあることから、理解を深めるために並行して勉強会を開くことにしました。
結果、自動化チームの動きとしてはスライドのように方向修正することになったのです。赤字が更新部分です。基盤作成と勉強会を実施するという具体的なアクションを追加しました。
次に、自動化基盤の作成について何をしたか紹介させていただきます。
基本的にscenarigoを利用するポリシーにしたので、scenarigoのsetup対応を請け負いました。他にも、テストのオペレーションの中で内製ツール等の実行が含まれる場合は、使い方をヒアリングし、処理をscenarigoで実行できるようにpluginで実装し提供もしました。
次に、自動テストの作成について簡単に紹介させていただきます。
ここはとてもシンプルです。定めたポリシーに沿って実際に自動テストを作成し、作成した内容をベースに勉強会でもシェア。QAチーム全体でツールの理解を深められるように働きかけました。他にも、相談ベースでどう実装するかなどをアドバイスさせていただきました。
ただ、自動化チームとは1人チームだったので、対応量に限界を感じるように。
より優先度の高いプロジェクトにフォーカスし、サポートすることにしました。また、開発エンジニアの方にお任せできるところはお任せする形で、プロダクトチームとして自動化が進められるようにサポートを行いました。
アクションとしては以上となります。
自動化チームの成果と今後の課題
ここで「自動化チームの成果と今後の課題」について紹介させていただきます。
まず成果については、テスト自動化の状況を可視化できたという点。自動化の基盤を整え、自動化できる状況を提供できたという点。その結果複数のチームで、自動化の一歩目を踏み出すことができたという点。また自動化ポリシーを定めたことで、自動化をどうしていけばいいか方向性を出すことができました。
課題としましては、ケースの追加とメンテナンスがまだまだ難しそう、という点が挙げられます。こちらは根気強く対応していく必要があると考えております。また、アプリに関しての自動化が未だにノータッチのため、どこかのタイミングでQAエンジニアも介入できるようになりたいなと考えております。
また、直接的な成果ではないのですが、今回定めた自動化のポリシーが他の新規プロジェクトでも生きたケースがありました。方向性としては間違ってないと感じております。
おわりに
おわりに、対応したことをまとめます。
まずはテストの自動化を推進するチームを作ってみました。活動としましては、テスト自動化の現状整理、自動化基盤の構築サポート、テストコードの作成サポート、ツールの勉強会を実施。
現状を整理した結果、バックエンドの自動化が進むと嬉しい状況、ということがわかったので、バックエンドのチームを中心に自動化推進の活動を行いました。
また、利用ツールの傾向として、バックエンドはscenarigo・Postman・内製ツール、フロントエンドはCypress、アプリはXCUI・Espressoを利用しているところが主でした。
また、自動化ポリシーも定めました。振り返ると、ツールは多用せず基本的に一つを利用するバックエンドはscenarigo、フロントエンドはCypress、アプリはXCUI・Espressoとしました。あとはテストコードは誰でもわかるくらいシンプルに振る舞いベースで書くことということを定めました。
さいごに、自動化を推進していくうえで改めてチームで全員品質を意識して行動する大事さを感じました。裏を返すと、1人でできることの限界も感じました。そのため一緒にテストの自動化周りをよりブーストしていける仲間をいつでも募集中なので、テストの自動化周りにご興味ある方はぜひともお声がけください！
発表としては以上となります。ご清聴いただきありがとうございました。
