Slide 1

Slide 1 text

Session Title なめらかなFintech QAを実現するために テストケースフォーマットを標準化した話 Masatoshi Sato Merpay QA Team Yuki Sakamoto Merpay QA Team

Slide 2

Slide 2 text

Masatoshi Sato / @satomasa 第三者検証会社で約 10年、様々なシステムの QAを経 験。その後いくつかの事業会社の QAを経てメルペイに 入社。メルペイでは社内向けの管理画面の QAを主に 担当している。 株式会社メルペイ QA Engineer Yuki Sakamoto / @y-sakamoto ソーシャルゲーム、 WEBサービスのQAを経験し2021 年にメルペイ入社。主に督促、回収に関わる領域や WEB領域のQAを担当している。 株式会社メルペイ QA Engineer

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

前置き ● QAの対象がいろいろ ○ Backend,Frontend,Client, … ● QAのプロセスもいろいろ ○ テストケースを作らずにチケット上に確認したことを記載してテスト完了す るケースがあった ● 各Productチームの体制や状況もいろいろ ○ アサインされたチームの状況によって、各メンバーが工夫しながらテスト ケースを進化させていた テストケースのフォーマットがチームごとあるいはメンバーごとによっても違う状態に なっていました

Slide 5

Slide 5 text

前置き 例えば ● アサインチーム変更時のオンボーディングコストが高い ○ 移動したチームのテストケースに慣れる必要がある ● 品質状況の把握するために必要な情報の取得が難しい ○ テスト実施時に検出した不具合が管理されていない ○ チームごとにテスト結果の記載方法が違う テストケースのフォーマットが標準化されていない状態が続くことで、い くつかの課題がみえるようになってきていました

Slide 6

Slide 6 text

前置き ● QA完了時のテスト結果報告書を作成する際に工数がかかってい た ○ テスト結果の集計がされていない(わかりづらい)、まとまって いない等の理由により、QA完了後に改めてテスト結果を集計 する必要があった

Slide 7

Slide 7 text

前置き このような課題を解決するために テストケースフォーマット標準化プロジェクト が立ち上がりました

Slide 8

Slide 8 text

テストケースフォーマット標準化に向けて ● プロジェクト方針の決定 ● 現状の各チームのテストケースフォーマットの調査 ● ドキュメント作成 ● trialの実施 ● ver1.0のリリース ● 運用 それぞれ、取り組んだ内容について簡単に説明します

Slide 9

Slide 9 text

テストケースフォーマット標準化に向けて ● プロジェクト方針の決定 ● 現状の各チームのテストケースフォーマットの調査 ● ドキュメント作成 ● trialの実施 ● ver1.0のリリース ● 運用

Slide 10

Slide 10 text

プロジェクト方針の決定 テストケースフォーマット標準化に向けて、プロジェクトの方針を決めま した。 決めたことはいろいろありますが、一部を紹介します。

Slide 11

Slide 11 text

プロジェクト方針の決定 ● どこまでフォーマットを標準化するか ○ 最低限のルールだけ決めて、それぞれのチームである程度自由に変更 ができるようなフォーマットにする 当初はこの方針としていたのですが、後に方針を変更しました ● 変更後の方針 ○ 固定化フォーマットを作る ● 理由 ○ 各チームのテストケースを見比べたところ、意外とフォーマットに違いがな かった ○ 自由度が高いと、結局バラバラになってしまい目的を達成できないリスク がある

Slide 12

Slide 12 text

プロジェクト方針の決定 ● プロジェクトの活動方針について ○ weeklyでmtg(1h)を開催 ■ この時間で進捗の共有だけでなく、プロジェクトの作業を 行う時間とした ● 理由 ○ 通常のQA業務と並行して、このプロジェクトに関 する作業を行うので予め作業時間を確保すること が目的 ● 効果 ○ プロジェクトの業務が停滞することがなかった

Slide 13

Slide 13 text

テストケースフォーマット標準化に向けて ● プロジェクト方針の決定 ● 現状の各チームのテストケースフォーマットの調査 ● ドキュメント作成 ● trialの実施 ● ver1.0のリリース ● 運用

Slide 14

Slide 14 text

現状の各チームのテストケースフォーマットの調査 まず、各チームの代表的なテストケースを集め(約10種類)、 メンバーで比較を行いました 比較した結果、 ● 各チームでいろいろなテストケースのフォーマットが使用されている ● 基本的な部分についてはあまり違いがない ということが分かり、テストケースフォーマット標準化に向けてどうやって 標準化していくべきかが何となく見えてきました

Slide 15

Slide 15 text

テストケースフォーマット標準化に向けて ● プロジェクト方針の決定 ● 現状の各チームのテストケースフォーマットの調査 ● ドキュメント作成 ● trialの実施 ● ver1.0のリリース ● 運用

