複数の開発チームによるmabl活用とQAの関わり方 / 株式会社カカクコム QAスペシャリスト 伊藤由貴

複数の開発チームによる mabl活用とQAの関わり方 公開版 2024/11/20 mabl Experience 2024 Japan 株式会社カカクコム QAスペシャリスト 伊藤由貴 1

発表の概要 n mablを活用する、組織内で利用を広めていくための 取り組みと事例についてご紹介 l 複数チームでの共同利用、かつ開発者が中心に利用している組織では どのような工夫をしているのか l QAエンジニアが品質保証を組織に根付かせる上で mablをどのように活用しているのか 2

目次 1. はじめに 2. mabl導入の背景と利用状況 3. 複数の開発チームで活用するための工夫 4. 品質保証を根付かせるために 5. 事例 6. 課題 7. まとめ 3

自己紹介：伊藤由貴（いとうよしき） n 仕事の経歴 l 2012 ~ 2022 株式会社ベリサーブにて 主にシステムテスト自動化の推進 l 2023 ~ 株式会社カカクコムにて 部門一人目のQAエンジニアとして 複数開発チームへの横断QA活動実施中 n 社外の活動 l JSTQB AL テスト自動化エンジニアシラバス翻訳 l テストツールまるわかりガイド改訂 l TechTeamJournal ライター l Sqripts スクリプター n X：@yoshikiito 4

会社概要：株式会社カカクコム 5

6

目次 1. はじめに 2. mabl導入の背景と利用状況 3. 複数の開発チームで活用するための工夫 4. 品質保証を根付かせるために 5. 事例 6. 課題 7. まとめ 7

mabl導入の背景 n 手動テストが中心で、自動テストで効率化したい n 一部でSelenium等を導入していたが、 メンテナンスの手間が大きく辛い n 長く続いているサービスゆえにレガシーな部分もあり、 一部ユニットテストを書くのが困難 まずは（現実的にできる）E2Eテストから始め、 他のテストレベルへと広げていこうと考えた 詳細はFindy Tools | mablの導入効果をレビューでご紹介(YoshikiIto-株式会社カカクコム) 8

• https://findy-tools.io/products/mabl/2/18

カカクコムでの利用状況の概要 n 時期：2022/8~ （トライアル含） n プラン：Enterprise 3K n 主な利用部門：価格.com4チーム、その他4チーム n 用途：主にブラウザテスト l APIテスト、アクセシビリティは一部のみ n テストの実行タイミング l 週に1〜2回の定期実行 l デプロイ前後 などチーム毎にさまざま 9

参考：月間実行回数の推移（価格.com以外含） 3000 2633 【訂正】 誤（発表時）：620 正：1730 2500 2917 2810 2749 2551 2500 2427 2466 2441 2423 2340 2288 1950 2000 1901 1730 1500 1000 804 500 370 180 209 -1 0 20 24 -0 9 20 24 -0 8 20 24 -0 7 20 24 -0 6 24 20 20 24 -0 5 -0 4 20 24 -0 3 20 24 -0 2 20 24 -0 1 20 24 -1 2 20 23 -1 1 20 23 -1 0 20 23 -0 9 20 23 -0 8 20 23 -0 7 20 23 -0 6 20 23 -0 5 23 20 20 23 -0 4 0 10

開発組織の構成とQAの立ち位置 100名弱 開発チーム1-A 開発部1 価格.com 開発本部 … 開発部2 開発チーム1-B QAの立ち位置 • 各部・チームに対して広く浅く テスト等の活動を支援 開発部3 • デザイン部１ 開発チーム3-A デザイン部２ 開発チーム3-B イネイブリングチーム テストの実務を担うのではなく、 テストプロセス整備や技術移転を行う QA(私) QA 11

開発チーム主体で自動テストを運用中 QAエンジニア • 全体に関わる運用 各開発チーム • 自動テストの利用全般 • 実行回数のウォッチ • テストの作成・修正 • mabl Link関連 • プラン作成 • mabl社とのやりとり • 実行結果の確認 • 導入・利用サポート • デモ・ハンズオン • Fail時の調査 など • 困ったときに技術調査 など ※mablで行うチームのほか、OSSで行うチームも。 12

目次 1. はじめに 2. mabl導入の背景と利用状況 3. 複数の開発チームで活用するための工夫 4. 品質保証を根付かせるために 5. 事例 6. 課題 7. まとめ 13

複数の開発チームで並用する際の問題 n ワークスペースやリソースの共有 l 実行回数：どのくらい使っていい？空きはある？ l フロー、スニペット等：どれを使っていい？自チーム専用はOK？ n 導入可否や導入の流れ l 制限があると聞いたけど使っていいの？ l 誰に言えば・何をすれば使えるの？ n ツール自体の理解 l そもそもどんなツールなの？何ができるの？ 14

mablを活用するための取り組み １ ハンズオンやサンプルシナリオの実装と提供 n 自動テストを運用に載せるまでのハードルを下げる ２ 手続きやルールの整備、利用状況可視化 n 自動テスト以外の周辺部分をQA側で担う 15

①ハンズオン、サンプルシナリオの提供 n 利用希望チームには必ずハンズオンを行い、 目的や対象となるテスト、想定実行ボリュームなどを確認し 一緒に導入検討 n 導入時にはQA側でサンプルシナリオを作成・提供するなど、 スタート時点でのつまづきポイントを排除 16

②手続きやルール整備、利用状況可視化 n 複数チームで使う際の運用ルールを整備＆ドキュメント化 l 利用開始時の手続き l フローやテスト、プラン等の命名規則 n 日々の各チームの利用状況を可視化 l Teamsに投稿し、ユーザー全員が 見られる状態 17

