$30 off During Our Annual Pro Sale. View Details »

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

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

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

Junshi Kubota

December 03, 2022
Tweet

More Decks by Junshi Kubota

Other Decks in Technology

Transcript

  1. 自動テスト導入の歴史 エムスリー自動テストの歴史は 2014年位から 2014 旧 Selenium IDE を用いてスタート 2015〜2016 拡大期

    Jenkinsなどのスケ ジュール実行はこ の頃から 2017〜 退職や仕事量の変 化によりメンテナン スが問題化 2021〜 mabl等の検討開始 より詳しい情報はこちら https://speakerdeck.com/jkubota/emusurifalsetesutozi-dong-hua-false-li-shi-tokorekara
  2. 自動テスト運用の問題点 よくある問題点 • 自動テストが何故か失敗する(バグなのか単なる失敗なのか) • システムの変更により自動テストが壊れる • 自動テストに時間がかかる • 専任メンテナーが少ない

    上記に伴う問題点 • 壊れたテストが壊れたまま放置されている • テスト内容が古くあまり意味のないテストが残っている ◦ やっても意味がないので自動テストを動かさない QAチームでは この2つが大問題
  3. メンテナー不足の問題 • SET人材の獲得がそもそも難しい ◦ 人員が少ない+付加価値の高い人材 • QA人材でコードをバリバリ書ける人がそもそも少ない ◦ テスト業務が忙しくなると書ける人でも手を動かせない 対応案としては

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

    • QA含め全メンバーにメンテナンス方法を覚えてもらいメンテナンスする • QAメンバーがメンテナンスしやすい方法(ローコードツールなど)を導入する ◦ ちょうど流行り始めて興味を持ってくれている人も多い ◦ 色々比較した結果、 mabl を導入することに
  5. mabl とは Web ブラウザアプリ向けの E2E 自動テストクラウドサービス • ブラウザ上で操作すると、操作を記録し自動テストを作成してくれる • AI

    を用いた自動修復等の機能あり(便利) • 有料の便利機能がある ◦ VRT ◦ リンク切れ ◦ 見やすいテストレポート • テスト実行回数に限度がある ◦ 機能を制限した場合、上限なくテストを実行できる
  6. なぜ mabl だったのか mabl 以外にもローコードのテストツールはいくつかあるが …… • プロキシ設定ができる(エムスリーでは重要) ◦ mabl

    link を用いたプライベートネットワークとのスムーズな接続ができた • 利用例の Web 検索結果が比較的豊富にある ◦ 調べながらすすめることが多いので重要 • チャットなどを通じて問題解決に導いてくれた ◦ 試用期間中に様々な問い合わせをしており、迅速に回答をもらえた
  7. mabl 導入の前に • 自動テストを推進するメンバーが非常に限られていた ◦ 当初は selenium の自動テストをメンテナンスできるメンバーのみで進めていた ▪ 既存の自動テストのメンテナンスがメイン

    ▪ 進捗確認や方針相談は殆どなされていなかった ◦ テストが壊れたら担当メンバーに丸投げの状態 • 自動テストを推進するチームを明確に定めた ◦ 定期的な進捗確認、自動テスト大方針の相談の実施 ◦ 自動テスト導入を検討しているチームのメンバーを推進メンバーに加えて情報共有 ▪ 最終的には各チーム代表一人 、全メンバーが自動テスト担当ができるように改革
  8. mabl 導入のおおまかな流れ 1. 全体向けの mabl レクチャー会を mabl の方に依頼 2. テスト導入対象のピックアップと導入順序を検討

    3. テストケース作成 4. 自動テストをmabl を用いて作成 5. 実際にテスト運用 6. 運用の評価
  9. 全体向けの mabl レクチャー会を mabl の方に依頼 mabl の方が基本操作の方法をレクチャーしてくれる機会があったため、 QAメンバーで有志を募りレクチャー会 を実施 -

    導入予定のあるチームのメンバーはほぼ強制的に参加 - 何もわからない→なんとなくわかるの状態になるのはかなり重要 mabl では独学用の多くの教材も用意してくれているためそれらも参考になる
  10. 自動テストをmabl を用いて作成 いくつかの方針を定めて作成した • 週に1回メンバーを集めてライブでテスト作成を実施し喋 りながらテストを作成する ◦ 週1で 必ずmabl を起動してテスト作成の時間を作る

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

    ◦ ゆるく相談しつつ試行錯誤、情報共有を実施する • QA 業務の合間に作業をする ◦ 全員で自動テストを実施できるかの検証も兼ねて ▪ 1年程度運用してみて今は大丈夫 この活動が結構うまくいき チーム全員で自動テスト作成がで きるように Tips の共有がスムーズに行われた
  12. 運用の評価 良かった点 • 全員で自動テストを作成、修正、実行が問題なくできる • 大規模リニューアルがない限り業務の合間に問題なく自動テストメンテナンスできる ◦ 大体全体作業の 5〜10%程度の労力 課題点

    • 初期の計画が甘かったため、課金対象の実行上限に早々に到達した ◦ 定期実行はローカル実行(無課金)に変更 ◦ リリース前のテストのみクラウド実行(課金対象) • 上記からCIへの組み込み戦略がまだ立てられていない ◦ ローカル実行をCIに組み込み予定 • テスト環境に不安定さがあり、テストが若干不安定 ◦ 現在は失敗箇所の再実行 or 手動再実行で運用
  13. mabl を導入して良かった点 • QA 依頼が気軽にできるようになった ◦ テスト実施工数が大幅に減ったので、気軽にリファクタリングができるようになった • それなりにバグ検出ができている •

    自動テストを実施するためにテスタビリティを高くする活動が増加した ◦ 自動テストをうまく動かすために APIの追加などを依頼、手動テストの効率化にもつながる • 手動テスト効率化にもつながっている ◦ データを用意するのが非常に面倒な手動テストのデータを自動で用意することが可能に
  14. 苦労したポイント • mabl ツール自体がそれなりに重い • 初期は各チーム自由に作成し不便な面があった ◦ テスト名、テストスイート名等の命名規則を作った • 類似した共通処理(JavaScript

    のスニペット)の乱立 ◦ 上記同様命名規則設定で一旦回避 • 安定して動かないテストはやはりある ◦ mabl のクラウドサービスの性能が結構良いので操作が早すぎ る等 これらは早々に問題になったため全体ルー ルを早めに作成した • テスト名 • ラベル名 • アプリケーション名 等 ex. Unit名_サービス名_テスト対象機能_実施 操作
  15. 自動テストの浸透状況(抜粋) チーム mabl 導入前 導入後 A チーム 3サービス 4サービス B

    チーム 2サービス 2サービス C チーム 1サービス 13サービス D チーム 1サービス 1サービス(mabl でリプレイス) E チーム 1サービス 12サービス 本格導入をして半年、各チームで自動テストを拡大することが出来た
  16. 今後の課題 • 実行時間が長い ◦ シナリオが長くなりすぎであるため、テスト実行時間がかかっている ◦ テストケースの縮小と高速化の工夫を現在検討中 • CI を整えきれていないため、今後方針含めて検討が必要

    ◦ cli の tips を城本がブログにまとめていますのでよろしければ ▪ https://www.m3tech.blog/entry/mabl_cli_tips • native app には完全に未対応 直近の活動のブログもあります。よろしければ。 https://www.m3tech.blog/entry/mabl_operation