Slide 16

Slide 16 text

ドキュメント作成 今回のプロジェクトで作成したドキュメント ● テストケースフォーマット ○ 別途、使い方やルール等をドキュメント化 ● テスト結果集計 ○ 別途、使い方やルール等をドキュメント化 ● 運用プロセス それぞれのドキュメントについての詳細は後ほど説明します

Slide 17

Slide 17 text

テストケースフォーマット標準化に向けて ● プロジェクト方針の決定 ● 現状の各チームのテストケースフォーマットの調査 ● ドキュメント作成 ● trialの実施 ● ver1.0のリリース ● 運用

Slide 18

Slide 18 text

trialの実施 ドキュメント作成が一通り終わったタイミングで、作成したルールやフォーマットが運 用に耐えうるかを試すためにtrial期間を設けました。 1. 新しいフォーマットを試していただくチームを募集 2. 運用してみて気づいたことや改善してほしいことをFBシートに記載 3. FBシートに記載された内容を確認し、必要に応じてドキュメントを更新 trial期間でいくつかFBを受け、修正した点はありましたが運用上大きな問題は発生 しないことが分かったため、ver1.0のリリースに向けてさらにドキュメントの精度をあ げていくことになりました。

Slide 19

Slide 19 text

テストケースフォーマット標準化に向けて ● プロジェクト方針の決定 ● 現状の各チームのテストケースフォーマットの調査 ● ドキュメント作成 ● trialの実施 ● ver1.0のリリース ● 運用

Slide 20

Slide 20 text

ver1.0のリリース trial期間で出たFBを経て、いくつかの修正をしてver1.0としてリリースしました。ただ全 チームで一斉に新しいフォーマットやルールを適用する事はできないため、キリの良い タイミングで新しいフォーマットへの移行をお願いする形としました。 プロジェクト立ち上げ:2022/12 ver1.0のリリース:2023/4 ver1.0のリリースまで5ヶ月ほどかかったが、何とかリリースすることができました。

Slide 21

Slide 21 text

ver1.0のリリース

Slide 22

Slide 22 text

テストケースフォーマット標準化に向けて ● プロジェクト方針の決定 ● 現状の各チームのテストケースフォーマットの調査 ● ドキュメント作成 ● trialの実施 ● ver1.0のリリース ● 運用

Slide 23

Slide 23 text

運用 運用フェーズでもFBシートを用意して、実際に使ってみて感じた改善点や疑問/不明 点を書いてもらっています。 運用フェーズでもweeklyのmtgは継続しており、FBシートに新しいFBの記載があれ ばその場でメンバーで議論し、改善が必要な点はドキュメントも更新していく形をとっ ています。

Slide 24

Slide 24 text

本プロジェクトで作成したドキュメントについて 今回のプロジェクトで作成したドキュメントについて、それぞれ説明します ドキュメントの構成 テストケースフォーマット 標準化 テストケースフォーマット フォーマット ドキュメント(ルール等を記載) テスト結果集計 フォーマット ドキュメント(ルール等を記載) 運用プロセス ドキュメント(ルール等を記載)

Slide 25

Slide 25 text

テストケースフォーマット ● 目的 ○ 品質分析の効率化 ■ チームごとにフォーマットが異なるため、分析に必要な情 報が得られないケースがあった ○ オンボーディング負荷の軽減 ■ チーム異動時に移動先のテストケースフォーマットを キャッチアップする必要がなくなった

Slide 26

Slide 26 text

テストケースフォーマット ● テストケースの項目 / レイアウトを作成しました ○ 環境、Evidence、確認手順、期待結果等、テストケースに必要な 項目とレイアウトを標準化 ■ ただしチームごとに必要な情報は異なるので必要な項目は 各チームでの追加を許容 ○ 項目を英語化 ■ English speakerの方もいるため、一部を英語化

Slide 27

Slide 27 text

テストケースフォーマット ● テストケースに必要なシートを作成しました ○ 構成 ■ テストケースシート ■ バグ一覧シート ● 集計効率化のため、テスト実施期間中に検出した不具合を記 載 ■ 自動テスト結果シート ● 自動テストを実施した場合に結果を記載 ■ テスト結果集計シート ● 後ほど紹介 ■ チェックリスト ● 後ほど紹介

Slide 28

Slide 28 text

テスト結果集計 ● 主な目的 ○ 結果集計を必須とすることで各チームの品質状況の把握の効 率化 ○ 一定のルールに沿った集計結果シートを予め作成することで 品質報告書の作成を効率化

Slide 29

Slide 29 text

