mablの導入効果をレビューでご紹介(株式会社ヘンリー-sumiren)

参考になった

レビュー投稿日の情報になります

株式会社ヘンリー / sumiren

メンバー / SRE / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名

最終更新日2024/03/08投稿日2024/01/21

利用プラン	ツールの利用規模	ツールの利用開始時期
スタートアッププラン	10名以下	2023年3月

導入の背景・解決したかった問題

導入背景

導入前は、スプリントごとに設計する新機能テストに加え、非回帰テストも手動で実施していました。機能増加や本番バグの検知につれて非回帰テストが急増しており、非回帰テストに要する時間が長くなった結果、スプリント終盤に非回帰テストでバグを検知してリリースが遅れるといった課題が発生していました。この課題に対して、バグの存在を事前に検知できるようにシフトレフトすることが、あるべきエンジニアリングの形だと考えました。ヘンリーでは、医療ドメインにディープダイブするために医療事務などのドメインエキスパートを採用しており、ドメインエキスパートがQAの仕事をしています。そのため、ソリューションの検討にあたっては、彼らの知見を最大限活かすことを重視しました。こうしてmablを導入することになりました。

比較検討したサービス

Autify

選定理由

非エンジニアでも利用できる使いやすさがあった
CI/CDとの連携や統計のAPI提供など、エンジニアリングとの統合が強力だった
以下のような複雑な機能のテストをカバーしており、バーティカルSaaSであり複雑な業務を支援するHenryにマッチしていた
- 変数の動的設定が可能である
- AIによるクリックやセレクタによる検索、JS処理など多様な操作方法がある
- メールの文言検証や二要素認証のサポートしている

導入時の苦労・悩み

非エンジニアであるドメインエキスパートがツールを積極的に使えるようにするためには、テスタビリティの低い機能の改修やJSスニペットや共通フローの作成、つまずきそうな機能のQ&AのWiki作成やワークショップなど、成功体験を積めるように先回りで環境を整える必要がありました。結果的には、ドメインエキスパートが前向きにmablに取り組める流れを作ることができました。トライアルで毎日同期的に時間を取りながらテスト作成に慣れてもらえたタイミングで、当初の目的であったドメインエキスパートの知見活用と自動テストを両立できそうだと確信しました。

導入に向けた社内への説明

経営陣・上長への説明

前提として非回帰テストの急増によってテスト期間が伸びたり、そこで問題が発生した際にリリースに影響が出たり、という課題に対して共通認識を持っていた。
ドメインエキスパートが自動テストを実行できる状態を作ることが、ヘンリーが目指すべきエンジニアリングの世界観であること伝えた。
特に注意した点として、自動テストはテストの作成やメンテナンスの時間がかかるため、自動テストの価値は工数削減ではなく、あくまでシフトレフトから得られる開発生産性であり競争力であることを強調した。

費用対効果の算出

コストをどうやって回収できるかというロジックを用いて資料の作成や説明をしたというよりは、自社が目指す世界観に近いのはmablを活用した体制であるという話し方で進めました。一方で、固定の回数＋超過分の従量課金制なので、テストの実行回数や費用の試算等は行っています。

活用方法

よく使う機能

テストの実行方法
- ヘンリーでは週に1回に本番リリースを絞っており、トランクには各自自由にマージした上で、週に1回ステージング（リリース前環境）とプロダクション環境にデプロイしています。
- 上記を踏まえ、MablのPlan機能により、トランクが自動デプロイされるテスト環境では毎日、ステージング（リリース前環境）では週に一度のデプロイ日にテストを自動実行しています。
テストの追加
- 週に1度、同期的にmablのテストを作成する時間をQAチームで取っている。また、週に1度のQA定例の中で、既存機能のバグや新規機能からmablの非回帰テストに移すものをリストアップしている。
Slack連携と実行結果画面
- テストが落ちた際はSlackで通知を受け、実行結果の画面スクリーンショットを見てトラブルシュートを行っている
統計情報を活用したPDCA
- mablのダッシュボードからテストごとの成功率を見たり、GitHub ActionsでmablとAPI連携をし、テスト全体の通過率の変遷を確認している

ツールの良い点

バグをすぐ検知することで生産性が向上
- 手動テストの場合、開発とテスト実行にラグがあり、トラブルを引き起こしたコミットハッシュの特定が困難になったり、コンテキストスイッチが発生するなど、対処が後手に回ることによる被害が大きい。その点、自動テストはバグをすぐに検知することができるので、生産性を高めることができる。
質実剛健なプロダクト
- 高速でテストを作成できるといった華やかな機能はないが、複雑なプロダクトでもしっかりテストできカバレッジが広い。プロダクトや組織フェーズが浅く、組織全体でエンジニアリングに向き合うようなときに真価を発揮できる。

ツールの課題点

テストの安定性に課題

リトライすれば戻るが、15件/日くらいテストを行う中で、mablの挙動の問題で1〜2件/日ほどテストに落ちたりするケースがある。恒常化するとテストに落ちた際に、バグではなくテストの不安定さが原因なのではないかとなり形骸化してしまう恐れがあるのが課題。

テストの回数制限

スタートアッププランでは月に500回、日割りにすると1日に15回くらいしかテストを回せない。現状は日に1回でも間に合ってはいるが、デプロイ単位でテストを回すというE2Eテストの理想の状態を達成しようとすると回数制限が課題になる。

タイムゾーンなど細かい設定ができない

日本のタイムゾーンに時間を設定できない点。それによる問題として、現地アメリカでは前日だが、日本ではその日（当日）であるという状態になると、データを作って画面を更新してもデータが出力されないことがあることは改善して欲しい。

(※2023/09/19時点でタイムゾーンのカスタマイズ機能は早速対応されました。)

ツールを検討されている方へ

テスト自動化ツールを工数削減と結びつける方もいらっしゃるかもしれませんが、テストの作成やツールの利用におけるキャッチアップも含めると、工数はむしろ増える可能性もあります。それよりも、組織がスケールしても競争力を保つための自動テストという意識を持ち、それを組織内で統一することが成功の秘訣と考えています。

株式会社ヘンリー / sumiren

メンバー / SRE / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名

18歳からプログラマーとして活動。その後クラウド系のSIerでリードエンジニア・マネージャーを経験。2023年4月にHenryにジョインし、医療会計チームでフルスタックエンジニアとして機能を開発しながら、CTO室で自動テスト、オブザーバビリティ、アーキテクチャを担当している。