なめらかなFintech QAを実現するためにテストケースフォーマットを標準化した話 / Standardizing Test Case Formats to Enable Seamless Fintech QA

メルペイQAチームでは、よりよいサービスをお客さまに早く届けるために、日々品質保証活動の生産性を上げる取り組みを行なっています。 今回その取り組みの1つとして、テストケースフォーマットの標準化を行いました。 QAチーム全員が使用するテストケースフォーマットをどのように作成していったのか、方針決定から運用開始に至るまでのプロセスや運用してみて分かった課題などお伝えできればと思います。

In order to provide our users with better services as fast as possible, the Merpay QA Team works to improve the productivity of our day-to-day quality assurance activities. Our initiative to standardize test case formats is one such recent example. In this presentation, we will relate how the QA Team created the test case format that all of our members use, as well as share things like processes ranging from planning and decision-making to starting operations and the issues we discovered in the process of operations.

------
Merpay & Mercoin Tech Fest 2023は3日間のオンライン技術カンファレンスです。
IT企業で働くソフトウェアエンジニアおよびメルペイ・メルコインの技術スタックに興味がある方々を対象に2023年8月22日（火）、23日（水）、24日（木）の3日間、開催します。 Merpay & Mercoin Tech Fest は事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りです。

今年のテーマは「Unleash Fintech」。 メルペイ・メルコインのこれまでの技術的な取り組みはもちろん、メルカリグループのFintech事業における新たな挑戦をお伝えします。 セッションでは事業を支える組織・技術・課題などへの試行錯誤やアプローチなど多面的にご紹介予定です。

メルペイ・メルコインが今後どのようにUnleash（解放）していくのか、ぜひ見に来てください。

■イベント関連情報
- 公式ウェブサイト：https://events.merpay.com/techfest-2023/
- 申し込みページ：https://mercari.connpass.com/event/286670/
- Twitterハッシュタグ： #MerpayMercoinTechFest
■リンク集
- メルカリ・メルペイイベント一覧：https://mercari.connpass.com/
- メルカリキャリアサイト：https://careers.mercari.com/
- メルカリエンジニアリングブログ：https://engineering.mercari.com/blog/
- メルカリエンジニア向けTwitterアカウント：https://twitter.com/mercaridevjp
- 株式会社メルペイ：https://jp.merpay.com/

Transcript

