テスト自動化のアプローチ 
 　～範囲別の採用ツールと手法 
 2024/11/22
 テスト自動化エンジニア勉強会　 
 ～各社の取り組みや課題から学ぶ会～ 
 エムスリー株式会社　城本　由希 
 1 

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

今日話すこと、メインターゲット 3 ＜話すこと ＞ 1. E2Eテストツール導入時の 課題とアプローチ 2. API自動化時の課題と アプローチ 3. まとめ ＜メインターゲット＞ ● テスト自動化に興味のある人 ○ 特に課題毎にアプローチを 検討している人 3 

エムスリーのQAチームの立ち位置 4 開発 エンジニア QA エンジニア 自分 組織横断のQAチームに所属 担当サービスがBIR 4 

E2Eテスト自動化ツール 導入時の 課題とアプローチ 図はgihyo.jpの和田卓人氏の「サバンナ便り ～ソフトウェア開発の荒野を生き抜く～」 第5回「テストピラミッド 」よりお借りしました。強調箇所はこちらで付けています。 5 

やりたいこと テストをガンガン回したい 開発を高速に安心して進めたい 6 6 

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

E2Eテストでカバーしたい範囲 8 マイクロサービス① マイクロサービス② マイクロサービス③ テストしたい範囲（ユースケースで通る範囲） 

検討内容と狙い 検討：2020当時広まりつつあったローコードツールで解決できないか？ 狙い： ● 課題の解消 ○ ローコードツールのため、QAチームのメンバー全員が扱える ■ Webブラウザの操作のレコードでテストケース作成が可能 ■ 自前で実行用の環境を準備する必要がない ● mablの標準機能でカバーできる範囲が広がる ○ 簡単なスモークテストやVRTを実施する機能がついており、リンク切れな どの検知は自動で行える 9 9 

アプローチ：スモールトライアル まずは担当チーム（BIR）でトライアル開始 ● ペアプロ的な対応 ○ 1~2ケース一緒に作れば初めて使うメンバーもすぐ使い始められる ● できる感覚をつかんでもらう ○ 体感では7~8割程度がレコーディングしたとおりに動かせる ○ GUIからwaitやassertionの追加ができる。IF文やFOR文も可能 テスト対象システムが自動化と相性の良いものであれば レコーディングとGUIで自動テストケースが作成可能！ 10 10 

参考：mablの実際の画面 11 ブラウザの操作を一連の ステップとして記録 waitやassertionの追加も GUIからできる 11 

アプローチ：全体への拡大 1チーム（BIR）で成功体験を積んでから他チームへ拡大 ● 複数チームで運用を行うためのルール作り ○ 命名規則やクラウド実行タイミングのルール整備 ● 質問しやすい場の整備 ○ 週一の勉強会や自動テスト関連のSlackチャンネル 現在は利用チームが7チームに拡大 mablであれば自動テストに対応できるメンバーが増えた 12 12 ※こちらの記事でも詳しく紹介しておりますのでご覧ください 「mabl Experience'23で「複数チームでmablを活用する際の課題と対応」について話しました 」 

mabl導入の結果 13 テストをガンガン回したい 開発を高速に安心して進めたい 当初の狙いは概ね達成 アプローチ中のチームや 運用課題対応中のチームもある。 が、そこは次の課題が 出てきたと考えている 13 

APIテスト自動化時の 課題とアプローチ 図はgihyo.jpの和田卓人氏の「サバンナ便り ～ソフトウェア開発の荒野を生き抜く～」 第5回「テストピラミッド 」よりお借りしました。強調箇所はこちらで付けています。 14 

やりたいこと テストをガンガン回したい 開発を高速に安心して進めたい 15 

背景：テスト自動化の状況（2022） 背景(1)プロジェクト状況 リニューアルプロジェクトが始まる 大きいサービスからパーツを分けてマイクロサービス化 （パーツのINPUT、OUTPUTに変更はない） →大きいサービスの毎週の定期リリースから外れた →都度リリースができるようになりPDCA回しやすくなった リグレッション機会が増える 16 16 

背景：テスト自動化の状況（2022） 背景(2)自動テストのカバー状況 ● モバイルアプリは自動テストがない ● PC/SPのWebアプリはmabl他でカバーされている 背景(3)リソース状況 ● 通常のリリース向けのテストの実施も必要 ● 担当のQAはコーディングにも積極的に取り組む姿勢アリ 17 17 

APIテストでカバーしたい範囲 ※理解あってるか確認してから図は直します 18 18 

APIテストでカバーしたい範囲 19 19 m3.com 基盤系 API群 各サービス群 テストしたい範囲 簡略化したイメージ API API API …… サービス サービス サービス …… 

検討内容と狙い 検討：APIテストでカバーできないか 狙い： 背景(1)プロジェクト状況 →自動テストを整備し、増えたリグレッションテストの回数に対応したい 背景(2)自動テストのカバー状況 →自動テストでカバーできる範囲を増やしたい 背景(3)リソース状況 →外部仕様に変更ないものはEngが自動テストを回すことで 　QAリソースの逼迫を防ぐ 　メンテナンスをEng、QA双方ができるようにする 20 20 

補足 「外部仕様に変更ないものは Engが自動テストを回すことで 　QAリソースの逼迫を防ぐ」について 21 事前にテスト実施について以下のルールを定めていた ● QAチームによるテストが必要なもの ○ 仕様自体の変更 ○ ロジックに変更が入ったもの　など ● 開発Engによるテストでよいもの ○ 外部仕様に変更がないもの ■ 非機能ライブラリ等のマイナーアップデートなど ○ 軽い変更 ■ 文言のみ、閾値のみの変更など 21 

アプローチ 仮説：APIテストで背景に挙げたことに対応できるのではないか 状況のおさらい： 外部仕様に変更はなく、APIを一個ずつ置き換えていく ＝変更前後でAPIのINとOUTが変わらなければOK 対応：まずはscenarigoを使用して1案件実施 　　　→APIテストを自動化する方向で解決しそうという実感を得る　 　　　→その後runnに置き換えて対象範囲拡大 　　　（チュートリアルが整っていて導入しやすい） 22 22 scenarigoについてはこちらで詳しく 紹介しておりますのでどうぞ 「API テスト事始め ーテストツールscenarigoを添えてー」 

アプローチの結果どう変わったか Before：自動テスト整備前は手動テスト 　　　　（所要0.5人日程度） After：（事前の相談） 　　　自動テストのpass 　　　Slackワークフローで完結 　　　(テスト実施の実働が短縮) 23 23 

APIテスト導入の結果 24 テストをガンガン回したい 開発を高速に安心して進めたい 当初の狙いは概ね達 成 （まだ運用中チームは少ない ので拡大予定） 24 

まとめ ● やりたいこと「システムテストをガンガン回したい」「開発を高速に安心して 進めたい」に対して、範囲別に2つのアプローチをとった ○ E2Eテストはローコード自動化サービスの mabl ○ インテグレーションテストは APIテストツールのrunn ● 当初の狙いとしては概ね達成。新しく出てきた課題に対応しようとしている 25 25 

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