複数チームでmablを活用する際の
 課題と対応 2023/11/22
 mabl Experience
 エムスリー株式会社　城本　由希
 1

自己紹介 ● 城本　由希　@yuki_shiro_823 ● エムスリー株式会社で組織横断のチームであるQAチームに所属 ● 担当はリサーチの部門であるBIRでアンケートの作成や配信などのシステム のQA ● QAエンジニアのスキル向上を目指してQAチーム内の勉強会を開いたり、 ツールの導入・運用を行っている ● 広島出身のカープファン 2

今日話すこと、メインターゲット 3 ＜話すこと＞ 1. 前提 2. 複数チーム展開時の施策 a. 導入 b. 対象のピックアップ c. 定着 d. 運用 3. 出てきた課題 a. 複数での運用 4. まとめ ＜メインターゲット＞ ● ローコードツールを全社的に使 おうとしている人

エムスリーの紹介 4 “インターネットを活用し、 健康で楽しく長生きする人を一 人でも増やし、 不必要な医療コストを一円でも 減らすこと” →　テクノロジーで支援する

エムスリーのQAチームの立ち位置 5 開発 エンジニア QA エンジニア 自分 組織横断のQAチームに所 属し、担当サービスが BIR エムスリーエンジニアリングGの組織構成 エムスリー 経営会議 マネジメントチーム CTO VPoE GL 採用TL エンジニア人事担当 事業チーム （9） 横断チーム （10） Unit1 MR君 Unit4 サイトプロモ Unit6 キャリア Unit9 治験 Unit3 新領域 Unit5 コンシューマ Unit7 BIR SRE マルデバ AI・機械学習 グループ会社 支援 グローバル プロダクト 基盤 2023-11-1時点：101名 採用チーム QA セキュリティ プロダクト 支援 データ基盤 デジスマ デジカル

前提：エムスリーでのテスト自動化の状況や問題点 ● テスト実施、リグレッションに時間がかかっている ○ 一部E2Eテスト自動化に着手できておらず、手動テストで対応 ● 自動テストの作成、メンテナンスが一部の知識のあるメンバーに集中してし まうため全体展開が進みづらい ○ SeleniumやPlaywrightはある程度コードが書ける必要がある ○ 自動実行用の環境にアップデートやメンテに手が回りづらい ツールである程度解決できるのでは？ 6