1. Session Title なめらかなFintech QAを実現するために テストケースフォーマットを標準化した話 Masatoshi Sato Merpay QA Team Yuki Sakamoto Merpay QA Team
2. Masatoshi Sato / @satomasa 第三者検証会社で約 10年、様々なシステムの QAを経 験。その後いくつかの事業会社の QAを経てメルペイに 入社。メルペイでは社内向けの管理画面の QAを主に 担当している。 株式会社メルペイ QA Engineer Yuki Sakamoto / @y-sakamoto ソーシャルゲーム、 WEBサービスのQAを経験し2021 年にメルペイ入社。主に督促、回収に関わる領域や WEB領域のQAを担当している。 株式会社メルペイ QA Engineer
3. QAチームの体制 テキストを入力テキスト テキストをテキストを入力テキスト 入力テキス Merpay/ Mercoin QA QA1 QA2 社員 パートナー 社員 パートナー 社員 パートナー QA Teams Product Teams Product A Product B assign QA3 社員 パートナー Product C Product D Product E Product F Product G Product H assign Product I Product J Product K Product L assign
4. 前置き • QAの対象がいろいろ ◦ Backend,Frontend,Client, … • QAのプロセスもいろいろ ◦ テストケースを作らずにチケット上に確認したことを記載してテスト完了す るケースがあった • 各Productチームの体制や状況もいろいろ ◦ アサインされたチームの状況によって、各メンバーが工夫しながらテスト ケースを進化させていた テストケースのフォーマットがチームごとあるいはメンバーごとによっても違う状態に なっていました
5. 前置き 例えば • アサインチーム変更時のオンボーディングコストが高い ◦ 移動したチームのテストケースに慣れる必要がある • 品質状況の把握するために必要な情報の取得が難しい ◦ テスト実施時に検出した不具合が管理されていない ◦ チームごとにテスト結果の記載方法が違う テストケースのフォーマットが標準化されていない状態が続くことで、い くつかの課題がみえるようになってきていました
6. 前置き • QA完了時のテスト結果報告書を作成する際に工数がかかってい た ◦ テスト結果の集計がされていない（わかりづらい）、まとまって いない等の理由により、QA完了後に改めてテスト結果を集計 する必要があった
7. 前置き このような課題を解決するために テストケースフォーマット標準化プロジェクト が立ち上がりました
8. テストケースフォーマット標準化に向けて • プロジェクト方針の決定 • 現状の各チームのテストケースフォーマットの調査 • ドキュメント作成 • trialの実施 • ver1.0のリリース • 運用 それぞれ、取り組んだ内容について簡単に説明します
9. テストケースフォーマット標準化に向けて • プロジェクト方針の決定 • 現状の各チームのテストケースフォーマットの調査 • ドキュメント作成 • trialの実施 • ver1.0のリリース • 運用
10. プロジェクト方針の決定 テストケースフォーマット標準化に向けて、プロジェクトの方針を決めま した。 決めたことはいろいろありますが、一部を紹介します。
11. プロジェクト方針の決定 • どこまでフォーマットを標準化するか ◦ 最低限のルールだけ決めて、それぞれのチームである程度自由に変更 ができるようなフォーマットにする 当初はこの方針としていたのですが、後に方針を変更しました • 変更後の方針 ◦ 固定化フォーマットを作る • 理由 ◦ 各チームのテストケースを見比べたところ、意外とフォーマットに違いがな かった ◦ 自由度が高いと、結局バラバラになってしまい目的を達成できないリスク がある
12. プロジェクト方針の決定 • プロジェクトの活動方針について ◦ weeklyでmtg(1h)を開催 ▪ この時間で進捗の共有だけでなく、プロジェクトの作業を 行う時間とした • 理由 ◦ 通常のQA業務と並行して、このプロジェクトに関 する作業を行うので予め作業時間を確保すること が目的 • 効果 ◦ プロジェクトの業務が停滞することがなかった
13. テストケースフォーマット標準化に向けて • プロジェクト方針の決定 • 現状の各チームのテストケースフォーマットの調査 • ドキュメント作成 • trialの実施 • ver1.0のリリース • 運用
14. 現状の各チームのテストケースフォーマットの調査 まず、各チームの代表的なテストケースを集め（約10種類）、 メンバーで比較を行いました 比較した結果、 • 各チームでいろいろなテストケースのフォーマットが使用されている • 基本的な部分についてはあまり違いがない ということが分かり、テストケースフォーマット標準化に向けてどうやって 標準化していくべきかが何となく見えてきました
15. テストケースフォーマット標準化に向けて • プロジェクト方針の決定 • 現状の各チームのテストケースフォーマットの調査 • ドキュメント作成 • trialの実施 • ver1.0のリリース • 運用
16. ドキュメント作成 今回のプロジェクトで作成したドキュメント • テストケースフォーマット ◦ 別途、使い方やルール等をドキュメント化 • テスト結果集計 ◦ 別途、使い方やルール等をドキュメント化 • 運用プロセス それぞれのドキュメントについての詳細は後ほど説明します
17. テストケースフォーマット標準化に向けて • プロジェクト方針の決定 • 現状の各チームのテストケースフォーマットの調査 • ドキュメント作成 • trialの実施 • ver1.0のリリース • 運用
18. trialの実施 ドキュメント作成が一通り終わったタイミングで、作成したルールやフォーマットが運 用に耐えうるかを試すためにtrial期間を設けました。 1. 新しいフォーマットを試していただくチームを募集 2. 運用してみて気づいたことや改善してほしいことをFBシートに記載 3. FBシートに記載された内容を確認し、必要に応じてドキュメントを更新 trial期間でいくつかFBを受け、修正した点はありましたが運用上大きな問題は発生 しないことが分かったため、ver1.0のリリースに向けてさらにドキュメントの精度をあ げていくことになりました。
19. テストケースフォーマット標準化に向けて • プロジェクト方針の決定 • 現状の各チームのテストケースフォーマットの調査 • ドキュメント作成 • trialの実施 • ver1.0のリリース • 運用
20. ver1.0のリリース trial期間で出たFBを経て、いくつかの修正をしてver1.0としてリリースしました。ただ全 チームで一斉に新しいフォーマットやルールを適用する事はできないため、キリの良い タイミングで新しいフォーマットへの移行をお願いする形としました。 プロジェクト立ち上げ：2022/12 ver1.0のリリース：2023/4 ver1.0のリリースまで5ヶ月ほどかかったが、何とかリリースすることができました。
21. ver1.0のリリース
22. テストケースフォーマット標準化に向けて • プロジェクト方針の決定 • 現状の各チームのテストケースフォーマットの調査 • ドキュメント作成 • trialの実施 • ver1.0のリリース • 運用
23. 運用 運用フェーズでもFBシートを用意して、実際に使ってみて感じた改善点や疑問/不明 点を書いてもらっています。 運用フェーズでもweeklyのmtgは継続しており、FBシートに新しいFBの記載があれ ばその場でメンバーで議論し、改善が必要な点はドキュメントも更新していく形をとっ ています。
24. 本プロジェクトで作成したドキュメントについて 今回のプロジェクトで作成したドキュメントについて、それぞれ説明します ドキュメントの構成 テストケースフォーマット 標準化 テストケースフォーマット フォーマット ドキュメント（ルール等を記載） テスト結果集計 フォーマット ドキュメント（ルール等を記載） 運用プロセス ドキュメント（ルール等を記載）
25. テストケースフォーマット • 目的 ◦ 品質分析の効率化 ▪ チームごとにフォーマットが異なるため、分析に必要な情 報が得られないケースがあった ◦ オンボーディング負荷の軽減 ▪ チーム異動時に移動先のテストケースフォーマットを キャッチアップする必要がなくなった
26. テストケースフォーマット • テストケースの項目 / レイアウトを作成しました ◦ 環境、Evidence、確認手順、期待結果等、テストケースに必要な 項目とレイアウトを標準化 ▪ ただしチームごとに必要な情報は異なるので必要な項目は 各チームでの追加を許容 ◦ 項目を英語化 ▪ English speakerの方もいるため、一部を英語化
27. テストケースフォーマット • テストケースに必要なシートを作成しました ◦ 構成 ▪ テストケースシート ▪ バグ一覧シート • 集計効率化のため、テスト実施期間中に検出した不具合を記 載 ▪ 自動テスト結果シート • 自動テストを実施した場合に結果を記載 ▪ テスト結果集計シート • 後ほど紹介 ▪ チェックリスト • 後ほど紹介
28. テスト結果集計 • 主な目的 ◦ 結果集計を必須とすることで各チームの品質状況の把握の効 率化 ◦ 一定のルールに沿った集計結果シートを予め作成することで 品質報告書の作成を効率化
29. テスト結果集計 テストケースの結果に使用する種別を OK,NG,Resolved,対象外,保留の５つとしました • OK ◦ テストが想定した結果となった場合に使用 • NG ◦ テストが想定した結果とならなかった場合に使用 • Resolved ◦ NGだった項目が改修されて想定した結果となった場合に使用 • 対象外 ◦ 仕様変更等によりテストケースが不要となった場合に使用 • 保留 ◦ 不具合等によりテストケースの実施が出来ない場合に使用 特にNGだったテストケースが OKになった際の記載方法がチームごとに異なっていたため、 Resolvedを使うルールとしました
30. テスト結果集計 テスト結果において集計する項目を「総項目数」,「実施対象項目数」,「OK」,「NG」,「Resolved」,「対象外」,「保留」,「進 捗率」,「完了率」,「残項目数」の１０項目としました • 総項目数 ◦ テストケースの全項目数を集計 • 実施対象項目数 ◦ 実施対象となる項目数を集計 ▪ 総項目数 -対象外数 • OK / NG / Resolved / 対象外 / 保留 ◦ それぞれの件数を集計 • 進捗率 ◦ 着手済みのテストケース数を集計 ▪ (OK数 + NG数 + RESOLVED数 + 保留数) / 実施対象項目数 • 完了率 ◦ 完了したテストケース数を集計 ▪ (OK数 + RESOLVED数 + 対象外数 ) / 総項目数 • 残項目数 ◦ テストケースの残項目数を集計 ▪ 総項目数-(OK数 + RESOLVED数 + 対象外数 )
31. テスト結果集計 テスト結果集計が行われていなかったり、進捗率の集計方法が違った りということがありましたが、今回標準化したルールを使用することとし ました
32. 運用プロセス • 目的 ◦ 今回定めたテストケースフォーマットおよびテスト結果集計のルールを正しく運 用するために運用プロセスを定義 • 内容 ◦ テスト実施中に検出した不具合はバグ一覧シートにまとめる ◦ 自動テストの結果を自動テスト結果シートに記載する　
33. 運用プロセス • 内容 ◦ 運用が正しく行われているかを確認するため、チェックリストを作成 テスト完了時にこのチェックリストにチェックをつけるルールとし、決めたルールに沿ってテ ストケースフォーマットが運用されているかの確認を行うような形にしました。
34. まとめ • 良かったこと ◦ テストケース設計の効率化 ▪ フォーマットが用意されているのでフォーマットを考える工数が減り、テスト観点出し等の別作業 に、より集中できるようになったとの意見があった ◦ テストケースレビューの効率化 ▪ 当初の目的はテストケース実施時の効率化でしたが、フォーマットが統一されていることでレ ビューも効率化されたという意見もあった ◦ 進捗状況が把握しやすくなった ▪ テスト結果集計シートを必ず作ることにしたため、進捗状況はそのシートをみれば把握できるよう になった ※今までは集計シートがない場合、各シートの集計欄を見る必要があった ◦ チーム移動時のオンボーディング工数が削減（？） ▪ まだチーム移動が行われるようなケースが少ないので、何とも言えないですが削減されるは ず！　
35. まとめ • 苦労したこと ◦ 全ての要求を満たすテストケースフォーマットを作るのは難しい ▪ もらったFBをすべてテストケースフォーマットに反映するのではなく、共 通化すべき内容なのかをチームで議論し必要なものだけを反映
36. まとめ 今回のテストケースフォーマット標準化プロジェクトを通じて思わぬ効果も ありました • QAチーム内でのコミュニケーションの活性化 QAメンバーは各Productチーム配属になっているため、意識的に行わないと QAメンバー 同士であまりコミュニケーションをとる機会がなかったり、ひとつのことに一緒に取り組むこ とがなかなかない状況でした。 この取り組みはQAチーム内のひとつの施策としてproject化されたため、アサインされたメ ンバーで議論したりすることでQAチーム内でのコミュニケーションが活性化されるきっかけ になりました。
37. おわりに 今見えている課題と今後取り組んでいきたいことを紹介します • 課題 ◦ 全チームへの浸透 ▪ 多くのチームで使ってもらうことで得られるFBを参考にしながら、改善を繰り 返してよりよいフォーマットを作っていく • 今後取り組んでいきたいこと ◦ テスト結果報告書の自動作成（効率化） ▪ テストケースフォーマットや集計結果が標準化されたことでテスト結果報告書 に必要な情報はある程度収集されるようになった ▪ テスト完了したタイミングで収集した情報を元にテスト結果報告書が自動で作 成したい