こんにちは！スマートキャンプでBALES CLOUDというSaaSを開発しているエンジニアの井上です。
本記事では、弊社のBALES CLOUD開発チームでサービスの品質を保つために導入したE2Eテスト自動化サービスmablについてご紹介します。
mablとは
mablはE2Eテスト自動化サービスです。 特長としては以下のような機能を備えています。
- mabl Trainer というChromeの拡張機能があり、自分の操作手順を記憶させることでテストを作成できる
- CI/CDにも簡単に組み込むことができる
- クロスブラウザのテスト実施も可能
導入背景
導入前の状態
弊社のBALES CLOUD開発チームはエンジニア2人とPM1人の体制です。 リリースまでは以下のようなフローをとっており、Unitテストはしっかり書かれているためカバレッジは高い状態でした。 また、過去にデザイン崩れなどの問題も起きていたので、Visual Regression Testを追加しデザイン崩れに気付ける状態にした上で POが要求通りかテスト環境で確認してくれるので安心してリリースできる状態でした。
導入前のリリースフロー
- 機能開発
- Unitテスト
- Visual Regression Test
- コードレビュー
- POの要求仕様確認テスト
- リリース
BALES CLOUDで発生した思わぬバグ
いつもどおり安心して本番リリースを実施したところ、追加した機能の影響で既存機能にバグが発生しました。 エンジニアもPMも影響範囲がその機能に及ぶとは思っていなかったため、テストから漏れていた状態でした。
開発初期であればコードサイズも小さいため、影響範囲の把握が容易でしたが 機能追加していくと、関連し合う機能が増えUnitテストだけでは担保できない範囲でバグが発生する状態になっていました。 その後、発生したバグに対する振り返りを行い、検知のためにはアプリケーションに対する手動テストを行う必要があるという結論になりました。 しかし、手動では機能の増加に伴ってテストのコストも増加していくため、E2Eテストツールを導入することを決めました。
E2Eテスト導入への課題
E2Eテストを導入する前にクリアしなければならない課題がいくつかありました。 そもそもE2EテストはUnitテストとは逆の特徴があり、以下のような課題があるため今まで手をつけられていませんでした。 そのため、これを解決しないままE2Eテストを導入することはテストのメンテナンスコストを高くする恐れがありました。
E2Eテスト導入するための解決すべき課題
- 壊れやすく、メンテナンスが大変
- ちょっとした文言の変更等で落ちたりする
- そのたびに修正をしなければならなくなる
- 導入コストが高い
- E2Eテストツールは様々あり、ツールの選定や安定運用できるだけの知識の習得が大変
- 安定性が低い
- たまに発生する落ちる要因(画面のロード待ち、文言の変更)がいくつかある
mablを選んだ理由
今回のツール選定では、上で挙げたE2Eテスト導入するための課題をもっとも解決してくれそうだったmablを選び導入に至りました。良いと感じた点は以下のようなところです。
1. コーディング不要でテスト作成が簡単
一番の理由は、コーディングをしなくてもテストが作成できるという点です。 mablTrainerという機能で直感的かつ簡単にテストが作成できます。 また、Flowという小さい操作単位にして他の操作と組み合わせることなどもでき 上手く設計すれば既存のFlowを組み合わせるだけでテストができるのでとても魅力的でした
2. クラウド/SaaS環境なので初期構築コストがない
E2Eテストはメンテナンスコストもかかりますが、初期構築のコストも高くさくっとお試しがしづらかったりします。 その点mablはSaaSとして提供されているため、すぐにテストを試せるという点が魅力的でした
3. AIでテストを自動修復、自動画面分析
E2Eテストの難しいところで、少しの変更でテストがコケるのでメンテナンスコストがかかるという点です。 この点に関してはmabl側でAIが自動でテストを修復してくれる設定があるので、これをONにすることで文言変更などの多少の変更は自動で修復されるようになります。
4. Japan Lead 藤原さんの手厚いサポート
mablの導入ではJapan Lead 藤原 大さんにサポートを受けながら導入や設計をおこないました。 mablの機能説明だけではなく、どのようにテストをすればいいか解説して頂き 導入後はテストのレビューまでしていただき、手厚いサポートに頭が上がりませんでした。
mablでテストを作る
次に、実際にテストを作っていった過程について紹介します。
mablの構造を知る
mablでテストを作成する上で、操作をどの単位で組み合わせて作れるようにしていくかを設計するために、 mablの構造をエンジニアとPMで図を作成しながら認識を合わせました。 コストはかかりましたが、この後の動きはかなりスムーズになるアクションでした。
テストを作成する
テストを作成するにあたって、これまで一番手動テストをしているPOと何をテストするかの認識合わせをしました。 プロダクトにとって大事な機能に問題が起こらないようにPOに最終チェックをしてもらっているため mablでどのようなテストを作っていくかの認識を合わせることで今後のPOのテスト工数も減らせるのでは、という取り組みでした。 そして、その認識合わせの中で上がってきたやるべきテストを選定しmablに落とし込む作業を行いました。
mabl導入により良かったこと
現在は作成したテストをPOの要求仕様確認テストの前に走らせることで既存機能への影響がないかが担保される状態になりました。 これにより、今までPMやエンジニアが既存機能のテストに時間を使っていた部分が自動化されて、新たに追加された機能のみを手動テストすればリリースまでできる状態になりました。 また、既存機能のテストにかけていた時間を開発に使うことができるようになったのも導入した効果かなと思います。
まとめ
mablの導入によりこれまでコストがかかっていた既存機能で重要な部分のテストを実現することができました。 まだmablへのテスト追加ができていない箇所も多いので、徐々に自動化していき、より開発に時間を使っていける状態にしていきたいなと思います。
