こんにちは！ エムスリーエンジニアリンググループ QAチームの城本（@yuki_shiro_823）です。普段は担当しているBIR（Business Intelligence and Research）チームで品質向上のためにあれこれしています。
本記事はmablのカレンダー | Advent Calendar 2023 - Qiitaの5日目の記事です。 先日行われたmabl Experience'23で「複数チームでmablを活用する際の課題と対応」と題して登壇してきました。 今回はその内容をかいつまんで紹介します。
mabl Experienceとは
テスト自動化SaaSであるmablの年次カンファレンスです。mabl社のCo-FounderであるIzzy Azeri氏による今後のmablの展開の話や、ユーザー企業によるmablの活用事例などが紹介されました。エムスリーでもmablを導入しており今は複数チームでの活用が進んでいるため、当社での活用事例について紹介してきました。
mabl大学では、mablの基本的な使い方をご覧いただけます！
— mabl Japan (@mabljp) November 22, 2023
複数チームでのmabl 活用について by @yuki_shiro_823 様
mabl大学はこちら: https://t.co/3KERTbBNPE pic.twitter.com/V3PS7n53bQ
発表のサマリ
発表してきた「複数チームでmablを活用する際の課題と対応」の内容を軽く紹介します（詳しくは当日の資料をご覧ください）
前提
エムスリーの一部のプロダクトでは、手動テストがボトルネックになっていたり、自動テストケースのメンテナンスが一部のメンバーに集中してしまっているといった課題がありました。QAチームではこの課題を解決すべく、テスト自動化SaaSであるmablを導入にチャレンジしていました。
導入初期の話は以前書いているので興味のある方はこちらも合わせてご覧ください。
複数チームでの展開
導入勉強会の実施
よくあるテスト自動化ツール導入の失敗事例として、導入したツールを扱えるエンジニアが限られてしまい、結局テストケースがメンテナンスされなくなるという話があると思います。 これでは、先に書いた「テストケースのメンテナンスが一部のメンバーに集中してしまう」という課題が解決できません。
そこでまずエムスリーQAチームでは、全体での勉強会を実施しました。 全員でmablの説明を聞いた上で、mablを実際に触る会です。 さらにSalckチャンネルや週一の有志の勉強会など、QAチームメンバーで気軽に質問できる場を設けました。なるべく全員が関わるように実装と運用を進めた結果として、全体でmablを活用できそうな感触を得ることができました。
社内からも良い声が聞こえてきており、堅実に進める事が重要だったなと振り返って思います。
複数チームでの活用で出てきた課題と対策
複数チームで運用する上で2つの課題が出てきました。
- 設計を各自で自由に進めた結果管理が難しくなった
- 契約単位でクラウド実行回数が決まっているため全体の実行回数を把握する必要が出てきた
設計を各自で自由に進めた結果管理が難しくなった
最初は特にルールを定めず運用していたため、似たような名前のテストケースができてしまう等の問題が出てきました。対応として命名規則や作成ルールなど、いくつかの決まりを定めています。以前の記事で紹介してますので、詳しくはこちらをどうぞ！
契約単位でクラウド実行回数が決まっているため全体の実行回数を把握する必要が出てきた
こちらについての対応は、「現状のクラウド実行回数を各チームで算出し、リリース頻度と証跡が必要性に応じてクラウド実行する回数を大まかに決めた。ローカル実行で問題ないものはローカル実行という整理も合わせて行った」というものになります。
前提として、mablの実行環境はクラウドとローカルの2種類があります。クラウドはAIを活用したオートヒーリングやテストケースの実行順序の指定など様々な便利機能が使えますが、実行回数は契約で上限が決まっています。一方ローカル環境だとクラウドで提供されている便利機能が使えなかったり、mabl CLIのコマンドではテストケースの実行順序が指定できません。ただ大きなメリットとして、実行回数は無制限です。
クラウド実行回数を分ける前提として、mablでは契約している実行回数のうち今何回使用しているかと月の実行予測数を表示する画面はあります。ただ2023/11時点では、それをチームごとに分けたりフィルタして表示する機能はなく、自分のチームがどのくらい使っているのか把握できませんでした。
そこでまず現状で各チームが何回程度使っているのか、近い未来で何回程度使う予定かを手動計測で大雑把に出しました。*1
各チームの回数を出した後、E2E自動テストを作成している主なメンバーで行うミーティングで実行回数を調整しました。ここで決めたことは、クラウド実行はリリース前の確認や証跡が必要なプロジェクトを優先し、ローカル実行でも問題ないものはローカル実行で行うということです。
実行回数の調整後はしばらくモニタリングを行い、算出した実行予想数から大幅に乖離していないかを確認していました。実行環境の整理方針を決めて、各チームが自分のチームのクラウド実行タイミングとおよその実行回数を把握したこともあって、大きな乖離は今までに発生していません。
感想
発表はオンラインで多くの方が聞いてくださったようでありがたかったです。複数チームでの運用については、他の会社でも同様の問題を抱えている方がいらっしゃるようで「参考になる」とのコメントをいただきました。同じ悩みの方に届いたようで幸いです。 また、他の方の発表でもmablの活用の仕方や、自動テストの作成・メンテナンスをどう行うかなどの参考になるお話が聞けてためになりました。mablからの発表でも生成AIによるオートヒーリングなど気になるWordが飛び出しており楽しみです。
We're hiring
QAチームでは自動テストを活用しながら、協力してリードタイムを短縮したいエンジニアを募集しています。 社会に役立つシステムを高品質で素早く届けたいQAエンジニアの方、一緒に働きませんか？ カジュアル面談でより詳しくお話ししましょう！
*1:一部実装が必要ですが、mablのレポーティングAPIを利用して出す方法もあります。
mablのアプリケーション毎の実行回数をレポーティングAPIで取得する - カカクコムTechBlog
こちらのコードで取れるのは実行回数2000回までと教えていただきました。
