ローコード自動化ツールmablの導入と
 うまく利用するためのルールの策定 2023/09/13
 テストパフォーマンス向上のためのテスト戦略〜自動化の秘訣 Lunch LT〜
 エムスリー株式会社　城本　由希
 1 

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

今日話すこと、メインターゲット 3 ＜話すこと＞ 1. mabl導入前の課題 a. テスト自動化の状況や問題点 2. 導入時の体験と挑戦 a. スムーズに行った点 b. ちょっと工夫が必要だった点 3. うまく利用するための社内ルー ル 4. 対応の効果 5. まとめ ＜メインターゲット＞ ● ローコードツールを全社的に使 おうとしている人 

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

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

前提：エムスリーの自動化の歴史 6 ● Selenium IDE導入 ● トライアル 最初期 ● 社内展開 ● テスト増加 成長期 ● メンテナン ス問題 ● Selenium IDEのEOL 停滞期 ● mabl導入 ● BIRでのト ライアル 導入期 ● mablの全 社展開 ● 運用中 成長期2 mabl Selenium playwright etc 見 直 し 

今回の範囲 7 ● Selenium IDE導入 ● トライアル 最初期 ● 社内展開 ● テスト増加 成長期 ● メンテナン ス問題 ● Selenium IDEのEOL 停滞期 ● mabl導入 ● BIRでのト ライアル 導入期 ● mablの全 社展開 ● 運用中 成長期2 mabl Selenium playwright etc 見 直 し 

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

mablとは何か Webブラウザアプリ向けのE2Eテスト自動化クラウドサービス ● 操作をレコードすることによりローコードでテストケース作成が可能 ● AIを活用したオートヒーリングと画面崩れ検知の機能がある ● APIテスト、モバイルWebテストにも対応 9 

mablとは何か 10 ブラウザの操作を一連の ステップとして記録 waitやassertionの追加も GUIからできる 

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

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

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

おさらい：今回の範囲 14 ● Selenium IDE導入 ● トライアル 最初期 ● 社内展開 ● テスト増加 成長期 ● メンテナン ス問題 ● Selenium IDEのEOL 停滞期 ● mabl導入 ● BIRでのト ライアル 導入期 ● mablの全 社展開 ● 運用中 成長期2 mabl Selenium playwright etc 見 直 し 

ちょっと工夫が必要だった点（成長期2の課題） ＜前提＞ 社内には複数チーム存在する mablの利用は1チーム→7チームに拡大 ＜課題＞ 1. どれが自分のチームのものか分からなくなる 2. 人によってコメントの付け方や何をflow（関数）にしているのかが異なる a. 誰でもメンテナンスできるものになっているか 3. レビューはどうするか 15 E2Eテスト自動化サービスmablでテストケースを作成する際のルールを作った話 詳しくはこちらをどうぞ！ 

対応1「命名規則策定」 ＜課題＞ どれが自分のチームのものか分からなくなる ＜対応＞ 命名規則を決めた 「チーム名-サービス名-（テスト対象機能）-（実施操作）」 例：「Unit7_アンケート管理システム_アンケート作成_新規作成」 16 

対応2「作成ルール策定」 ＜課題＞ 人によってコメントの付け方や何をflow（関数）にしているのかが異なる ＜対応＞ ある程度粒度が揃い、メンテナンスしやすくなるよう作成ルールを決めた ● コメントを適宜入れているか ● 実行内容に応じて適切に結果を確認しているか ● 同手順が複数ある場合flow化（関数化）しているか ● 1日に複数回実行可能か　etc 17 

対応3「レビュールール策定」 ＜課題＞ レビューはどうするか ＜対応＞ レビューフロー、ルールを定めた ● テストケース作成者が作成ルールに沿っているかセルフチェック →チーム内でレビューを依頼 ● mablにはブランチ機能がある。大きな修正を加える場合はブランチの使用 を推奨 18 

対応の効果 ● 初めて自動テストのケースを作成するメンバーでも一定のレベルを保って作 成が可能に ● レビューアになると他のメンバーがテストを作成する際に行っている工夫を 知れる（副次的な効果） ＜その他の工夫＞ ● 週一で有志メンバーでmablの勉強会を実施 ○ 他の人が作成したテストケースを眺める →他の人の工夫を知ったり、フィードバックをするいい機会に 19 

今後の取り組み 自動化は今後どのように拡充するのか？ ● mablによるE2Eテスト ○ よりよいメンテナンス ○ よりよい運用方法がないか ○ 長くなっているテストをどう回しやすくしていくか etc ● APIテスト 20 

まとめ ● テスト自動化の推進のため、ローコードテスト自動化サービスのmablを導 入 ● 1チームでのトライアルで成果があった後、社内展開実施。展開にあたり ルールを策定 ○ 命名規則、作成ルール、レビュールール ● ルールにより一定のレベルを保ってmablのテストケースを作成できるように なった 21 

QAエンジニア募集中です！　詳しくはこちらで！ 22 We are hiring!! ご清聴ありがとうございました！