目次 1. はじめに 2. mabl導入の背景と利用状況 3. 複数の開発チームで活用するための工夫 4. 品質保証を根付かせるために 5. 事例 6. 課題 7. まとめ 18

mabl推進による成果・・・？ n たくさんのE2Eテストを自動化できた l 2024/10時点でmablには250以上のテストが存在 n 実行回数を増やすことができた l 毎月2000回以上のクラウド実行が回っている 19

自動テストを進めるうえでの疑問 たくさんのテストを自動化をすればよい たくさん実行すればよい しかし 開発チームが主体となって行う場合に、 最初から「ちょうどよい自動テスト」ができる？ 20

まずは小さくやってみる n 開発者自身でmablを使い、E2Eテストの自動化と運用を体感 l どんな粒度で作ればいいの？ l どんな頻度で動かせばいいの？ l そもそもテストで何を確かめれば？ などの疑問が生まれる n 疑問に対してQAが一緒に考えつつ、 ビジネスに影響する「大きな失敗」をしないようにサポート 21

疑問・課題から品質向上の取り組みへ mablによるテスト自動化を、品質向上について 考え取り組むためのキッカケとして（も）利用。 E2Eテストの 範囲と目的の 明示 ・・・ 効果的な E2Eテスト ・・・ 高品質な サービスを 安定して提供 各テストレベル の責務を明示 環境やSUTの テスタビリティ 22

例：テスト全体を構造化し、mablが担う範囲を合意 参考：部門1人目のQAとして入社1年間でやったこと 23

• https://kakaku-techblog.com/entry/qa-activities-2023

目次 1. はじめに 2. mabl導入の背景と利用状況 3. 複数の開発チームで活用するための工夫 4. 品質保証を根付かせるために 5. 事例 6. 課題 7. まとめ 24

mabl利用事例 製品詳細ページリニューアル n 開発中＆リリース後のリグレッションテスト 価格.com保険 n 日常的に行うリグレッションテストの自動化 25

事例：製品詳細ページリニューアル n プロジェクトの概要 l スマートフォン向けの製品詳細ページのリニューアル • と言ってもデザイン変更だけ、簡単、というものではなく・・・ 詳しくは以下ブログ記事もご覧ください。 最恐の技術的負債に挑むリニューアルプロジェクト 26

• https://kakaku-techblog.com/entry/renewal-project-summary

事例：製品詳細ページリニューアル 参考：2025年3月期第1四半期̲決算説明資料 P19 27

• https://ssl4.eir-parts.net/doc/2371/tdnet/2483688/00.pdf

事例：製品詳細ページリニューアル n mabl利用目的 l 開発中およびリリース後のリグレッションテストを自動化 • デザイン部門や企画部門などによる変更可能性があった • リリース後も細かな変更やBugFixなどが発生しそうだった l せっかくなのでこの機会に使ってみよう n 進め方 l 開発チーム全員に対してmablのハンズオン l 開発・QAそれぞれでシナリオを検討し自動化 28

事例：製品詳細ページリニューアル n シナリオ検討時のイメージ 必須の導線や クリティカルな部分を 開発チームと相談・合意 シナリオ数自体は 最小限に （他のテストレベルでカバー） 29

事例：製品詳細ページリニューアル n 自動テスト運用による効果 l 基本導線について日次でテストを実施できている l 実績 • 他チームの改修によって内部のAPIに問題が起こっていたことを検知 • デザインチームの改修影響による機能不備（＆連携不足）を検知 など 30

mabl利用事例 製品詳細ページリニューアル n 開発中＆リリース後のリグレッションテスト 価格.com保険 n 日常的に行うリグレッションテストの自動化 31

事例：価格.com保険 n mabl利用目的 l リグレッションテストの範囲と頻度の向上 • mabl導入以前から内製の自動テストツールで結合テスト相当を実施していたが、 システムテストは手動かつ新規開発・改修部分が中心だった n 進め方 l 開発チーム全員に対してmablのハンズオン l 開発チームでシナリオを検討し自動化 • QA側は最初DataTableまわりなど複雑なところを作ってお渡ししつつ、 後半はほぼノータッチ l 運用も基本的に開発チームのみで実施中 32

事例：価格.com保険 n 開発チーム側でのmabl運用の工夫 l 結果確認＆失敗原因調査担当者を週ごとにローテーション l チームのナレッジベースに情報をまとめる mablでの自動テストを属人化させず、 チームの全員が自動テストの作成・運用ができる状態に 33

目次 1. はじめに 2. mabl導入の背景と利用状況 3. 複数の開発チームで活用するための工夫 4. 品質保証を根付かせるために 5. 事例 6. 課題 7. まとめ 34

今後の課題 n 効果的な自動テストのシナリオおよび運用へ l mablで自動テストを作って運用できる開発者は増えた。 次は、回している自動テストが効果的なものになるよう、 場合によってはシナリオや実行頻度を減らす等の対応を行う n オンプレの開発環境での安定性向上 l mabl link agentを用いて自動テストを行っているが、 本番に向けたクラウド実行と比べて不安定になりがち 35

目次 1. はじめに 2. mabl導入の背景と利用状況 3. 複数の開発チームで活用するための工夫 4. 品質保証を根付かせるために 5. 事例 6. 課題 7. まとめ 36

まとめ n 複数開発チームで活用するための工夫 l ハンズオンやサンプルシナリオ提供など手厚く、ルール等土台整備 n 品質保証を根付かせるために l E2E自動テストの導入をきっかけに開発チームと課題感を共有し、 品質向上のためにやるべきこと、につなげていく 37

ご参考 n カカクコムTechBlog ‒ mabl カテゴリ l チーム内での導入や、QA側での工夫など記事化しています 38

• https://kakaku-techblog.com/archive/category/mabl

以上 ありがとうございました！ 39