[mablers_JP]Ubieでのmablユースケース 〜メトリクスを添えて〜

mabl experience '22 の再演と情報のアップデート、最近取り組んだテスト実行数の可視化についての発表です

Transcript

1. Ubieでのmablユースケース 〜メトリクスを添えて〜 01 / 08 / 2023
2. 2 はじめに - お話する内容はmablユーザー向けです - 過去の登壇、発表内容と重複する箇所があります - mablのEnterpriseプランでしか使えない機能について触れます - なるべく質問には回答するよう努めますが、テスト対象のシステムや事業についての詳細な説明は控えさせ ていただきます。 2
3. 3 自己紹介 - 2021年1月に入社。 - Ubieのプロダクト開発組織で QAエンジニアをやっています。 - テストをしたり、mabl/MagicPodの管理者をやったり、採用をやったり - 訳あって、mablユーザー歴3年以上 - twitter @tmasuhara 3
4. 4 導入経緯 4
5. 5 導入時の状況 - 求められるリリースサイクルが非常に早い - 毎営業日何らかリリースしている - 自動テストの仕組みを短期間で整備する必要があった - 自動テストのシステムを自前で構築して、メンテをするようなポジションの人がいない - プロダクトチームの業務をしつつ、テストを整備・メンテしていく必要あり 5
6. 6 Why mabl? - 過去に利用経験があり、求められるユースケースに fitしそうだった - mablがダメだったら他を検証すれば良い 6
7. 7 現状の利用状況 7
8. 8 現在の利用状況(2023/08/01現在) - test数 - 105 - test runs/month - 多め - flow数 - 106 8
9. 9 mablを効果的に利用し続け るためにやっていたこと 9
10. 10 プロダクト/チームのメトリクスの一つにする - mablのデータをBQに連携 - 特定のラベルがついた testsの実行結果がみれる redash dashboardを作成 - ミーティングで実行状況を毎週チェック - 落ちたテストについて、何か手を打つべきかの確認を PO/ENGがいる場でする - mablがプロダクト運用の一部であるという共通認識を維持できている - 今後生産性観点でもダッシュボード作成、メトリクスを作る予定 10
11. 11 現在は運用停止 - redashのグラフだけ見ても「？」 - production実行でテストが落ちていたらすぐに slackのメンションが来て対応している - あるスクラムチームでは、 projectの開始・終了時にmablの実装完了やoffにする対応をjiraのタスクにして管 理している 11
12. 12 mabl導入がUbieにもたらし た変化 12
13. 13 QA以外の開発者の積極的な参加 - もともとUbieは品質に興味を持っている人が多い - mablには多くの人が参加しやすい機能が整っている - アカウント増による請求増がない - slackやBQなど開発・運用に関わるツールとの連携機能が標準で整っている - ↑のおかげで様々なコラボレーションが生まれた 13
14. 14 Testing in Production - プロダクトメトリクスに影響を与えず、本番環境でもテストを回したい - SRE,BI等関係者で連携して、結果的には mabl側は少量のflow変更で対応できた 14
15. 15 独自slack integration - いつのまにかできていた - テスト結果とPRへのリンク、コミッターのメンションが通知されて、修正時のコミュケーションが効率的になった 15
16. 16 乗り越えた課題 16
17. 17 知らない間にフロントエンドのフレームワークが変わってた事件 - 2021年のGW前後にいきなり変わる - なぜかauto-healingがうまく効かなくて、泣きながら testを修正 17
18. 18 unified test runner beta版で調子に乗りすぎて請求額爆発事件 - 業務委託さんが出勤時にローカルで回していた自動テストを mablに移植してテスト数が増加 - unified test runnerがbetaだったのでガンガン使いまくる - unified test runner正式リリース -> 実行数が界王拳 - 真面目に契約とtest数を見直し - 課金爆発を心配する人が結構いた - ^を払拭するために、先を考えた余裕のある実行上限数を設定。周知 18
19. 19 最近良かったmablの リリース 19
20. 20 最近良かったmablのリリース 去年だけど。 - branch機能の改修 - testの修正はしておきたいけど、リリースタイミングがすぐではない場合等に大活躍 - 実例) testの修正は自分でやっておいて、開発者に「本番リリース前に mablのこのbranchマージしてく ださい。ダメだったら slackでメンションしてください」 - マージ前にmaster取り込み、コンフリクト解消 - 複数人でのtest編集は昔は心配だったが、現在はかなり良くなってる認識 20
21. 21 今後mablに期待したいこと 21
22. 22 settings/usageページ（月の実行数がみれるページ）の改良 - 組織内でのmablの利用状況をもう少し詳細に把握したい - 現状だと、workspace内トータルでのテスト実行回数しかわからない - プロダクトや環境別で絞りこめると、担当外プロダクトの mabl利用状況がわかりそう - 今後の契約変更を考える判断材料を増やしたい 22
23. 23 flow関連機能の改善 - flowを含めたstepの塊を扱いたい - datatableでflowとパラメータが使えるようになってほしい - 特定のflow前後にstep/flowを追加できるようにしたい - 同じ作業を繰り返しやりたくない、 testの数を減らしたい 23
24. 24 もう少し柔軟なプライシング - mablを組織内で広く使ってもらうには、上限をオーバーしないように余裕を持った上限回数をセットする必要 がある - 月の上限実行回数に届かなくても、その分請求額が減るわけではない - 上限をオーバーした際の従量課金分をもう少し安くするとか、余った実行回数を翌月以降も使い回せるように するとかできると納得感が増しそう - 今いる顧客からの利益を最大化したい気持ちはわかるけど、 LTVで考えてほしいと自分は思う 24
25. 25 その他 - testsのon/offを時限発火したい - ^ 前後にslackリマインダーがあるとよさそう - planのstageを並列実行したい - 特定のtestは2個順番に実行したいけど、他は全部並列でいい　という設定ができるとありがたい - slack連携で、testを最後に編集した人をメンションするのは要らない - 独自slack通知だけでやっていくべきか 25
26. 26 mablのadminとして最近取 り組んだメトリクス整備事例 26
27. 27 QJF(急に実行回数が増えたので) 27 - 6月のtest実行回数が、毎月の支払額で実行可能な回数の 3/4近くを消費していて焦った - 実行回数が増えた原因調査や、実行回数を抑えられそうな施策はやるとして、もう少し利用状況の詳細が知 りたい - BQに連携可能なデータが既に入ってるので、 Looker Studioで可視化してみた
28. 28 月間のtest実行回数のグラフを作成 28 - ほぼ毎営業日watchしている - どれぐらいのペースで定額分の実行回数 を消費しているのかわかるようになった - BQのmabl_journey_runのテーブルに applicationの情報は入ってなさそう - mabl内のusageダッシュボードよりは ちょっとマシ - 閾値を設定してアラートを slackに飛ばした りできるとよさそう - 現状集計期間は手動で設定している
29. 29 application別のplan実行回数のグラフを作成　 29 - 日別のplan実行回数を可視化したもの - こちらはapplicationがわかる - planの中に入っているtestの数はわから ない
30. 30 最後に 30
31. 31 最後に - Ubieはこれからもmablを使い続けます - mablをより効果的に使うための努力も続けていきます 31