mablの導入効果をレビューでご紹介(筋肉CTO)

導入前は、スプリントごとに作成する新機能テストに加え、決まったメニューの非回帰テストを実施。非回帰テストは1名で回していたうえ、機能増加や本番バグの検知につれて非回帰テストが急増していた。

週次でリリースを行うサイクルの中で、5日間のスプリントのうちの最後の1日でテストを実施しバグを検知する状態では、バグが起きた際にバグへの対応によりリリースが遅れてしまうという課題があった。

バグの存在を事前に検知できるようにシフトレフトすることが、あるべきエンジニアリングの形だと考えた。また、ヘンリーでは、医療ドメインにディープダイブするために医療事務など、ドメインのスペシャリストであるドメインエキスパートを採用しているが、彼らの知見を最大限活かすためには非エンジニアがテストを実行できる必要があり、テスト自動化のローコードツール導入を検討した。

• トライアルの段階で非エンジニアの方にmablを使ったテストを作成してもらっていたが、非エンジニアでも利用できる使いやすさがあった
• CI/CDとの連携や統計のAPI提供など、エンジニアリングとの統合が強力だった
• 多くのBtoB企業で行う以下のような複雑な機能のテストをカバーしている点
  • 変数の動的設定が可能である
  • AIによるクリックやセレクタによる検索、JS処理など多様な操作方法がある
  • メールの文言検証や二要素認証のサポートしている
• 2021年段階でGlobalでのシェアが1位だったのと、StackdriverをGoogleに売却した起業家が設立した2社目の企業だったというのもあり、信頼することができた

mablが使いやすいということもありますが、非エンジニアで自動テストを作成できているのは、ヘンリーのドメインエキスパートがレベルが高くて素晴らしいという側面もあります。私だったら元医療事務で変数生成したりなど自動テストを作成するのはなかなか難しいと感じました。

テスト自動化ツールは工数削減を目的とされる方もいるかもしれないが、テストの作成やツールの利用におけるキャッチアップも含めると工数はむしろ増える可能性もあります。それよりも組織がスケールした際にバグ対応で後手に回らないように自動テストを利用することで生産性を高めるという意識が重要だと思います。

また、手動の非回帰テストが週1回、1時間程度でそこまで負担になっていないフェーズであればテスト自動化ツールを導入する必要はないと考えています。1〜2年経って、機能が増えたり、複雑化したタイミングで考え始めればいいと思います。