テスト結果集計 テストケースの結果に使用する種別を OK,NG,Resolved,対象外,保留の5つとしました ● OK ○ テストが想定した結果となった場合に使用 ● NG ○ テストが想定した結果とならなかった場合に使用 ● Resolved ○ NGだった項目が改修されて想定した結果となった場合に使用 ● 対象外 ○ 仕様変更等によりテストケースが不要となった場合に使用 ● 保留 ○ 不具合等によりテストケースの実施が出来ない場合に使用 特にNGだったテストケースが OKになった際の記載方法がチームごとに異なっていたため、 Resolvedを使うルールとしました

Slide 30

Slide 30 text

テスト結果集計 テスト結果において集計する項目を「総項目数」,「実施対象項目数」,「OK」,「NG」,「Resolved」,「対象外」,「保留」,「進 捗率」,「完了率」,「残項目数」の10項目としました ● 総項目数 ○ テストケースの全項目数を集計 ● 実施対象項目数 ○ 実施対象となる項目数を集計 ■ 総項目数 -対象外数 ● OK / NG / Resolved / 対象外 / 保留 ○ それぞれの件数を集計 ● 進捗率 ○ 着手済みのテストケース数を集計 ■ (OK数 + NG数 + RESOLVED数 + 保留数) / 実施対象項目数 ● 完了率 ○ 完了したテストケース数を集計 ■ (OK数 + RESOLVED数 + 対象外数 ) / 総項目数 ● 残項目数 ○ テストケースの残項目数を集計 ■ 総項目数-(OK数 + RESOLVED数 + 対象外数 )

Slide 31

Slide 31 text

テスト結果集計 テスト結果集計が行われていなかったり、進捗率の集計方法が違った りということがありましたが、今回標準化したルールを使用することとし ました

Slide 32

Slide 32 text

運用プロセス ● 目的 ○ 今回定めたテストケースフォーマットおよびテスト結果集計のルールを正しく運 用するために運用プロセスを定義 ● 内容 ○ テスト実施中に検出した不具合はバグ一覧シートにまとめる ○ 自動テストの結果を自動テスト結果シートに記載する 

Slide 33

Slide 33 text

運用プロセス ● 内容 ○ 運用が正しく行われているかを確認するため、チェックリストを作成 テスト完了時にこのチェックリストにチェックをつけるルールとし、決めたルールに沿ってテ ストケースフォーマットが運用されているかの確認を行うような形にしました。

Slide 34

Slide 34 text

まとめ ● 良かったこと ○ テストケース設計の効率化 ■ フォーマットが用意されているのでフォーマットを考える工数が減り、テスト観点出し等の別作業 に、より集中できるようになったとの意見があった ○ テストケースレビューの効率化 ■ 当初の目的はテストケース実施時の効率化でしたが、フォーマットが統一されていることでレ ビューも効率化されたという意見もあった ○ 進捗状況が把握しやすくなった ■ テスト結果集計シートを必ず作ることにしたため、進捗状況はそのシートをみれば把握できるよう になった ※今までは集計シートがない場合、各シートの集計欄を見る必要があった ○ チーム移動時のオンボーディング工数が削減(?) ■ まだチーム移動が行われるようなケースが少ないので、何とも言えないですが削減されるは ず! 

Slide 35

Slide 35 text

まとめ ● 苦労したこと ○ 全ての要求を満たすテストケースフォーマットを作るのは難しい ■ もらったFBをすべてテストケースフォーマットに反映するのではなく、共 通化すべき内容なのかをチームで議論し必要なものだけを反映

Slide 36

Slide 36 text

まとめ 今回のテストケースフォーマット標準化プロジェクトを通じて思わぬ効果も ありました ● QAチーム内でのコミュニケーションの活性化 QAメンバーは各Productチーム配属になっているため、意識的に行わないと QAメンバー 同士であまりコミュニケーションをとる機会がなかったり、ひとつのことに一緒に取り組むこ とがなかなかない状況でした。 この取り組みはQAチーム内のひとつの施策としてproject化されたため、アサインされたメ ンバーで議論したりすることでQAチーム内でのコミュニケーションが活性化されるきっかけ になりました。

Slide 37

Slide 37 text

おわりに 今見えている課題と今後取り組んでいきたいことを紹介します ● 課題 ○ 全チームへの浸透 ■ 多くのチームで使ってもらうことで得られるFBを参考にしながら、改善を繰り 返してよりよいフォーマットを作っていく ● 今後取り組んでいきたいこと ○ テスト結果報告書の自動作成(効率化) ■ テストケースフォーマットや集計結果が標準化されたことでテスト結果報告書 に必要な情報はある程度収集されるようになった ■ テスト完了したタイミングで収集した情報を元にテスト結果報告書が自動で作 成したい

Slide 38

Slide 38 text

No content