Merpay & Mercoin Tech Fest 2023 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りで、2023年8月22日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
この記事は、「なめらかなFintech QAを実現するために テストケースフォーマットを標準化した話」の書き起こしです。
@satomasa：「なめらかなFintech QAを実現するために テストケースフォーマットを標準化した話」ということで、ここ半年ほど、主に私と@y-sakamotoさんで取り組んだ内容について説明します。
@satomasa：メルペイでQAエンジニアをやっている@satomasaと申します。よろしくお願いします。
@y-sakamoto：同じくメルペイでQAエンジニアをしております、@y-sakamotoと申します。よろしくお願いします。
@satomasa：まず、メルペイQAチームの体制から説明させていただきます。QAチームはQA1・QA2・QA3の3チームにわかれています。それぞれのチームは社員とビジネスパートナーさんで構成され、メンバーはメルペイに存在する各プロダクトにアサインされる形で日々QAの活動を行っております。
メルペイにはいろいろなプロダクトが存在することもあり、QAへのやり方もいろいろあります。バックエンド、フロントエンド、クライアント、QAのプロセスもさまざまです。例えば、テストケースを使わないケースもありました。
また、プロダクトがたくさんあるため、各プロダクトチームの体制も状況もさまざまです。アサインされたチームの状況によって、各QAメンバーが工夫しながらテストケースを進化させていました。そのため、テストケースのフォーマットがチームごとあるいはメンバーごとによっても違う状態でした。
テストケースのフォーマットが標準化されていない状態が続くことで、いくつかの課題が見えるようになってきました。
例えば、アサインチーム変更時のオンボーディングコストが高いこと。例えばプロダクトAからプロダクトBのチームに異動になった場合に、新しいチームのテストケースに慣れる必要があったり、テスト実施時に検出した不具合が管理されていなかったり、チームごとにテスト結果の記載方法が違うため、品質状況を把握するために必要な情報の取得が難しいという問題もありました。
また、QA完了時のテスト計画報告書を作成する際に工数がかかっていました。テスト結果の集計がされていないなどの理由により、QAを完了した後に改めてテスト結果を集計する必要がありました。
以上のような課題を解決するために、テストケースフォーマット標準化プロジェクトが立ち上がりました。
テストケースフォーマット標準化プロジェクトで取り組んだ内容について順番に説明します。
まず、プロジェクト方針の決定ということで、決めたことはいろいろあるんですが、一部を紹介します。
まず、どこまでフォーマットを標準化するかに関しては、当初は「最低限のルールだけ決めて、それぞれのチームである程度自由に変更ができるフォーマットにしよう」ということにしました。
この部分については、後に方針を変更しました。各チームのテストケースを見比べたところ、意外とフォーマットに違いがなかったことと、自由度が高いと、結局バラバラになり、目的を達成できないリスクがあるためです。そこで固定化のフォーマットを作るという方針に変更しました。
プロジェクトの活動方針についても決めました。weeklyでmtgを1時間開催することにし、この時間で、進捗の共有だけではなくて、プロジェクトの作業を行うことにしました。
私も@y-sakamotoも、通常のQA業務を並行して行っているので、このプロジェクトに関わる時間をあらかじめ確保しておくことで、プロジェクトの業務が停滞することがなかったと思います。
次に、各チームのテストケースフォーマットの調査を行いました。
各チームの代表的なテストケースをサンプリングして、10種類ほど集めました。サンプリングしたテストケースをメンバーで比較した結果、各チームでいろいろなテストケースのフォーマットが使用されていることと、基本的な部分についてはあまり違いがないということがわかりました。これによって、どのようにテストケースフォーマットを標準化していくべきかが何となく見えてきました。
次にドキュメントの作成を行いました。今回のプロジェクトで作成したドキュメントは大きく三つあります。テストケースフォーマット、テスト結果集計、運用プロセスです。こちらのドキュメントの詳細は、後ほど説明します。
次にトライアルの実施を行いました。ドキュメントの作成が一通り終わったタイミングで作成したルールやフォーマットが運用に耐えられるかを試すために、トライアル期間を設けました。
まず新しいフォーマットを試してもらえるチームを募集し、実際に運用してもらい、気づいたこと・改善してほしいことをフィードバックしてもらいました。
その内容を、自分と@y-sakamotoさんで確認して、必要に応じてドキュメントを更新しました。トライアル期間でいくつかフィードバックをもらいましたが、運用上、大きな問題が発生しないってことがわかったので、バージョン1.0のリリースに向けて、さらにドキュメントの精度を上げていくことになりました。
いよいよバージョン1.0のリリースとなります。トライアル期間で出たフィードバックを元に修正をして、バージョン1.0としてリリースしました。ただ全チームで一斉に新しいフォーマットに切り替えることが難しいので、切りのいいタイミングで新しいフォーマットへの移行をお願いしました。
プロジェクトの立ち上げが2022年12月で、バージョン1.0のリリースが2023年4月と5ヶ月ほどかかりましたが、何とかリリースできました。
現在は、運用のフェーズとなっております。
運用フェーズでもフィードバックシートを用意して、実際に使ってみて感じた点や疑問点、不明点を書いてもらっています。運用フェーズでもweeklyのmtgは継続していて、新しいフィードバックがあれば、メンバーで議論して、改善が必要な点は、ドキュメントを更新しております。
次に、今回のプロジェクトで作成したドキュメントについて説明します。
@y-sakamoto：私の方から、テストケースフォーマットについて説明します。まずは目的を明らかにしました。先述の通り、今まではチームごとにフォーマットが異なっていたため、品質の分析に必要な情報が得られないケースもありました。
例えば、Aチームのテストケースにある項目が、Bチームのテストケースにはないため、最終的な品質分析を行う際に、Bチームのメンバーにヒアリングをして必要な情報を得るという、無駄な工数がかかることもありました。
またフォーマットが統一されることによって、チーム異動が発生した場合も、改めて異動先のフォーマットに慣れる必要がなくなるため、浮いた時間はドメインキャッチアップなど、よりオンボーディングでフォーカスしたいことに当てられると考えました。
続いて、我々はテストケースの項目とレイアウトを作成しました。テストケースに記載すべき必須項目については、検証観点や環境、エビデンス、確認手順、期待する結果など一般的なものを設定しました。
しかし、チームや検証対象によって必要な情報というのは異なりますので、必須項目以外にも、各チームの判断で項目を追加して良いというルールになっています。
また弊社ではイングリッシュスピーカーの方にテストケースのレビューをお願いすることもあるため、一部を英語化してレビューしやすいように言語面でも工夫を加えています。
メインとなるテストケース以外にも、必要なシートを作成しました。一つはバグ一覧シートです。
これまでは検出したバグを各チームおのおのが定めた場所で管理をしていました。しかし、チーム横断で行われる大規模な開発などでバグ集計をするときは、異なる管理場所を確認をしなければならず、バグを集計するだけでもコストがかなりかかっていました。そこでフォーマット内にバグ一覧シートを作成して、そこさえ確認しにいけば良いという形にしました。
次に自動テスト結果シートです。こちらはリリースの際に実行した自動テストの結果を残すシートになっています。
これまでは自動テストの結果をどう残すのかが定まっていなかったので、テストの証跡として十分ではありませんでした。しかし、実施した場合はこのシートに結果を残すと明確にルール化したことで、きちんと自動テストが実行され、QAもその結果を確認しているという証跡が間違いなく残るようになりました。
@satomasa：次にテスト結果集計について説明します。結果集計を必須にすることで、各チームの品質状況の把握の効率化と一定のルールに沿った集計結果シートをあらかじめ作成することで品質報告書の作成を効率化することが目的となります。
具体的に決めたルールとしては、テストケースの結果に使用する種別をOK・NG・Resolved・対象外・保留の五つとしました。特にNGだったテストケースがOKになった際に使う「Resolved」は各チームでルールがバラバラだったので、今回の標準化で統一された部分です。
テスト結果で集計する項目も決めました。
具体的には、項目数、実施対象項目数、OK、NG、Resolved、対象外、保留、進捗率、完了率、残項目数の10項目としました。項目も決めたのと、各項目の計算方法も、今回決めたので、チームによって、進捗率の計算方法や実施対象項目数のカウント方法が違うことがなくなり、全チーム同じ結果が集計できるようになりました。
現在、メルペイではこの集計シートを使ってテスト結果を管理しております。
次に、運用プロセスです。今回定めたテストケースフォーマットを正しく運用するために、運用プロセスを定義しました。
テスト実施中に検出した不具合をバグ一覧シートにまとめる、自動テストの結果を自動テスト結果シートに記載する、などの内容が書いてあります。運用が正しく行われているかを確認するために、チェックリストも作成しました。
テスト完了時にチェックすることで、テスト完了時にも、ルール通りに運用されているかの確認を行っています。
@y-sakamotoさん、良かったところはいくつかあると思いますが、何かありますかね。
@y-sakamoto：僕はテストケース設計するときに毎回フォーマットに悩む時間が少なからずあったので、フォーマットがすでに用意されていることで無駄な考える時間が数が減って、テスト観点出したり、設計時に本当にやるべき作業により集中できたと思います。
@satomasa：テストケースレビューの効率化もできたと思います。テストケースレビューは、開発の人も担当することがあるので、QAエンジニア以外にもメリットがあったと思います。
@y-sakamoto：フォーマットがバラバラだと、違うチームからレビューを頼まれたときにどこを見たらいいかわからないこともあったので、フォーマットが統一されているとレビューは確かにしやすいですね。
パートナーさんにも聞いたのですが、フォーマットが統一されたことで進捗状況が一目でわかると好評で、私も嬉しかったです。
@satomasa：それから、チーム異動時のオンボーディングコストの削減。今のところチーム異動が行われるケースはありませんが、削減される見込みです。
次に苦労したことです。難しい点は、やはり全ての要求を満たすテストケースフォーマットを作ることでした。
@y-sakamoto：全員の意見を盛り込もうとすると、情報過多になりフォーマット化した意味がなくなることもあると思います。意見を取捨選択することも難しかったです。
また、意見を反映しなかった場合に、「意見をくれた人にどうやって説明しよう」という大変さもあったかなと思います。
それから、最初の方針決めるときに、例えばバックエンドとクライアントという性質が違うものを同じフォーマットにまとめる運用と定めましたが、その判断は勇気が必要だったなと思います。
性質が違うものを同じケースでうまくやれるのかという不安はありましたが、意外に使ってみると大丈夫だったので一安心でした。
@satomasa：自分も@y-sakamotoさんも通常のQA業務を抱えつつ、こちらのプロジェクトに参加してたので、業務が忙しいときはこちらのプロジェクトに関わる工数が確保できず苦労しました。
@satomasa：今回のプロジェクトを通じて、思わぬ効果もありました。
具体的には、QAチーム内でのコミュニケーションが活性化されました。現状のQAチームの体制上、各プロジェクトチームに配属になっているので、なかなかQAメンバーでコミュニケーションを取る機会が正直ありませんでした。
一つのことにQAメンバーで取り組む機会がなかったので、今回のプロジェクトを通して、今までコミュニケーションが取れていなかったQAメンバーとも、コミュニケーションが取れるようになったのが大きかったかなと思ってます。
@y-sakamotoさんとも所属しているプロダクトチームが違うので、これまではあまり話したことがありませんでしたが、今回のプロジェクトを通してコミュニケーションが取れたと思います。
@y-sakamoto：そうですね。プロジェクトが違うと、長い間一緒に何か一つのことをやる機会がなかったので私も@satomasaさんとこの標準化のプロジェクトをやれてよかったかなと思いますし、これからのQA業務やまた何か一緒にやろうってなったときもよりスムーズにできると思います。
@satomasa：最後に、今見えている課題と、今後取り組んでいきたいことを紹介します。
まずは全チームへ浸透させたいです。多くのチームに使ってもらうことで、いろいろなフィードバックを得られるので、それを参考にしながらよりよいフォーマットを作りたいです。
今後取り組んでいきたいことは、テスト結果報告書の自動作成です。テストケースフォーマット等や集計結果を標準化したことで、テスト結果報告書に必要な情報が収集できるようになりました。
その情報をもとに、テストが終わったタイミングで、テスト結果報告書を自動作成できる仕組みを作れたらと思います。
@y-sakamoto：自動作成を実現できたら、ものすごく工数削減になると思います。
@satomasa：以上が、テストケースフォーマット標準化プロジェクトで取り組んだ内容です。ご清聴ありがとうございました。
