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