Merpay Tech Fest 2021は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知れるお祭りで、2021年7月26日（月）からの5日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。

この記事は、「リグレッションテストの自動化を段階的に実装した話」の書き起こしです。

高野純知氏：それでは「リグレッションテストの自動化を段階的に実装した話」という題目で、QAエンジニアの高野が発表させていただきます。本日はよろしくお願いいたします。

簡単に自己紹介をさせていただきます。新卒時には金融系システムのQAを担当していました。その後、ゲーム業界へ一度転職し、クライアント開発やバックエンドの開発を経験して、再度QAエンジニアとして2019年12月にメルペイにジョインさせていただきました。QA業務の中でも自動化まわりに興味が強いです。趣味はゲーム開発で、今はスマホ向けの簡単なゲームを作成したりしています。本日は、テストの自動化まわりの話をさせていただければと思いますのでよろしくお願いいたします。

前置きとして、担当するマイクロサービスにおけるQAチームの課題感から説明させていただきます。担当するマイクロサービスの概要は追って説明させていただきます。1つ目は、QA方法が難しいことが挙げられます。これはバックエンドに閉じたサービスであり、特に画面もなくツールを駆使してQAする必要があるため難しいと感じております。そのため、たびたび手戻りが発生したり、この機能はこの人しかQAできないなどの属人化する傾向がありました。2つ目は、仕様が複雑で、QA方法と相まってキャッチアップに時間がかかったり、単純な増員が難しかったりします。

それぞれの課題に対して、せめてQA方法は簡略化したいという思いのもと、手間のかかる手順はなるべく機械化するように取り組みました。機械化するにあたり、自分で対応できるところは簡単なスクリプトを作成したり、また、必要に応じて開発チームに協力を仰いだりしました。段階的に取り組みをしていくことで、最終的にコマンド1つでリグレッションができる状態になったという話を本日はさせていただきます。

取り組みを紹介する前に、私の担当するマイクロサービスについて簡単に説明させていただきます。機能としては、大きく2機能あります。1つ目は、お客様からの定額払い申し込みに対して、メルカリや指定信用情報機関であるCICから信用情報を取得して、取得した信用情報に基づきメルペイ側で定額払いの審査を実施するものとなります。

2つ目は、メルペイでの利用情報をCICに月一で登録する機能となります。今回の取り組みは、こちらのいわゆる月次登録についての取り組みを紹介させていただきます。

次に、月次登録の機能について時系列順に簡単に説明させていただきます。基本的に各機能はジョブとして実行されます。まず、メルペイ内の他のマイクロサービスから個人情報や利用情報などの情報を取得する機能が存在します。次に、取得した情報をベースにCICへ送るファイルを作成する機能が存在します。次に、CICへ実際に作成したファイルを送信する機能が存在します。

CICへの登録が実施されると、登録結果が数日後に返ってきます。登録結果もファイルで送信されるため、そのファイルを受信する機能が存在します。最後に、受信したファイルを解析して結果を反映する機能が存在します。これらの機能のQAを実際に行っております。

次に、QA方法について簡単に説明させていただきます。QAは、担当マイクロサービスの開発チームで作成した内製のQAツールを基本的に使用しています。内製のQAツールの初期バージョンは、テストデータの初期化、ジョブ実行ぐらいの機能でした。そのため、出力結果の確認はすべて目視確認をしておりました。例えばDBのデータや、CICへ送信するためのファイル、Google Cloud Storageへ出力されるファイル、CICに代わるスタブサーバーへ出力されるファイルなども目視確認する必要がありました。

ファイル作成の機能を例に具体的な操作をシーケンス図に表しますとこのようになります。

実行準備としてDockerイメージのタグ名を取得して、タグ名を添えて内製ツールを経由してジョブを実行し、出力されたファイルなどを目視確認しておりました。このQAエンジニアから出ている線が実際のQA作業となるのですが、結構な手数があることが図的に分かると思います。

ただ、今回の取り組みによってこの手順が、このようになりました。QAエンジニアから出ている線を見ていただければ一目瞭然で、コマンド1つでテスト結果を得られるような形になりました。ここから、こうなりました。

このように、コマンド1つで実行できるようにするために一気に取り組んだわけではないです。前置きでも触れましたが、手間のかかる手順を細かい単位で順次機械化していきました。必要に応じて、シェルスクリプトやPythonでスクリプトを組んだり、開発チームに協力を仰いで内製のQAツールの改修をお願いしたりもしていました。これらの具体的な取り組み内容を時系列順で簡単に一部紹介させていただければと思います。

取り組みの1つ目です。DBや作成したファイルの目視確認が一番つらかったので、こちらの例のようにアサート処理が書けるような内製のQAツールの改修依頼をさせていただきました。効果としましては、テスト結果の目視確認がなくなって機械的にチェックできるようになったという点で大きな効率化に繋がりました。

