Mercari Advent Calendar 2020 の21日目は、メルカリ QAE チームの@funaki、 @sawachan、 @hkondo134、 @yukanish、 @____rina____ がお送りします。
長い間メルカリのQAエンジニアはプロジェクトに入ってQA活動（主にプロジェクトで開発されるプロダクトのテストに関する活動）を行っていました。また、開発では昨年からスクラム開発を採用し、テストに対する活動もスクラムチームのエンジニアやPMが実施しています。その結果、QAエンジニアの役割も、プロダクトのテスト実施ではなく、メルカリのプロダクトやサービス全体の品質を保証するための活動、すなわち本来の役割であるQuality Assurance活動を行うことが求められています。
品質保証についてはVPの@wakasaさんがブログを書いていますので、こちらもご覧ください。Quality Assurance is Engineering Excellence
Scrum
QAエンジニアはスクラムの外へ。レビューを中心とした活動に変わりました。
メルカリではプロダクトを複数の領域にわけており、それをCampと呼んでいます。
テストに関する活動（特にテスト設計やテスト実行）はスクラムチームのエンジニアやPMが実施しています。QAエンジニアもCampにアサインされていますが、QAエンジニアはスペック（機能要件や仕様など）やテストケースに対するレビューを行っています。その他に、リファインメントやスプリントレビューなどのスクラムイベントに参加するQAエンジニアもいます。QAの観点から、懸念事項や足りていない項目などがないかを指摘しています。
QA Portal
QAエンジニアのナレッジを、開発する全員が閲覧しやすくなりました。
QAエンジニアリングチームには、テスト実行のためのノウハウがたくさんあります。それをすべてのエンジニアやPMにナレッジ共有する必要があります。そこで、QAポータルサイトとしてまとめ、Confluenceを使って社内公開を行っています。英語話者も多いため、ドキュメントは英語を中心に書いています。
- Onboarding : QAをはじめるための情報やリンク集
- Various test accounts：テスト用のアカウントを利用するための情報
- Features and screens：メルカリの機能一覧と画面一覧の情報へのURL
- Test Environment/Tools/Devices：
- How to testing：テスト環境、本番環境でプロダクトの各機能のテスト実行の手順とポイントやアプリのインストール方法、チケット運用方法、テストプラン・テストケースの例、バグレポートの例、アプリリリースのプロセスの説明などの情報
- JIRA Workflow：チケットのワークフローについての説明
- Automation Testing（E2E Test）：iOSとAndroidのUI Testについての情報
- Other Information：その他の情報
- FAQ for QA：FAQ集
また、このQAポータルサイトをより良くするために、Slackのリアクション機能からQAポータルサイトに追加するトピックを自動収集したり、アンケートを実施したり、啓蒙活動をしています。
Automation Testing(E2E Test)
ほとんどのQAエンジニアがテストコードを書き始めました。
メルカリアプリのリグレッションの自動テストはQAエンジニアが作成・メンテナンスを行っています。以前はAutomationエンジニアがテストコードを作成していましたが、現在はQAエンジニアが担当しています。自動テストの参加メンバーのキャリアのバッググラウンドはさまざまで、Automationエンジニアが継続参加していたり、前職にてProductコードを書いていたQAエンジニアがいたり、今回初めてコードを書きはじめたQAエンジニアもいます。iOSとAndroidでも現在取り組んでいる内容が異なります。
iOS
iOSの自動テストのメンバーは、毎日作成したテストの実行、実行に失敗したテストの問題特定、必要に応じてテストコードの修正をおこなっています。以前は環境の問題が発生したために、自動実行ができなくなった時期がありました。そのため、担当者は業務中にローカル実行を行う必要があり、修正まで含めると一日仕事になってしまい、時間が無駄になっていました。現在は環境の問題も解決し、CIで毎晩実行できるようになりました。QAエンジニアが参加し担当者も増えたことや修正に割ける時間も増えたことにより、失敗するテストケースが減少しました。
Android
現在Espressoを使用してテストコードを書いています。前はAppiumを使用し、Rubyで書いていました。しかし、アプリケーションと同じリポジトリにテストを配置し、アプリケーションと同じ開発言語のKotlinでUIテストを書くことができるよう、Expressoに移行することにしました。また、シナリオの内容や説明をAppium利用時代は日本語で書いていたのですが、Espressoへの移行に伴い、英語で書くように改めました。リポジトリや、記述言語や自然言語を統一することにより、エンジニアもUIテストに取り組みやすくなることを期待しています。
現在はテストコードのEspressoへの移行は完了しており、失敗しがちなテストケースのリファクタリングを行っています。また、テスト実行にはFirebase Test Labというクラウドベースでアプリのテストを行うインフラストラクチャーを使っていますが、課題がまだ残っています。それは、Test Labのデバイスに依存する問題であったり、実行タイミングによりテストが失敗することであったり、平行実行をしていても前に実行されるテスト実行が失敗することが依存して安定してテスト実行ができていないなどです。引き続きこれらの課題に取り組みます。
Regression test management
2020年も継続活動中です。英語化を行うことやテストケースの妥当性を見直して、テストケースが古くならないように気をつけています。
先ほど説明したiOSとAndroidのリグレッション自動テストは、両OSで同じテストケースを実装するようにしています。Regression test managementはそれらのテストケース管理を指します。そのためのツールとしてTestRailを使用し、テストケースの作成とメンテナンスを行っています。
作成したテストケースは大きく２つの目的で利用しています。１つ目は自動テストとして毎日実行する場合、２つ目はアプリリリースの前のリリース判定テストで使用する場合です。リリース判定テストでは、ケースごとに自動実行と手動実行が混在しています。それぞれの目的ごとに、適切なテストケースをピックアップして確認しています。
Client release facilitate
2020年もビジネスパートナーが主体となって活動を継続しています。
メルカリのアプリは現在２週間に一度のペースでリリースを行っています。一度のリリースには複数のプロジェクト施策やメルペイの機能も含まれるため、リリースするためのプロセス（工程）が整理されています。リリースプロセスについては、以前ブログで紹介しましたので、こちらをご覧ください。（アプリを安全にリリースするための取り組み(Release trainとClient release process)）
クライアントをリリースするプロセスを円滑にすすめることをクライアントリリースファシリテートと呼んでおり、QAエンジニア（現在はビジネスパートナーのQAエンジニア）が行っています。クライアントリリースファシリテーターが行う内容もプロセス化されています。クライアントリリースファシリテートチームは、リリースごとにふりかえりを行い、クライアントリリースファシリテートのプロセス改善を続けています。
Bug Analysis
2020年はバグ分析を本格化させるための準備をしています。
メルカリでは発見したバグはJIRAを使ってチケット管理しています。QAエンジニアは開発チームへ品質改善を提案できるように、バグ分析の取り組みを行っています。これには、バグの分析を行う手法や指標の選定や、バグの状況を可視化するための環境の構築や、バグのチケット管理ルールの見直しが必要です。
可視化するためのツールとして、LookerというBIツールを採用しています。バグ分析はさまざまなデータを組み合わせて分析を行うため、可視化するにあたって柔軟なカスタマイズ性を必要とします。Lookerはデータを自由に組み合わせてグラフを作成することができ、それらをダッシュボード上で見やすく管理できるためバグ分析に適したツールです。現在は、Lookerでのグラフの作り方やJIRAからのデータの取得方法などの調査をしています。今後はバグ分析ができるデータが集まり次第、バグの発生状況から開発された機能の品質状況を判断し、開発チームへ品質改善をするための提案を実施する予定です。
Device management
スクラムメンバーも所持するようになり、在宅勤務でも管理ができるようにしました。
メルカリでは現在QA用の検証端末機（以降、デバイス）として、約300台 約80バージョンのOSを揃えています。お客さまは多種多様なデバイスやOSを利用しています。デバイスやOSをできるだけ幅広く網羅してテストできるように、デバイスの購入やOSをバージョンアップを管理しています。
デバイスはQAエンジニアが使用するためだけではなく、各スクラムチームのエンジニアやPMなども使用しています。メンバー間で貸し借りもあるため、２週間ごとにデバイスの所在確認をQAエンジニアが行っています。今年は在宅勤務が多くなり、デバイスの貸し借りが簡単にできなくなりました。在宅勤務でもテストの実施が効率的にできるように、クラウド検証機サービスの選定などもQAエンジニアが行っています。
Business Partner Management
QAエンジニアが1on1を実施し、ビジネスパートナーもより働きやすい環境になるようにしています。
QAエンジニアリングチームには複数のビジネスパートナーが入ってメルカリのQAエンジニアと一緒に働いています。ビジネスパートナーにとっても働きやすい環境を提供するために、ひとりひとりと1on1を実施し、気になっていることや、不安に思っていること、QAエンジニアリングチームに提案したいことや、近況などを聞いています。ビジネスパートナーからよい提案をいただくことがあり、さらに品質の高いプロダクトとなるようにQAエンジニアリングチームと一緒に取り組むことができています。そして、QAエンジニアもより活動の幅を広げることができます。ビジネスパートナーとの働き方についてはこちらも参考にしてください。
Retrospective
ふりかえりをきっかけに、チームを巻き込む自主的な活動が増えました。
QAエンジニアリングチームでは、２週間に一度ふりかえりを実施しています。ふりかえりの時間では、その期間のできごとをふりかえって、カイゼンするためのアクションアイテムを出しています。ふりかえりにはRetriumというツールを使っています。
Retriumはいくつかのふりかえりのためのフォーマットが用意されています。Retriumでは、無記名の起票機能、起票のグルーピング機能、無記名の投票機能、アクションアイテムの入力機能、ストップウォッチ機能、アクションアイテムの確認機能があり、これらの機能はオンライン上で参加者みんなで同時実行をができます。図として掲載しているKPTもデフォルトでは用意されていませんが、自分たちで簡単に作成することが可能です。
ふりかえりを続けた結果、QAエンジニアリングチームのコミュニケーションが向上したり、自主的にナレッジシェアやチーム内で勉強会をする機会が増えました。
画像はPythonを使用したリリースbotの作成についての勉強会の様子です。毎週何らかの勉強会が開催されています。
前クォーターから、ふりかえりのファシリテートを２人体制で行うようにしました。ふりかえりでは１人がファシリテート、１人がRetriumの操作および書記をしています。そして、ふりかえりの後はふりかえりのふりかえりを行い、この時間自体のカイゼンも続けています。
ふりかえり期間が２週間といっても、その間にどのようなことがあったのか忘れることも多いです。そこで、その期間にあったイベントやSlackで話題になったものをふりかえりカレンダーを作って紹介するようにしています。これはふりかえりを１時間で終わるようにするための工夫のひとつになっています。
おわりに
今回ご紹介した内容のいくつかは、以前はプロジェクトのQAと兼任して実施していました。現在のQAの形になって、今まで取り組めなかった課題やカイゼンにも集中して取り組むことができるようになってきました。今回ご紹介した活動は複数人がかけもちで行っていますが、さらに新しく取り組みたいもの、課題もたくさんあります。
メルカリではミッション・バリューに共感できるQAエンジニアを募集しています。一緒に働ける仲間をお待ちしております。
明日のMercari Advent Calendar 2020執筆担当は、 MS Platform (Infra) Engineer の ＠_moricho_ さんです。引き続きお楽しみください。