なぜmablを導入したのか ● 課題の解消 ○ ローコードツールのため、QAチームのメンバー全員が扱える ■ Webブラウザの操作のレコードでテストケース作成が可能 (一部JavaScriptで記述する必要あり） ○ 自前で実行用の環境を準備する必要がない ● mablの標準機能でカバーできる範囲が広がる ○ 簡単なスモークテストやVRTを実施する機能がついており、リンク切れな どの検知は自動で行える まずはBIR（私の担当チーム）で導入開始！ 7

導入時の体験と挑戦　～スムーズに行った点 ● 体感では7~8割程度がレコーディングしたとおりに動かせる ● 1~2ケース一緒に作れば初めて使うメンバーもすぐに使い始められる ● waitやassertionの追加もGUIで提供されている機能で対応できる ○ IF文やFOR文の追加もGUIで可能 テスト対象システムが自動化と相性の良いものであれば レコーディングとGUIで自動テストケースが作成可能 8

ちょっと工夫が必要だった点（導入期の課題） ● 記録したとおりに動かないところもある ○ テーブルのセルの中をクリックしたり、文字入力するUI ○ idやnameがついていない要素 ○ 一部の日付選択のUI ● データを初期化/固定化する必要がある ○ ※テスト自動化につきものの課題であり、mablの問題ではない 9 今回はmablを使うことや自動テストにつ きものの困難な点の対応は省略！ この点の対応はこちらをどうぞ！ mablの導入と開発・QA間の協力体制

複数チームへの展開 10

全体展開時の流れ 1. 全体向けのレクチャー会を mabl の方に依頼 2. テスト導入対象のピックアップと導入順序を検討 3. テストケース作成 4. 自動テストをmabl を用いて作成 5. 実際にテスト運用 6. 運用の評価 11

全体向けのレクチャー会を mabl の方に依頼 mabl の方が基本操作の方法をレクチャーしてくれる機会があったため、QAメン バーで有志を募りレクチャー会を実施 ● 導入予定のチームのメンバーには声をかけて全員に参加してもらう ● mabl では「mabl大学」という自己学習用の教材もあるので活用 12 何もわからない→「なんとなくわかる」の状態になるのはかなり重要！

テスト導入対象のピックアップと導入順序を検討 優先的に mabl を導入する対象のシステムを決めた ● 自動テスト未導入 ○ 既存自動テストの運用は概ね機能しているため、自動テスト適用範囲を 増やす方針 ● 現在も連続的に変更されている ○ 組織としても価値が高い ● mablによるテスト実装が比較的容易である ○ 初期の成功体験と素早いPDCAによるノウハウ蓄積 13

テスト導入対象のピックアップと導入順序を検討 導入順序 1. （全体）自動テスト経験者のいるチーム、人数の多いチームから 2. （チーム内）１の中でも自チーム内で完結するシステムから 3. （チーム内）優先システムに順に実装 後回しにしたもの ● 難易度が高いもの、QAチームで完結しないもの ○ JS実装が必要（書ける人がお手本書いてから他の人も実施） ○ テスト対象側に自動テスト対応の修正が必要 ● チームをまたぐシステム 14

テストケース作成 大方針：全動作を網羅的に作らず、必要最小限になるように作成 ● 各サービスで必ず成功してほしいユースケースをテストケースにする ○ 不具合発生時にビジネスインパクトが大きいケースをピックアップ ● 上記を除く部分で、細かい部分の確認 ○ 上記には含まれないがビジネスインパクトが多少あるもの 15

自動テストをmabl を用いて作成 ● 週に1回メンバーを集めて喋りながらテストを作成する ○ 週1で 必ずmabl を起動してテスト作成の時間を作る ○ ゆるく相談しつつ試行錯誤、情報共有を実施する ● QA 業務の合間に作業をする ○ 全員で自動テストを実施できるかの検証も兼ねた ○ 1年程度運用してみて今は大丈夫 16

実際にテスト運用 以下の方針に従い、運用を実施 ● 重要なテスト（シナリオテスト）は壊れたら即修正 ● それ以外のテストはリリースまでに修正 ● mabl のクラウド実行（課金対象）を中心に運用（※2021年当時） ○ ローカル実行（実行回数無制限）は都度手元で確認用 17

運用の評価 良かった点 ● 全員で自動テストを作成、修正、実行が問題なくできる ● 大規模リニューアルがない限り業務の合間に問題なく自動テストメンテナン スできる（大体全体作業の5〜10％程度の労力） 課題点 ● 初期の計画が甘かったため、課金対象の実行上限に早々に到達した ○ 定期実行はローカル実行（無課金）に変更 ○ リリース前のテストのみクラウド実行（課金対象） ● 実行結果に不安定さがあり、テストが若干不安定（原因調査中） 18

複数チームでの利用時の課題 19

課題 ● 各チームが自由に作りすぎた ● 有限のクラウド実行回数をチーム間でどう分ける？ （追加料金がかからない範囲で実行回数をおさめたい） 20

各チームが自由に作りすぎた ＜課題＞ 1. どれが自分のチームのものか分からなくなる 2. コメントの付け方や何をflow（関数）にするのか人 により異なる 3. レビューはどうするか 21 私の作った ログインフロー どれだっけ？ 良くない例

各チームが自由に作りすぎた ＜課題＞ 1. どれが自分のチームのものか分からなくなる 2. コメントの付け方や何をflow（関数）にするのか人により異なる 3. レビューはどうするか ＜対応＞ 1. 命名規則を作成した 例「チーム名-サービス名-（テスト対象機能）-（実施操作）」 2. 作成ルールを定めた 3. レビューフロー、ルールを決めた 22 E2Eテスト自動化サービスmablでテストケースを作 成する際のルールを作った話 詳しくはこちらをど うぞ！

有限のクラウド実行回数をチーム間でどう分ける？ ＜課題＞ 契約内容によりクラウド実行回数には上限がある。 チーム間でこの回数をうまく分配する必要があるがどうするか？ ＜補足・前提＞ ● 月の実行回数はサマリで見れるが、ワークスペースの合計数である ○ チームごとに数を出したりフィルタする機能はない ● 実行上限を超えると従量課金になるが、それは避けたい （自動テストのメリットとコストのいい感じのバランスをとりたい） 23

24 有限のクラウド実行回数をチーム間でどう分ける？ Workspace全体の実行回数と 予想回数は出る チームごとには分けられない

25 有限のクラウド実行回数をチーム間でどう分ける？ ケース増やす予定 あるけど大丈夫？

有限のクラウド実行回数をチーム間でどう分ける？ ＜チームごとの実行数がわからない点への対応案＞ ● チームごとにワークスペースを分ける ● API等で自動で取得するよう実装する ● 正確さは求めないので手動で集計する 26

有限のクラウド実行回数をチーム間でどう分ける？ ＜チームごとの実行数がわからない点への対応案＞ ● チームごとにワークスペースを分ける 　　→正確な実行数がわかる。有料。他チームの実行数は分からない。 ● API等で自動で取得するよう実装する 　　→正確な実行数がわかる。実装コストはかかるが作ってしまえば無料 　　　（ただ当時この方法を知らなかった） ● 正確さは求めないので手動で集計する 　　→正確な数は不明。直近の実装計画も合わせれば実行予測が出せる 27

有限のクラウド実行回数をチーム間でどう分ける？ ＜やったこと＞ 1. （各チーム）手動で現状のケース数と月の実行予想数を出す a. 実装の計画済みのチームは、今後半年程度の実行予想数も出す 2. （MTG）合計数が実行上限内に収まるか確認する（調整） a. リリースサイクルを考慮、リリース前はなるべくクラウド実行 b. ローカル実行でもよいものはローカル実行に変更する 3. （MTG）運用して実行数との大きな乖離がないか確認 28 現状では予想数との大きなズレや、上限を超えることは起こっていない

各チームの現状のケース数、月の実行予想数を出す 29 チーム サービス 4月 5月 6月 7月 Unit1 サービスA 200 210 220 225 サービスB 100 100 100 100 サービスC 100 100 100 100 Unit2 250 250 250 250 Unit3 150 150 150 150 Unit4 100 100 100 100 Unit5 0 0 15 30 合計 900 910 935 955 実行予想数一覧サンプル

（MTG）合計数が実行上限内に収まるか確認する ＜前提＞ 週に一度、各チームの自動テスト推進担当が集まるMTGを設定している ＜実行回数について決めたこと＞ ● 前提として、実行回数の上限は超えたくない ● ローカル環境とクラウド環境の使い分け ○ 証跡を残したいところを優先 ● クラウドで失敗したケースは一度ローカルで確認 ○ まずはローカルで失敗原因を切り分ける 30

補足：ローカル実行とクラウド実行 31 CLIで実行（ローカル環境） クラウド実行（クラウド環境） 利用目的 完成したテストを通しで実行したいと きや、CI/CD連携する場合等 ローカルで成功したテストの最終確 認や定期実行用 実行の契機 テストの動作確認や開発途中の確認 等 デプロイ時やリリース前の確認等 メリット ● ヘッドレスブラウザ指定で動作が 高速 ● ローカルのCIに組み込めばいくら でも定期実行可能 ● クロスブラウザ、オートヒール、ス クリーンショット等 ● 定期実行の場合、パフォーマンス ログ等もすべて保存 デメリット クラウドで可能なクロスブラウザ、 オートヒール等が動かない ● コンテナ起動などで動作が遅い ● 実行回数がカウントされる mablヘルプページの mablの実行方法と実行環境の違いはなんですか より抜粋

補足：エムスリーでの運用 環境の使い分け 32 ローカル実行 ● 定期実行（チームごとにタイミ ングは異なる） ● 開発中など気軽に実行したい とき ● 失敗したテストの再実行や修 正確認 クラウド実行 ● リリース前 ● 証跡を残しておきたいシステ ム

（MTG）運用して実行数との大きな乖離がないか確認 ＜定期MTGでの確認内容＞ ● 実行回数のモニタリング ○ 実行数が予想を大きく超えていることがあれば原因確認＆是正 ■ 実装中にトライ＆エラーを繰り返して予想を大きく超えたことがあった ● テスト自動化の進捗確認 ○ 実装中のところは進捗、運用中のところは大きな問題がないか ● 困りごとや、問題の共有／相談（MTGで解決しない場合はmablへ問い合わ せることもある） 33

今後の取り組み 自動化は今後どのように拡充するのか？ ● mablによるE2Eテスト ○ よりよいメンテナンス ○ よりよい運用方法がないか ○ 長くなっているテストをどう回しやすくしていくか etc ● APIテスト ○ 一部のチームで取組中のものを各チームに普及させたい 34

まとめ ● テスト自動化の推進のためローコードテスト自動化サービスのmablを導入 ● 1チームでのトライアルで成果があった後、社内展開実施 ● 定着に向け勉強会などの施策を実施 ● 複数チームで運用するための課題にも対応実施／対応中 ○ 作成・レビュールールの策定 ○ クラウド実行回数の予測とモニタリング ○ クラウド実行、ローカル実行の方針整理 35

ぜひフォローよろしくお願いします！ 36 エムスリーの公式Xはこちら！！ ご清聴ありがとうございました！