はじめまして。メルペイ、メルコインの QA Engineer の takama です。
私は QA チームの中で、テスト自動化を推進する役割を持っています。
今までもメルペイにおいて、マイクロサービスに対する段階的なテスト自動化の導入や、チーム横断でテスト自動化の状況を整理、必要に応じてテスト自動化をサポートしてきました。
今までの取り組みについての記事もありますので、こちらも読んでみてください。
- QA Engineer1 年生の 1 年間で取り組んだことの紹介
- 【書き起こし】リグレッションテストの自動化を段階的に実装した話 – 高野 純知【Merpay Tech Fest 2021】
- QA Engineer2 年生が QA 的技術的負債と立ち向かった話
- 【書き起こし】QA 自動化チームの立ち上げとテスト自動化の現状 – Masatomo Takano【Merpay Tech Fest 2022】
そんな中、メルコインという新しいプロジェクトが発足し、自分もテスト自動化絡みで関わらせていただくことになりました。
メルペイとは似ているけど異なる点も多々あり、大変ではありましたが面白いプロジェクトでした。
本記事では、メルペイで発生した課題を、メルコインで発生させないために、どのように活かし、どのような結果になったかについて紹介します。
前置き
- 本記事で紹介するテスト自動化の範囲は、バックエンド（マイクロサービスの QA）となります。
- メルペイ、メルコインでは、バックエンドの API テストには、メルペイアーキテクトチームの zoncoen さんが開発したscenarigoを用いています。
- scenarigo でできることを簡単に列挙すると、以下の通りです。
- WebAPI のテストが YAML で書ける。
- 動的な処理（ランダム ID の生成など）を Golang でプラグインとして開発、シナリオ（テストコード）から呼び出すことができる。
メルペイにおけるテスト自動化
メルペイにおいて、テストのスコープは、バックエンド（マイクロサービスごと、マイクロサービス間の結合など）、Web フロント、アプリと大きく 3 つに分かれています。
テスト自動化の状況については、以下で詳しく紹介させていただきましたので、興味ありましたら読んでみてください。
テスト自動化は、チームによって状況は様々で、自動化が進んでいるチームもいれば、自動化を進めることが困難なチームもいます。
以降で、テスト自動化を進めることが難しい理由について、紹介していきます。
メルペイにおけるテスト自動化の課題
メルペイではテスト自動化を進める上で、大きく以下の 3 点の課題が挙げられます。
- スキル観点
- スケジュール観点
- 仕組みの観点
それぞれについて、以降で少し詳しく説明していきます。
課題 1. スキル観点
scenarigo で API テストをする上で、課題として一定以上のキャッチアップコストが必要という点が上げられます。
理由としては、以下のような傾向が見られます。
- YAML とはいえ、プログラミング知識を若干要する
- プログラミング知識を持っていないと、効率的なテストコードが書けない
- GUI がないため、CUI に不慣れだと、難しく感じる
- scenarigo の経験者がいない
1〜3 に関しては、プログラミング経験があると、そこまでハードルが高く感じないのですが、プログラミングに触れてこなかったメンバーにとってはハードルが高くなるケースもありました。
また、4 に関しては、scenarigo が OSS として開発されているとはいえ、QA として、scenarigo を利用した経験がある方はほぼメルカリグループ外ではほぼ見かけないという実情があります。
課題 2. スケジュール観点
スケジュールの面では、自動テストを考慮したスケジュールを立てるのが難しいという点が上げられます。
スキル観点での課題とつながる部分でもありますが、scenarigo を使ったことがない QA メンバーだと、計画時点で自動化に対しての工数が算出できないケースもあります。
その場合、まずはマニュアルテストをやるという方向になりがちで、結果、自動化はリリース後に追っての対応（もしくはそのまま対応できない状態）となり、リリース直後の障害対応等にリグレッションテストが回せず、QA コストが嵩むケースもあります。
課題 3. 仕組みの観点
scenarigo を使ったテスト自動化を実現する場合、デバッグ機能（デバッグAPI）の実装など、テストコードを書く以外にも工数が発生するというケースがあります。
以下のようなシンプルなケースで具体的に説明します。
- API リクエスト
- ジョブを実行
- DB(Spanner) のデータを目視確認
API リクエストは標準機能の範囲で実現できるので特に考えることはないです。
ジョブの実行について、 scenarigo 経由で実行するには以下の 2 パターンが存在します。
- ジョブを実行するためのコマンドを、プラグインで実装
- ジョブと同等の処理ができるデバッグ API を実装
DB の確認について、 scenarigo 経由で実行するには以下の 2 パターンが存在します。
- scenarigo のプラグインで、DB のデータをチェックする処理を実装
- DB からデータを取得することができるデバッグ API を実装
上述の通り、全てのステップを scenarigo で実行できるようになれば、あとはつなげるだけで自動テストが実現できます。
ここでポイントとなってくるのは、API リクエスト以外のことがテストのステップとして存在すると、プラグインを Golang で実装するか、デバッグ API を実装、もしくは実装依頼する必要性が出てくることです。
課題まとめ
長文になってしまいましたが、それぞれをすごくシンプルにまとめると以下の通りとなります。
課題 1. 一定以上のキャッチアップコストが必要
課題 2. 自動テストを考慮したスケジュールを立てるのが難しい
課題 3. デバッグ機能（デバッグ API）の実装など、テストコードを書く以外にも工数が発生する
これらの課題を踏まえ、メルコインでのテスト自動化をどのように整備していったのかを以降で紹介してきます。
メルコインにおけるテスト自動化
前述しましたが、Web フロント、App の自動化については本記事では触れません。
メルコインでは、バックエンドの自動テストの一先ずのゴールをリリースまでに自動テストが活用できる状態を目指すということとし、アクションを取ることにしました。
このゴールを達成するためには、メルペイで挙げた課題をそれぞれ解決しないといけないため、それぞれに対し、以下のようにアクションを取っていきました。
課題 1 に対するアクション
一定以上のキャッチアップコストが必要という課題に対しては、自分のナレッジをどのように伝えていくかが重要と考え、以下のようなアクションを取りました。
- 計画の早い段階でレクチャー会の実施
- 気軽に質問できるようにデイリーの朝会に参加
- エラー対応一覧表の作成と運用
- コーディングポリシーの作成
計画の早い段階でレクチャー会の実施
キャッチアップハードルの高さを低減するために、QA としてまだ比較的余裕のあるプロジェクトの早い時期に、利用ツールの説明や、具体的なイメージをつけるために、メルペイでの利用例の紹介などのレクチャー会を実施しました。
レクチャー会では、より理解するために以下のような点を工夫してみました。
APIテストをする意図を説明して、目的意識を高める（自動化が目標じゃない）- scenarigo というツールで
どういうことができるか？の理解を深める - メルペイでの利用例を紹介し、テストコードの
具体的なイメージをつける
結果、実際にテストコードを書いて実行できるようになるまでが、とてもスムーズに対応することができました。
気軽に質問できるようにデイリーの朝会に参加
毎朝自分が朝会に参加することで、API テストに絡む疑問点等を解消することに努めました。
ツールの不明点などがあった場合、知っている人に聞くのが近道な場合が大いにありますが、弊社は基本的にフルリモートワークのため、質問しにくいと言った点も様々なキャッチアップ時に阻害要因となり得ると考えたためです。
結果、多くの質問を解決することができました。
エラー対応一覧表の作成と運用
scenarigo に関する実行時などのエラーと、エラー原因、対応方法を一覧表に整理することにしました。
項目としては、以下の通りです。
- 発生トリガー
- エラー内容
- エラー原因
- 対応方法
- 参考 link
これを作ることで、誰かが困ったことに対し、他の誰かが同じ困ったことが発生しても、一覧表を見れば解決に繋がり、私も質問者もお互いが幸せになると考えたためです。
運用としては、以下のようにしました。
- 解決できないエラーが発生したら、とりあえず一覧表で検索
- もし一覧表に記載ないものであれば、エラー内容を追記
- 自分で解決できたら、エラー原因、対応方法を記載
- 自分で解決できない場合、問い合わせてもらう
- 解決したらエラー原因、対応方法を記載
結果、同じような問い合わせが減り、初学者が悩む時間の削減に繋がりました。
コーディングポリシーの作成
記述内容の統一感がなくなることで、可読性などに影響が出始めたため、ルールというより守るとみんなが嬉しいくらいの気持ちで、ポリシーとして定めることにしました。
また、体裁に関する統一もついでに図ろうと、フォーマッターを導入することで、人による記載のブレを少しでも無くそうとしました。
プロジェクトの早期フェーズでは、テストコードの書き方とかもどんどん良い書き方を提案、適用していきたいという思いから、初めはルールに縛られないよう、特にテストコードの書き方を統一していませんでした。しかし、一定以上の記載ルールがないと、レビュアーもレビューイも実際困ったこともあり、ポリシー策定に踏み切りました。
結果、一定誰が書いても同じような記載でテストコードが書けるようになりました。フォーマッターも、シングルクォーテーションやダブルクォーテーションなどの統一など、細かい統一ではありますが、より読みやすくなったという点では、導入して良かったと考えます。
また、変数名の付け方など初学者が少し悩んでしまうことも、ポリシーを定めたことで、迷う時間を削減できたと考えます。
課題 2 に対するアクション
自動テストを考慮したスケジュールを立てるのが難しいという課題に対しては、メルコイン QA メンバーで唯一メルペイでの自動化の知見を持っている自分が入っていくことで、テスト自動化を推進していきました。
アクションとしてはとてもシンプルで、具体的にいつまでに何をやっていくかを決め、不透明な部分に対しては、リスクヘッジしていき、元々やりたいQA（テスト）をなるべく止めないよう、動きました。
メルコインでは、そもそも scenarigo を使うための準備も別途必要であったこともあり、アーキテクトチームや認証基盤チーム、user-tkoolチームの方々と協力し、大きく以下のようなことをする必要がありました。
- scenarigo そのものを使えるようにする必要があった。
- メルペイとはセキュリティ要件が異なり、それに伴い認証方法が異なったため。
- メルペイで動くサービスとは異なるクラスタで動作するため、メルコインとのクラスタ間の通信を考慮するため。
- ユーザ作成周りは user-tkool を利用している部分もあり、メルコインに合わせた対応が必要となったため。
- 各マイクロサービスで、scenarigo を使えるようにする必要があった。（リモート実行）
- 対応として、まずは CI 上で動かす必要があったため。
- ローカル（個人 PC）で scenarigo を実行できるようにする必要があった。
- リモート実行だと、git で push 後に CI の結果を待つ必要があったため、作成したテストコードを確認するのに、とてつもなく生産性が悪かったため。
QA としては、お願いする部分ばかりでしたが、自分の方では各マイクロサービスで scenarigo を使った疎通確認など、アーキテクトチームと QA 間の橋渡し的なポジションで 10 を超えるマイクロサービスに対して、導入作業をしていきました。
また、スムーズに行かない部分もありました。例えば scenarigo が使えない時は、シェルスクリプトで curl を使った API のリクエストをできるようにして、一先ずそれで API のテストを一部したこともありました。
結果、無事導入したい 10 を超えるマイクロサービス全てに対し、自動テストが書け、実行することができました。
課題 3 に対するアクション
デバッグ機能（デバッグ API）の実装など、テストコードを書く以外にも工数が発生するという課題に対しては、こちらも対応自体はシンプルで、デバッグ API の必要性などを QA メンバーと議論し、開発メンバーへ実装を早めに相談しました。対応可能な部分は対応いただき、対応難しそうな部分は優先度を加味して、一先ず自動化の範囲から外す等をして、少しでも自動化できる範囲を広げました。
結果、どういったテストパターンが自動化しにくいかが見えつつ、必要なテストコードを書くことができました。
メルペイでの課題に対する、メルコインでのアクションまとめ
各観点ごとに整理すると以下の通りです。
- 課題 1
- 計画の早い段階でレクチャー会の実施することで、ツールへの理解を深めた。
- デイリーの朝会に参加することで、気軽に質問できるような場を作った。
- エラー対応一覧表の作成と運用することで、初学者の悩む時間を削減した。
- コーディングポリシーを作成することで、人によるテストコードの体裁のブレを削減した。
- 課題 2
- いつまでに何をやっていくかを具体的に決め、不透明な部分に対しては、リスクヘッジしていき、元々やりたい QA をなるべく止めないよう動いた。
- 課題 3
- 早めに相談して、自動化できる箇所を広げつつ、できない箇所を早めに見極めた。
それぞれのメルペイで上がった課題に対してアクションを行ったことで、コードの可読性を上げつつ、リリース前までに自動テストを回し、品質チェックを行える状態にすることができました。
今回対応した内容は、とても簡単に言うと、テスト自動化を計画立てて対応したということに尽きます。
テスト自動化は手段として行われることが多く、事前にしっかり計画を立てて進めることができないこともあると思います。
しかし、今回のように自動化の計画をしっかりと立てることによって、スムーズに自動化を推進できたことは、メルペイ・メルコイン QA として非常に良いノウハウになったと思っています。
今後は他のメンバーでも自動化の推進ができる仕組みづくりに注力していきたいと考えています。
残る課題
良いことばかりだけではなく、やはり課題も残りました。現状見えてるものとしては以下の通りです。
- テストの内容が機能的なものが多く、効率的なテストになっていない
- 一部自動化を諦めた範囲が残っている
- レビューができる人が少ない
1 に対しては、既に対策を打っており、根本を辿るとそもそも API テストや自動テストに対して、どうするべきかの方向性がズレていたことが原因だったので、メルペイにおける（メルコインで目指したい）API テストと、自動テストについて、一度ドキュメントに整理し、それをもってすり合わせ会を実施しました。結果、効率良く、またお客さま視点のシナリオ（テストコード）が少しずつ増えていっている状況です。
2 に対しては、1 とも関係しますが、今後のスケジュールと相談しつつ、既存の機能的なテストをお客さま視点のシナリオに置き換えながら地道に対応していきたいと考えています。
3 に対しても、社内勉強会などを開催し、地道に scenarigo に詳しい人を増やしていきたいと考えています。
今回のことで感じたこと
- リモートワーク主体となり、
言葉だけでナレッジを伝えていくことの難しさを痛感しました。例えば、レクチャー会はやってみて一定効果はあったとは思っています。しかし、そこで口頭だけで伝えた内容が時間が経つにつれお互い忘れてしまったりもしました。これはレクチャー会のやり方として、過去の資料をベースに説明し、口頭で大事なことを補足するなどをしたためです。雑に動画見てというのも違うと思うので、いつでも認識合わせができるよう伝えたいことは全てドキュメント化するのが一番良いのかなーと思いました。ただ、ドキュメントばかり増えると、今度はどこ見たら良いの？問題も発生したりするので、そこも考慮して整理する必要があるかなとも思いました。 - 昨今 AI の進化が凄まじく、今回取り上げた課題感に対しても、今後は AI による解決も期待しています。例えば、コーディングスキル問題などは GitHub Copilot を活用することで、誰もが一定のレベルで書けるようになったり、ドキュメントどこにあるの？問題も ChatGPT を活用するなどして、人に依存しない形で解決することができるかもしれません。ワクワクが止まらないですね！
最後に
- 本記事では、メルペイで得た経験をメルコインで活かした実話を紹介させていただきました。本記事で取り組んだことが、何かのヒントになれば嬉しいです。本記事で紹介しきれていない細かい話もあるので、興味ありましたらカジュアル面談等でお話できればと思います。
- 本記事で メルペイ の QA Engineer に興味を少しでも持っていただけたら幸いです。
現在 メルペイ のミッション・バリューに共感できる QA Engineer を募集しております。一緒に働き、切磋琢磨できる仲間をお待ちしております！
最後までお読みいただきありがとうございました。