取り組みの2つ目です。Dockerイメージのタグ名をContainer Registryにブラウザで確認、コピペしていたのですが、ブラウザ操作がすごく不便でした。タグ名自体は、gcloudのコマンドを利用すれば一覧の取得からフィルタリングまではできたのですが、特定名の最新のタグ名を取得するために、gcloudのコマンドの結果をパースしてタグ名を取得するようなPythonのスクリプトを作成し、さらにシェルスクリプトでクリップボードにタグ名をコピーできるようにしました。これにより、ブラウザをアクセスせずに1コマンドで特定のタグ名を取得できるようになりました。

取り組みの3つ目です。Cloud Storageのファイルをチェックするのにブラウザで目視確認をしていたのですが、これも地味に面倒でした。Cloud Storageに対してgsutilツールを用いることで、Cloud Storageのファイル操作が可能でした。そのため、Pythonを用いてgsutilのコマンドを実行し、ファイルがダウンロードできるかどうかを見てファイル有無をチェックするような形で機械化を行いました。これにより、ブラウザでアクセスせずに1コマンドでファイルチェックが可能となりました。

取り組みの4つ目です。先ほどの取り組み3のCloud Storageのファイルチェックを行う処理を内製のQAツールに移植してもらうことにしました。これは、運用フェーズで開発チームに少し余裕が出たため対応してもらうことになりました。これにより、内製のQAツールの実行後に取り組み3のPythonスクリプトを別途実行していたのですが、内製のQAツールの実行の中で同じ処理が実行できるようになったので、別途、実行する手間がなくなりました。

取り組みの5つ目です。ほかにもいろいろなスクリプトを作成したのですが、今回は省略させていただきますが、それらのスクリプトや、これまでの取り組みで紹介させていただいた自作のスクリプト、内製のQAツールを順次実行するような簡単なシェルスクリプトを作成しました。これにより、1コマンドの機能単位のリグレッションテストが実行できるようになりました。

再掲となりますが、ファイル作成で表しますとこのような手順が、このようになりました。

次に何をしたかというのは、もう感づかれている方もいらっしゃると思いますが、機能単位で1コマンドが実行できるというのであればということで、すべての機能に対するリグレッションテストも1コマンドで実行できるようにしました。

こちらも再掲となりますが、月次登録で必要な処理である情報取得、ファイル作成、ファイル送信、ファイル受信、データ反映、すべての機能に対するリグレッションテストを実行するようにしました。

シーケンス図で表すとこのようになります。細かいところは省いているのですが、1コマンドでそれぞれの機能のテスト結果を得られるような形で実装してみました。

取り組みを並べてみるとこのようになります。1つ目は、内製ツールに対する機能拡張依頼。2つ目は、コンテナレジストリに対するタグ名取得スクリプトの作成。3つ目は、Cloud Storageに対するファイルチェックスクリプトの作成。4つ目は、内製ツールに対する機能拡張依頼。5つ目は、機能単位でのリフレッシュテストを1コマンドで実行するためのスクリプトを作成。最後に、全機能に対するリグレッションテストを1コマンドで実行するためのスクリプトを作成したというものになります。

自動化の効果としては、課題感としてあった手戻りもゼロとなり、属人化していた機能も誰でも実行が可能となって実行ハードルがとても低くなりました。また、実行時のコストも以前は大体270分かかっていたのが、約90分と3分の1になって、かつ、基本放置することで並列作業が可能な状態となりました。実際、このスライド作成中にも2回ほど並行して回したりしていました。

自動化といえば、保守性も気になるかと思います。結果論になってしまいますが、結論としてはほぼメンテナンスもなく、自動化の仕組みをつくったコストを考えると、既に十分すぎるほどの元が取れています。なぜかということを考えたとき、細かい単位でスクリプト化しているのでフローが少し変わることでそこまで影響がないというところと、そもそも機能的な観点でフローも変わりづらいという点があるからかなと考えております。また、スクリプトの単位が小さいのでキャッチアップのときも容易に読み解くことが可能となっています。そして、何かしらの原因でスクリプトが動かなくなったとしても、基本的にはマニュアルで実行していたものをスクリプト化しているだけなので、一部マニュアルに切り替えることでQAが止まることはないです。実際に動かなくなるということはほぼありませんでした。

おわりに、今回は少しずつQA作業を機械化することで、最終的に全自動でリグレッションができたという内容を紹介させていただきました。自動化することでQAコストを大幅に下げ、実行に対する属人化が解消できました。また、これは触れませんでしたが、今回取り組んだ自動化が次のプロジェクトでも活用できる状況にあります。ここまで自動化ができましたが、まだまだリモートでの実行やSlack経由での実行、内製のQAツールの改修にQAエンジニアが介入するなど、やりたいことはたくさんあります。なので、今後もGo Boldにいろいろ挑戦していきたい思いでいます。

以上となります。ご清聴いただきありがとうございました。