はじめに
こんにちは、メルカリでQAエンジニアをやっている @tettan （河野）です。この記事は、Mercari Advent Calendar 2021 の14日目の記事です。
先日、Merwork（メルワーク）という新規プロダクトがローンチされました。メルワークの開発チームで主にQA・テスト周りをリードしてきました。QAの立ち上げから、実際にQAを実施するところまで、どのようなことをやってきたのかを紹介していきたいと思います。QA立ち上げフェーズに携わる方に、参考にして頂ければ幸いです。
背景
私がメルカリにジョインしたのが今年の5月で、メルワークにジョインしたのが7月でした。入社2ヶ月で新規プロダクトの一人QAとして放り込まれるという、なんとも Go Bold なアサインでした。さらに、こちらの記事で紹介されているように、チームメンバーはグローバル、かつリモートという環境でのスタートでした。英語を使った業務経験がゼロの状態でこのような環境に飛び込むことになり、当初は多少ストレスを感じていましたが、チームメンバの皆さんがAll for Oneで非常に親切、かつプロダクトに向き合っていることもあり、何もない状態からなんとかQAを進められています。感謝です。
開発プロセスは、Weekly の（ガチガチではない）スクラム開発で、主要なスクラムのイベントにはQAエンジニアとして、参加しています。以降、スクラム開発の文脈を交えながら、QAの立ち上げ（準備）と実践を紹介していきます。
今までやってきたこと ・ 今やっていること
QAプロセス
チームにジョインしたタイミングでは、QAに関してはゼロの状態だったので、どうやってQA（テスト）を回して行くのかという、QAプロセスを検討しました。
メルカリでは、こちらの資料で紹介されているように、QAエンジニアではなく開発のチームメンバーがQAの責任を持つような体制に変わったのですが、さすがにQAを進める土台は必要だと考え、私が主体的に動きつつ、必要に応じてPM（Product Manager）と協力して進めてきました。
さて、QAプロセスのモデルを書いてはエンジニアやPMと議論を重ねて改善し、現状は後で示すモデルをTo beのQAプロセスとして、日々ブラッシュアップを行っています。
とはいえ、パブリックリリースまでは、このプロセスはフィットせず、実装が終わったいくつかのStoryをテスト対象とし、テスト計画、テスト設計、テスト実行、テスト報告、という基本的になテストプロセスに従ってQAを行ってきました。また、テスト実行フェーズは、PMと一緒にテストケースを消化しつつ、他のテスト設計フェーズも少しずつPMと協業できるようにしています。
立ち上げの準備としては、QAプロセスを検討しつつ、プロセスで扱う成果物、テスト計画書、テスト設計書、テスト報告書のテンプレートの作成を行ってきました。加えて、スクラムのサイクルとは別に切り出して、QAを行っています。
ここで、To beのQAプロセスを概説します。まず、リリースの単位でこのサイクルを回そうと考えており、リリース対象のStoryやSpecに対してテスト設計を行い、テストケースを作成していきます。次にそのテストケースをE2Eテストで実装可能なテストケースとマニュアルでテストが必要なテストケースに選別します。ここで前者のテストケースは主に機能を確認するようなテストで後者はUIを確認するようなテストを想定してもらえるとわかりやすいと思います。そして、テストケースに従い、マニュアルのテストを行いつつ、並行でE2Eテストの実装も行っていきます。E2Eテストの実装が終わったら、すべてのE2Eテスト（含むリグレッションテスト）を実行し、最後に、そのE2Eテストの実行結果とマニュアルテストの実行結果をもってリリースのジャッジを行うという流れになっています。
E2Eテスト by Cypress
QAプロセスで、E2Eテストに触れましたが、ここではその詳細に少しだけ触れたいと思います。
現在、E2Eテストは Cypress を使って、実装しています。実装そのものは私が行っていますが、Cypress の環境構築や実装したE2Eのレビューなど、フロントエンドエンジニアがサポートしてくれていて非常に助かっています。
また、QAプロセスの示したHappy pathは、パブリックリリースの範囲のものはConfluenceにまとめて、それをベースにチケットを作成し、スプリントプランニングで実装するHappy pathを決め、E2Eテストの実装を進めています。加えて、スプリントレビューで実装が終わった E2E のデモも行います。
将来的には、実装が終わったE2EのHappy PathsはTestRailに移行し、リリースのジャッジがよりスムーズに行えるよにしていきたいと考えています。
バグマネジメント
QAプロセスの構築と同時にバグを見つけてから修正するまでのフローの構築、バグチケットのテンプレートの作成を行いました。
メルワークの開発では、Monday.comを使って、スクラムのバックログ管理を行っているためバグのチケットも同じサービス内で運用できるように、バグチケットのテンプレートを作成し、フローも同様に Moday.com内でバグチケット作成からクローズまでの流れを整備しました。テスト実行はPMと一緒に行っているので、バグを見つけた場合はPMもテンプレートを使用してバグチケットを作成してもらっています。
また、バグチケットを作成するだけではなく、バグの優先順位の確認や修正するときのハンドリングなどのディレクションも合わせて行っています。加えて、優先度の高いバグチケットはスクラムの管理下でトラックされ進捗の確認が日々行われています。
立ち上げ準備として、バグフローとバグチケットのテンプレートに着手できていたので比較的ソフトランディングできたと思っています。ただ、バグのフローはいまいち周知できていないので、その点は、今後の課題と考えています。
おわりに
メルワークのQAに関して、QAプロセス、E2Eテスト、バグマネジメントの3つのトピックに分けて紹介してきました。今までそこそこ長い自身のQAキャリアの中で、ここまでピンでやったことはなく、Be a Proとして業務にフォーカスしつつ、Go Boldなチャレンジをさせてもらっていると感じております。
今後は、E2Eテストの拡張とリファクタリング、QAプロセスのブラッシュアップと実践を行っていきたいと考えていますので、また機会があれば、ブログで紹介しようと思います。
最後に、メルワークでは、現在チームメンバを積極募集中です！
カジュアルにお話したい方、採用情報の詳細を知りたい方は、こちらのページの下の方に情報を掲載しています。
また、 リリース記念 Teck talk （12/15（水））と メルワーク事業説明会（12/20（月））を予定しています。興味がある方はぜひ参加して頂けると嬉しいです！
明日の記事は@sahil505です。引き続きお楽しみください！
