ローコードツールを用いてチーム全員で自動テスト導入 -mabl で自動テスト-

by Junshi Kubota

Slide 1

Slide 1 text

ローコードツールを用いてチーム全員で自動テスト導入 -mabl で自動テスト- エムスリー株式会社窪田純士

Slide 2

Slide 2 text

● 自己紹介 ● エムスリーでの自動テスト導入の歴史 ● 自動テスト運用での問題点 ● mabl 導入の取り組み ● 今後の課題

Slide 3

Slide 3 text

自己紹介

Slide 4

Slide 4 text

自己紹介 QA エンジニア @ エムスリー株式会社窪田純士（@kubota_junshi） ● クリニック・患者向けプロダクトの品質保証を担当 ● QA チームリーダーとして日々働いていますかれこれ、10年程度 QA やってます

Slide 5

Slide 5 text

自動テスト導入の歴史

Slide 6

Slide 6 text

自動テスト導入の歴史エムスリー自動テストの歴史は 2014年位から 2014 旧 Selenium IDE を用いてスタート 2015〜2016 拡大期 Jenkinsなどのスケジュール実行はこの頃から 2017〜退職や仕事量の変化によりメンテナンスが問題化 2021〜 mabl等の検討開始より詳しい情報はこちら https://speakerdeck.com/jkubota/emusurifalsetesutozi-dong-hua-false-li-shi-tokorekara

Slide 7

Slide 7 text

自動テスト運用の問題点

Slide 8

Slide 8 text

自動テスト運用の問題点よくある問題点 ● 自動テストが何故か失敗する（バグなのか単なる失敗なのか） ● システムの変更により自動テストが壊れる ● 自動テストに時間がかかる ● 専任メンテナーが少ない

Slide 9

Slide 9 text

自動テスト運用の問題点よくある問題点 ● 自動テストが何故か失敗する（バグなのか単なる失敗なのか） ● システムの変更により自動テストが壊れる ● 自動テストに時間がかかる ● 専任メンテナーが少ない上記に伴う問題点 ● 壊れたテストが壊れたまま放置されている ● テスト内容が古くあまり意味のないテストが残っている ○ やっても意味がないので自動テストを動かさない QAチームではこの2つが大問題

Slide 10

Slide 10 text

メンテナー不足の問題 ● SET人材の獲得がそもそも難しい ○ 人員が少ない＋付加価値の高い人材 ● QA人材でコードをバリバリ書ける人がそもそも少ない ○ テスト業務が忙しくなると書ける人でも手を動かせない

Slide 11

Slide 11 text

メンテナー不足の問題 ● SET人材の獲得がそもそも難しい ○ 人員が少ない＋付加価値の高い人材 ● QA人材でコードをバリバリ書ける人がそもそも少ない ○ テスト業務が忙しくなると書ける人でも手を動かせない対応案としては ● QA含め全メンバーにメンテナンス方法を覚えてもらいメンテナンスする ● QAメンバーがメンテナンスしやすい方法（ローコードツールなど）を導入する ○ ちょうど流行り始めて興味を持ってくれている人も多い

Slide 12

Slide 12 text

Slide 13

Slide 13 text

mabl とは Web ブラウザアプリ向けの E2E 自動テストクラウドサービス ● ブラウザ上で操作すると、操作を記録し自動テストを作成してくれる ● AI を用いた自動修復等の機能あり（便利） ● 有料の便利機能がある ○ VRT ○ リンク切れ ○ 見やすいテストレポート ● テスト実行回数に限度がある ○ 機能を制限した場合、上限なくテストを実行できる

Slide 14

Slide 14 text

なぜ mabl だったのか mabl 以外にもローコードのテストツールはいくつかあるが …… ● プロキシ設定ができる（エムスリーでは重要） ○ mabl link を用いたプライベートネットワークとのスムーズな接続ができた ● 利用例の Web 検索結果が比較的豊富にある ○ 調べながらすすめることが多いので重要 ● チャットなどを通じて問題解決に導いてくれた ○ 試用期間中に様々な問い合わせをしており、迅速に回答をもらえた

Slide 15

Slide 15 text

mabl 導入の取り組み

Slide 16

Slide 16 text

mabl 導入の前に ● 自動テストを推進するメンバーが非常に限られていた ○ 当初は selenium の自動テストをメンテナンスできるメンバーのみで進めていた ■ 既存の自動テストのメンテナンスがメイン ■ 進捗確認や方針相談は殆どなされていなかった ○ テストが壊れたら担当メンバーに丸投げの状態 ● 自動テストを推進するチームを明確に定めた ○ 定期的な進捗確認、自動テスト大方針の相談の実施 ○ 自動テスト導入を検討しているチームのメンバーを推進メンバーに加えて情報共有 ■ 最終的には各チーム代表一人、全メンバーが自動テスト担当ができるように改革

Slide 17

Slide 17 text

