
メルカリCTOが考えるエンジニアの価値
- #Advent Calendar
- #CTO
- #engineering management
Author: suguru
Merpay Advent Calendar 2020 の 8 日目は、メルペイフロントエンドチーム の @tanakaworld がお送りします。
2020 年後半からフロントエンドチームと QA チーム合同で、リグレッションテストの自動化に取り組んできました。E2E テストフレームワークである Cypress でマニュアルテストを自動化し、加えて TestRail を用いてテストケース管理も仕組み化することでワークフローの整備を進めています。本記事では、それらの取り組みについて紹介します。
実装を変更した結果、アプリケーション全体の振る舞いに予期せぬ影響がないかどうかを確認するテストです。メルペイではリリース前 QA の最終フェーズでリグレッションテストを実施しています。Web アプリケーションを End To End (E2E) でテストすることで、フロントエンドだけでなくバックエンド・インフラなども総合してテストすることができます。
2020 年前半までは、リグレッションテストの大半を QA エンジニアが手作業で行っていました。リリースの度に繰り返し実施されるので、自動化することで QA 負荷を軽減し、効率化・迅速化を図りたいと考えました。
メルペイでは E2E テストのフレームワークに Cypress を採用しています。技術選定や基盤構築、初期の自動化はフロントエンドエンジニアを中心に進めました。
メルペイではプロダクト開発のエンジニアと QA エンジニアで役割分担をしています。プロダクト開発のエンジニアが単体テストやインテグレーションテストを書きます。それとは別に、リリース前のリグレッションテストは QA エンジニアが担当するという分担です。そのため、フロントエンドエンジニアだけでなく、我々が採用する技術を知悉 (ちしつ。知り尽くしていること) しているとは限らない QA エンジニアにも扱いやすくなることを重視しました。選定理由を次にまとめます。
コードカバレッジだけでなくテストコードの品質にも注意を払っています。テストが自動化されていても、メンテナンスしづらいテストコード・壊れやすいテストコードだと、後々自分たちを守る盾ではなく、足枷になってしまいます。そのため、いくつかルールを決めています。
その他、フロントエンドチームと QA チームで一緒に、ハンズオンやペアプログラミングを実施したり、Cypress の動向をシェアするなどをしています。
リグレッションテストはテスト環境に対して実施します。テスト環境は本番とほぼ同等の環境で、すべてのマイクロサービスがデプロイされた環境になります。
テストする内容によってあらかじめテストデータを用意するケースと、テスト実行時に動的にテストデータを作成するケースがあります。すべてのテストデータを都度作成していると、テスト実行時間が膨大になってしまいます。テストの実行中にデータが更新される場合は、データの使いまわしはせずにそのテスト専用のデータを都度作成する方針です。
Cypress とテスト環境の間にテストデータ作成を中継する BFF を置いています。Node.js のサーバーで「 Cypress Data Server 」と呼んでいます(社内用語)。Cypress のテストコードはブラウザ上で実行されます。データ作成時に、ブラウザ上では動作させることのできない npm パッケージを用いた処理を実行したいニーズなどがあり、別サーバとして切り出しました。次がその構成イメージです。
Cypress 側は単に HTTP リクエストを送るシンプルな処理に留めています。テストデータ作成結果をレスポンスとして受け取り、テストコード上で扱うことができます。この構成は cypress-on-rails から着想を得ました。
beforeEach(() => {
cy.createUserData({ ••• }).then((user) => {
cy.wrap(user).as(‘user’);
});
});
現在は Postman と 社内ツールの user-tkool を用いたデータ作成をサポートしています。
QA チームは API のテストを Postman を使って実施していました。フロントエンドのテストを実行するときにその Postman のシナリオを用いてテストデータを作成できるようにしています。テストコードリポジトリ内で Postman のシナリオファイルを管理し、それを Cypress Data Server 経由で実行できます。
user-tkool は様々なメルカリ・メルペイのお客さまのデータを作成することのできるツールです。ある日 API 対応もなされ、シナリオに組み込めるようになりました。Cypress Data Server からその API を用いてデータ作成を行っています。
ここまで Cypress 導入の背景やテストデータ作成に関する取り組みを説明しましたが、テストケースの管理でも課題解決に取り組んでいます。
テストケースは Google Sheets で管理していました。自由度が高い反面、管理方法が属人化したり、手作業が増えていることに課題を感じていました。最終的に TestRail に移行することで課題解決を図りました。
テストコードとテストケースの対応付けや、実施結果の確認などを人力で行っており、非効率さを感じていました。たとえば、次のような課題がありました。
TestRail はテストケース管理ができる SasS です。TestRail の概念と Cypress との連携方法を解説します。
Test Cases はテストケースのマスタです。TestRail の Web アプリケーション上でテストケースの新規作成・編集・削除ができます。ケースごとにユニークな ID が設定される他、自由にフィールドを追加することができます。フロントエンドチームでは Automation Status
というカスタムフィールドで、そのテストケースを自動化しているかどうかを定義しています。
これらのフィールドを用いて、自動でカバレッジ計算を行っています。
Test Run はテスト実施結果を記録します。テストケースのマスタである Test Cases をコピーする形で Test Run がつくられ、各ケースごとに結果を記録することができます。
TestRail は API を提供しており、Web アプリケーション上でできることが API で実行できます。Cypress から TestRun の作成と、テスト実行結果の登録を実行しています。Cypress コミュニティの TestRail レポーター が存在しますが、社内のワークフローに合わせてレポートロジックを変更するなどしたかったため、Fork して拡張しています。
Test Case の ID をテストコードに設定し、次のフローで処理されます。
describe('未ログイン', () => {
it('[C123456] 〇〇が表示されること', () => {
cy.get('h2').contains('○○');
});
});
結果が連携されると、TestRail 上で次のような結果が閲覧できます。
自動化されていないテストケースは Status が Untested
となります。それらのケースは手動でテストをして、結果を反映します。
このように、自動化されているテストケースとそうでないテストケースを TestRail 上で一元管理することができるのも嬉しいポイントです。
最後に、リリースするまでの実際のワークフローを紹介します。
テストケースの管理
テストコード更新、コードレビュー
テスト実行 + レポーティング
cypress run --reporter @merpay/cypress-testrail-reporter
とレポートオプションを指定して実行しますマニュアルテスト実施
テスト結果の可視化
TestRail を用いてテストケース管理を仕組み化し、Cypress でマニュアルテストの大部分を自動化することができました。一方で新たな課題も見つかってきました。
などなど、今後も継続して改善に取り組んでいきたいと思います。
メルペイでは、プロダクト品質や Developer Experience の向上、テスト自動化に興味があるエンジニアを募集しています!
明日の Merpay Advent Calendar 2020 執筆担当は、Backend Engineer の sou さんです。引き続きお楽しみください。