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

エムスリーで mablを導入して1年経過時の成果や課題をまとめました。

Transcript

1. ローコードツールを用いて チーム全員で自動テスト導入 -mabl で自動テスト- エムスリー株式会社 窪田 純士
2. • 自己紹介 • エムスリーでの自動テスト導入の歴史 • 自動テスト運用での問題点 • mabl 導入の取り組み • 今後の課題
3. 自己紹介
4. 自己紹介 QA エンジニア @ エムスリー株式会社 窪田 純士（@kubota_junshi） • クリニック・患者向けプロダクトの品質保証を担当 • QA チームリーダーとして日々働いています かれこれ、10年程度 QA やってます
5. 自動テスト導入の歴史
6. 自動テスト導入の歴史 エムスリー自動テストの歴史は 2014年位から 2014 旧 Selenium IDE を用いてスタート 2015〜2016 拡大期 Jenkinsなどのスケ ジュール実行はこ の頃から 2017〜 退職や仕事量の変 化によりメンテナン スが問題化 2021〜 mabl等の検討開始 より詳しい情報はこちら https://speakerdeck.com/jkubota/emusurifalsetesutozi-dong-hua-false-li-shi-tokorekara
7. 自動テスト運用の問題点
8. 自動テスト運用の問題点 よくある問題点 • 自動テストが何故か失敗する（バグなのか単なる失敗なのか） • システムの変更により自動テストが壊れる • 自動テストに時間がかかる • 専任メンテナーが少ない
9. 自動テスト運用の問題点 よくある問題点 • 自動テストが何故か失敗する（バグなのか単なる失敗なのか） • システムの変更により自動テストが壊れる • 自動テストに時間がかかる • 専任メンテナーが少ない 上記に伴う問題点 • 壊れたテストが壊れたまま放置されている • テスト内容が古くあまり意味のないテストが残っている ◦ やっても意味がないので自動テストを動かさない QAチームでは この2つが大問題
10. メンテナー不足の問題 • SET人材の獲得がそもそも難しい ◦ 人員が少ない＋付加価値の高い人材 • QA人材でコードをバリバリ書ける人がそもそも少ない ◦ テスト業務が忙しくなると書ける人でも手を動かせない
11. メンテナー不足の問題 • SET人材の獲得がそもそも難しい ◦ 人員が少ない＋付加価値の高い人材 • QA人材でコードをバリバリ書ける人がそもそも少ない ◦ テスト業務が忙しくなると書ける人でも手を動かせない 対応案としては • QA含め全メンバーにメンテナンス方法を覚えてもらいメンテナンスする • QAメンバーがメンテナンスしやすい方法（ローコードツールなど）を導入する ◦ ちょうど流行り始めて興味を持ってくれている人も多い
12. メンテナー不足の問題 • SET人材の獲得がそもそも難しい ◦ 人員が少ない＋付加価値の高い人材 • QA人材でコードをバリバリ書ける人がそもそも少ない ◦ テスト業務が忙しくなると書ける人でも手を動かせない 対応案としては • QA含め全メンバーにメンテナンス方法を覚えてもらいメンテナンスする • QAメンバーがメンテナンスしやすい方法（ローコードツールなど）を導入する ◦ ちょうど流行り始めて興味を持ってくれている人も多い ◦ 色々比較した結果、 mabl を導入することに
13. mabl とは Web ブラウザアプリ向けの E2E 自動テストクラウドサービス • ブラウザ上で操作すると、操作を記録し自動テストを作成してくれる • AI を用いた自動修復等の機能あり（便利） • 有料の便利機能がある ◦ VRT ◦ リンク切れ ◦ 見やすいテストレポート • テスト実行回数に限度がある ◦ 機能を制限した場合、上限なくテストを実行できる
14. なぜ mabl だったのか mabl 以外にもローコードのテストツールはいくつかあるが …… • プロキシ設定ができる（エムスリーでは重要） ◦ mabl link を用いたプライベートネットワークとのスムーズな接続ができた • 利用例の Web 検索結果が比較的豊富にある ◦ 調べながらすすめることが多いので重要 • チャットなどを通じて問題解決に導いてくれた ◦ 試用期間中に様々な問い合わせをしており、迅速に回答をもらえた
15. mabl 導入の取り組み
16. mabl 導入の前に • 自動テストを推進するメンバーが非常に限られていた ◦ 当初は selenium の自動テストをメンテナンスできるメンバーのみで進めていた ▪ 既存の自動テストのメンテナンスがメイン ▪ 進捗確認や方針相談は殆どなされていなかった ◦ テストが壊れたら担当メンバーに丸投げの状態 • 自動テストを推進するチームを明確に定めた ◦ 定期的な進捗確認、自動テスト大方針の相談の実施 ◦ 自動テスト導入を検討しているチームのメンバーを推進メンバーに加えて情報共有 ▪ 最終的には各チーム代表一人 、全メンバーが自動テスト担当ができるように改革
17. mabl 導入の前に • 自動テスト導入理由を全体で共有できていなかった ◦ あったら便利という認識は共有できていたがそれ以上はなかった • 自動テストが無いことによるデメリットをまとめチーム内共有を実施 ◦ 人員不足による手動テスト着手遅れ ◦ 手動テスト実施期間の現状まとめ 「自動テスト導入を皆で進める」「現状の課題を解決したい」の意識を共有するところからスタート
18. mabl 導入のおおまかな流れ 1. 全体向けの mabl レクチャー会を mabl の方に依頼 2. テスト導入対象のピックアップと導入順序を検討 3. テストケース作成 4. 自動テストをmabl を用いて作成 5. 実際にテスト運用 6. 運用の評価
19. 全体向けの mabl レクチャー会を mabl の方に依頼 mabl の方が基本操作の方法をレクチャーしてくれる機会があったため、 QAメンバーで有志を募りレクチャー会 を実施 - 導入予定のあるチームのメンバーはほぼ強制的に参加 - 何もわからない→なんとなくわかるの状態になるのはかなり重要 mabl では独学用の多くの教材も用意してくれているためそれらも参考になる
20. テスト導入対象のピックアップと導入順序を検討 まずは以下に該当するシステム・サービスを優先的に mabl の導入対象にした • 自動テスト未導入のシステム ◦ 既存自動テストの運用は概ね機能しているため、自動テスト適用範囲を増やす方針 • 変更が殆どないシステムではなく、現在も変更が入っている重要なシステム • 上記の中で比較的に実装が容易そうなものを最初に実装 ◦ 導入の初期に手っ取り早く成功体験が欲しかった ◦ 素早い実装を繰り返して簡単な失敗を早く経験しノウハウの蓄積を早めにしたかった
21. テストケース作成 大方針：全動作を網羅的に作らず、必要最小限になるように作成 • 各サービスで必ず成功してほしいユースケースをテストケースにする ◦ シナリオテストと命名 ◦ 逆に言うと不具合があったときにビジネスインパクトが大きいケースをピックアップ • 上記を除く部分で、細かい部分の確認 ◦ 追加テストと命名 ◦ 上記には含まれないがビジネスインパクトが多少あるもの
22. 自動テストをmabl を用いて作成 いくつかの方針を定めて作成した • 週に1回メンバーを集めてライブでテスト作成を実施し喋 りながらテストを作成する ◦ 週1で 必ずmabl を起動してテスト作成の時間を作る ◦ ゆるく相談しつつ試行錯誤、情報共有を実施する • QA 業務の合間に作業をする ◦ 全員で自動テストを実施できるかの検証も兼ねて ▪ 1年程度運用してみて今は大丈夫
23. 自動テストをmabl を用いて作成 いくつかの方針を定めて作成した • 週に1回メンバーを集めてライブテスト作成を実施し喋り ながらテストを作成する ◦ 週1で 必ずmabl を起動してテスト作成の時間を作る ◦ ゆるく相談しつつ試行錯誤、情報共有を実施する • QA 業務の合間に作業をする ◦ 全員で自動テストを実施できるかの検証も兼ねて ▪ 1年程度運用してみて今は大丈夫 この活動が結構うまくいき チーム全員で自動テスト作成がで きるように Tips の共有がスムーズに行われた
24. 実際にテスト運用 以下の方針に従い、運用を実施 • 重要なテスト（シナリオテスト）はこわれたら即修正 • それ以外のテストはリリースまでに修正 • mabl のクラウド実行（課金対象）を中心に運用 ◦ ローカル実行（実行回数無制限）は都度手元で確認用
25. 運用の評価 良かった点 • 全員で自動テストを作成、修正、実行が問題なくできる • 大規模リニューアルがない限り業務の合間に問題なく自動テストメンテナンスできる ◦ 大体全体作業の 5〜10％程度の労力 課題点 • 初期の計画が甘かったため、課金対象の実行上限に早々に到達した ◦ 定期実行はローカル実行（無課金）に変更 ◦ リリース前のテストのみクラウド実行（課金対象） • 上記からCIへの組み込み戦略がまだ立てられていない ◦ ローカル実行をCIに組み込み予定 • テスト環境に不安定さがあり、テストが若干不安定 ◦ 現在は失敗箇所の再実行 or 手動再実行で運用
26. mabl を導入して良かった点 • QA 依頼が気軽にできるようになった ◦ テスト実施工数が大幅に減ったので、気軽にリファクタリングができるようになった • それなりにバグ検出ができている • 自動テストを実施するためにテスタビリティを高くする活動が増加した ◦ 自動テストをうまく動かすために APIの追加などを依頼、手動テストの効率化にもつながる • 手動テスト効率化にもつながっている ◦ データを用意するのが非常に面倒な手動テストのデータを自動で用意することが可能に
27. 苦労したポイント • mabl ツール自体がそれなりに重い • 初期は各チーム自由に作成し不便な面があった ◦ テスト名、テストスイート名等の命名規則を作った • 類似した共通処理（JavaScript のスニペット）の乱立 ◦ 上記同様命名規則設定で一旦回避 • 安定して動かないテストはやはりある ◦ mabl のクラウドサービスの性能が結構良いので操作が早すぎ る等 これらは早々に問題になったため全体ルー ルを早めに作成した • テスト名 • ラベル名 • アプリケーション名　等 ex. Unit名_サービス名_テスト対象機能_実施 操作
28. 自動テストの浸透状況（抜粋） チーム mabl 導入前 導入後 A チーム 3サービス 4サービス B チーム 2サービス 2サービス C チーム 1サービス 13サービス D チーム 1サービス 1サービス（mabl でリプレイス） E チーム 1サービス 12サービス 本格導入をして半年、各チームで自動テストを拡大することが出来た
29. 今後の課題
30. 今後の課題 • 実行時間が長い ◦ シナリオが長くなりすぎであるため、テスト実行時間がかかっている ◦ テストケースの縮小と高速化の工夫を現在検討中 • CI を整えきれていないため、今後方針含めて検討が必要 ◦ cli の tips を城本がブログにまとめていますのでよろしければ ▪ https://www.m3tech.blog/entry/mabl_cli_tips • native app には完全に未対応 直近の活動のブログもあります。よろしければ。 https://www.m3tech.blog/entry/mabl_operation