こんにちは。QA Engineerの @____rina____です。
メルカリのQAの形
メルカリでは長い間、プロジェクトチームにQAエンジニアをアサインし、専任としてQAに関する活動をおこなっていました。
昨年よりプロジェクトがスクラム開発へ移行していくことになり、スプリントを回していく中で、QAエンジニアだけがテストフェーズをおこなうと開発リズムがとりづらく、ボトルネックになっています。 その解決策のひとつとして、QAをスクラムチームのメンバーもおこなえるように移行中です。
移行するためには、今までQAエンジニアがおこなっていたプロセスやHowToなどを伝える必要があるため、 現在、さまざまな施策を実施中です。 今回は、私が所属するスクラムチームでおこなっているQAプロセス（とくにテスト戦略）についてご紹介します。
ぼくたちのQAJourney
私の所属するスクラムチームは、お問い合わせ対応をおこなうツールの新規開発をしています。 今回ご紹介するスクラムチームは、PM、Frontendエンジニア、Backendエンジニアが一人ずつと、QAに私がいました。
今回は今まで私がおこなっていたテスト計画の作成、テスト設計、テスト実行を私以外のメンバーがおこない、 私はそれらのレビューや、ペア計画、ペアテストなどを行いました。
誰がどんなQAをするのか
最初にみんなで話し合ったのは、誰がどのテストを行うかというところでした。 他のスクラムチームでは、必ずコーディングをおこなった人と別の人がQA実施をおこなっていました。 お互いのQA（とくにテスト実行）をおこなうには、環境整備や仕様を把握するコストが高すぎるという意見がでました。 実施するテストのレビューは私がレビューしていたため、 「実装者以外のメンバーが必ずQA（レビューも含む）を実施することになるよね」と整理し、実装者が、実装した対象のテスト実行をおこなってよいこととしました。
💡QA（テストにおける活動。テストに関するレビューも含む）とコーディングは二人以上でおこなう。ただし、コーディングとテスト実行は同一の人でもよいとする。
テスト実行結果をどこまで書くか
この取り組みを始めたときは、QAレビューというフェーズをテスト実行の完了後におこなっていました。 正確には、QAフェーズの間でよければいつでもよいとしていました。 事前にテストケースを書いていても、テスト実施中に新しく気になるところなどが出てくるため、最終的にQAエンジニアでレビューをして、そのタスクを完了とみなしたかったからです。
今までは、QAエンジニア同士でもそのようにおこなっていました。 QAエンジニア同士のときは、それであまり問題なく回っていました。
それをスクラムチームで実施したところ、エビデンスを多く残していたり、テストの実行結果は数多く残しているが、 どのような意図で実施したのかが却って見づらくなる問題がおこりました。
また、これらのレビューやフィードバックによる追加テストの実施も開発のボトルネックになりました。
そのため、まずはテストする内容を事前に書いておき、それをテスト実行前にレビューをおこなうように変更しました。
💡QAレビューを前に倒す。開発中（コーディング中）にテスト内容を確定するようにする
テストする内容はどこまで書くか
テストする内容をテストケースとして先に書くようにしましたが、ここでもテストする内容はどこまで書くのがよいのか課題になりました。 テストケースをレビューする人（QAエンジニア）が、テストケースの粒度が変わることの意味を説明できないと、テストケースを作る方は、すべて同じ粒度のテストケースが増えていきそうでした。 そのようなテストケースができてしまうと、それをレビューする方も意図がわからずお互いにうれしくありません。
そこで、「そもそも何を書いて欲しいのか」についてスクラムチームのみんなで話しあいました。 その結果、「スプリント内で完了したいタスクチケットについて、完了したことを保証できる項目が書きたい。 それは完了の定義（Definition of Done= Doneの定義)に値するのではないか？」 となりました。
そこで、テストケースの作成は任意（どうしてもテストケースで整理した方がいいものなど）とし、 Doneの定義をタスクに着手する前までに書き、それをQAエンジニアがレビューすることにしました。
💡Doneの定義をしっかり書く。QAエンジニアはそれをレビューし、リグレッションも含め、テストの視点も取り入れるようにする
各メンバーに応じた戦略
基本的に上記の実施をメンバー全員で合意しました。（合意するまで数スプリントTryした結果です！） これらのテストの多くがマニュアルでの実行になりますが、その他にもいくつか工夫した点を紹介します。
BackendのUnitテストのコードレビューをおこなう
これは前クォーターから少しずつ取り入れているのですが、BackendのUnitテストのコードをQAエンジニアがレビューしています。 PRベースのレビューではなく、Backendエンジニアが不安に感じたときに呼んでもらい、一緒にコードレビューをおこなうような形にしています。
FrontendはUIレビューにPMと一緒に入る
FrontendのUI設計ではFigmaを使うようになりました。 UI設計のレビューでは、PM、Frontendエンジニアと共に私も入り、その場でレビューと修正をするようにしました。
PMと一緒にテスト計画を作る
PM（PdM）とは、いわゆるシステムテストや受け入れテストなど、今までQAエンジニアがおこなってきたテストの多くの部分を考える必要があります。 とはいえ、事前にBackendエンジニアとFrontendエンジニアでも完了したテストもあるため、できるだけPMが注力したい内容に絞る必要があります。 PMが本当に注力したいテストは、届けたい相手（私たちのプロジェクトの場合、お問い合わせ対応のCSなど）の要求に応えられそうかという点になります。
テスト計画は、前クォーターから少しずつ私が作っているものがありました。 ここでは、どんな機能のテストをするのか、それを誰がするのか、どのようなタスクで分かれているかなどがわかるようになっています。（ConfluenceとJIRAで構成しています） QAプロセスをスクラムチームに移行しても同じようなテスト計画を作成することで、BackendやFrontendでおこなっているものなどを含めて全体像が見やすくなりました。
おわりに
今回の取り組みでは、今までQAエンジニアがまとめて実施していた内容を、 適切なタイミングで適切なボリュームに割り振るようにし、全体像をテスト計画でみることができ、トレースしやすくなりました。
現在は、スクラムチームのメンバーも増え、今後さらに改善することが期待できます。 また、今後はレビューもQAエンジニアでなくとも実施できるようにするなど、さらに開発を加速するための取り組みをしていきます。