mabl 導入の前に ● 自動テスト導入理由を全体で共有できていなかった ○ あったら便利という認識は共有できていたがそれ以上はなかった ● 自動テストが無いことによるデメリットをまとめチーム内共有を実施 ○ 人員不足による手動テスト着手遅れ ○ 手動テスト実施期間の現状まとめ「自動テスト導入を皆で進める」「現状の課題を解決したい」の意識を共有するところからスタート

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

全体向けの mabl レクチャー会を mabl の方に依頼 mabl の方が基本操作の方法をレクチャーしてくれる機会があったため、 QAメンバーで有志を募りレクチャー会を実施 - 導入予定のあるチームのメンバーはほぼ強制的に参加 - 何もわからない→なんとなくわかるの状態になるのはかなり重要 mabl では独学用の多くの教材も用意してくれているためそれらも参考になる

Slide 20

Slide 20 text

テスト導入対象のピックアップと導入順序を検討まずは以下に該当するシステム・サービスを優先的に mabl の導入対象にした ● 自動テスト未導入のシステム ○ 既存自動テストの運用は概ね機能しているため、自動テスト適用範囲を増やす方針 ● 変更が殆どないシステムではなく、現在も変更が入っている重要なシステム ● 上記の中で比較的に実装が容易そうなものを最初に実装 ○ 導入の初期に手っ取り早く成功体験が欲しかった ○ 素早い実装を繰り返して簡単な失敗を早く経験しノウハウの蓄積を早めにしたかった

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

自動テストをmabl を用いて作成いくつかの方針を定めて作成した ● 週に1回メンバーを集めてライブテスト作成を実施し喋りながらテストを作成する ○ 週1で必ずmabl を起動してテスト作成の時間を作る ○ ゆるく相談しつつ試行錯誤、情報共有を実施する ● QA 業務の合間に作業をする ○ 全員で自動テストを実施できるかの検証も兼ねて ■ 1年程度運用してみて今は大丈夫この活動が結構うまくいきチーム全員で自動テスト作成ができるように Tips の共有がスムーズに行われた

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

運用の評価良かった点 ● 全員で自動テストを作成、修正、実行が問題なくできる ● 大規模リニューアルがない限り業務の合間に問題なく自動テストメンテナンスできる ○ 大体全体作業の 5〜10％程度の労力課題点 ● 初期の計画が甘かったため、課金対象の実行上限に早々に到達した ○ 定期実行はローカル実行（無課金）に変更 ○ リリース前のテストのみクラウド実行（課金対象） ● 上記からCIへの組み込み戦略がまだ立てられていない ○ ローカル実行をCIに組み込み予定 ● テスト環境に不安定さがあり、テストが若干不安定 ○ 現在は失敗箇所の再実行 or 手動再実行で運用

Slide 26

Slide 26 text

mabl を導入して良かった点 ● QA 依頼が気軽にできるようになった ○ テスト実施工数が大幅に減ったので、気軽にリファクタリングができるようになった ● それなりにバグ検出ができている ● 自動テストを実施するためにテスタビリティを高くする活動が増加した ○ 自動テストをうまく動かすために APIの追加などを依頼、手動テストの効率化にもつながる ● 手動テスト効率化にもつながっている ○ データを用意するのが非常に面倒な手動テストのデータを自動で用意することが可能に

Slide 27

Slide 27 text

苦労したポイント ● mabl ツール自体がそれなりに重い ● 初期は各チーム自由に作成し不便な面があった ○ テスト名、テストスイート名等の命名規則を作った ● 類似した共通処理（JavaScript のスニペット）の乱立 ○ 上記同様命名規則設定で一旦回避 ● 安定して動かないテストはやはりある ○ mabl のクラウドサービスの性能が結構良いので操作が早すぎる等これらは早々に問題になったため全体ルールを早めに作成した ● テスト名 ● ラベル名 ● アプリケーション名　等 ex. Unit名_サービス名_テスト対象機能_実施操作

Slide 28

Slide 28 text

自動テストの浸透状況（抜粋）チーム mabl 導入前導入後 A チーム 3サービス 4サービス B チーム 2サービス 2サービス C チーム 1サービス 13サービス D チーム 1サービス 1サービス（mabl でリプレイス） E チーム 1サービス 12サービス本格導入をして半年、各チームで自動テストを拡大することが出来た

Slide 29

Slide 29 text

今後の課題

Slide 30

Slide 30 text

今後の課題 ● 実行時間が長い ○ シナリオが長くなりすぎであるため、テスト実行時間がかかっている ○ テストケースの縮小と高速化の工夫を現在検討中 ● CI を整えきれていないため、今後方針含めて検討が必要 ○ cli の tips を城本がブログにまとめていますのでよろしければ ■ https://www.m3tech.blog/entry/mabl_cli_tips ● native app には完全に未対応直近の活動のブログもあります。よろしければ。 https://www.m3tech.blog/entry/mabl_operation