mablの導入効果をレビューでご紹介(YoshikiIto-株式会社カカクコム)

mabl導入以前は手動テストが中心で、一部チームではSeleniumなどのOSSを活用したテストを行っていたが、テストの工数やメンテナンスの手間が掛かっていることが課題であった。そこで、システム本部内でテスト自動化の検討を開始した。最初の導入ターゲットとして価格.comを選択したが、価格.comは長く続いているサービスであり、レガシーな部分によってユニットテストの書きづらさが懸念され、E2Eテストの自動化から着手した。

• Autify
• MagicPod

• Selenium、Playwrightを利用している時は、テストのメンテナンスがしづらいなどの課題があったため、メンテナンスコストの低さを重視した
• オンプレの開発環境に対してアクセスする仕組みとして、mabl Linkが最もハードルが低かった
• アクセシビリティなどグローバルの視点で求められるような要素を取り入れるスピードが感じられた
• Autifyはモバイルのテストができたが、モバイルのテストよりも上記項目の方が優先度が高かった。MagicPodではテストを自動化する仕方が異なり、操作を記録するタイプの自動テストであるmablの方が自社では使いやすいと感じた。
• 海外の会社であったが、日本法人の立ち上げや一番最初のローカライズ対応が日本であるなど、日本市場を重視していた

当時は日本におけるmablの事例はまだ少ないフェーズだったが、カカクコム内では当時からGitHubを始め海外サービスを活用することは多かった。また、これから日本語対応を進めていくというmablのロードマップも見えていたため安心して導入することができた。

導入した当初は、技術的な部分はあまり困らなかったが、最初の1〜3ヶ月にmablを使い過ぎて、月間3000回実行という契約プランに対し、4000回以上テストを実行してしまうことがあった。自動テストを運用する際の勝手があまりわかっておらず、複数の端末のバリエーションでのテストを高頻度で実行した結果、実行回数がどんどんカウントされ、意図せず月間実行回数を超過して追加料金が発生してしまっていた。その後、mablでのテスト実行頻度を少なくするよう、当時利用していた部門に依頼した。その結果、逆に実行回数が余ってしまうなど、上手く運用していく上で失敗をした経験がある。

テストのメンテナンスで工夫しているところ

ログイン機能などmablとして共通化した方が良い部分をフローとして切り出したり、データテーブル機能を活用してテストのステップとデータを切り分けて管理したりといったmablとして推奨されている方法を取り入れている。また、細かい部分では、各テストのステップを作成する際に、要素が変更されても影響を受けにくい方法を選択し、壊れにくいテストを作成するよう意識している。

私自身、過去にはある程度運用が進んでいて手動テストをずっと続けていたシステムに対して、自動テストを後から大規模に導入して大変だった経験があります。

できれば、ミニマムなプランからでも良いので早い段階からテスト自動化の仕組みを導入することをお勧めします。

週2回や毎日など、頻繁に自動テストを実施することで、問題を早期に発見することができます。

また、ある自動テストの実行から次に実行するまでに長い期間が空いてしまうと、テストを修正するのに多くの時間が掛かることがあります。

テストが正常に動く状態を保つためにも、実行頻度を確保することが重要です。

少しずつテストを回していきながら、開発環境へデプロイする度にリグレッションテストを実施したり、本番環境にデプロイした際にも新規追加や改修部分の手動テストに加えて他の部分のリグレッションテストをしたりと、複数の段階で自動テストができると安心です。

一方で、自動化以前にやるべきことがまだまだ存在する状態の場合は、テスト自動化ツールは必要ないと思います。あまりにもプロダクトの品質がよくない時や、テスト自体のやり方が固まっていない時は、ツールを入れても上手くいかない可能性が高いです。テストのやり方がある程度チー ム内で固まってから自動化を検討すると良いと思います。