ノーコードで立ち上げ速度を重視したE2Eテスト自動化の第一歩

ツール導入前の課題

• QA不在で統合ブランチでのリグレッションテストを行えていなかった
• E2Eの自動テストを立ち上げたかったが、あまり工数を割けない状況だった

どのような状態を目指していたか

• 統合ブランチでのリグレッションテストを自動化し、より多くの時間を探索的テストや新機能の検証に充てたい
• プログラミング経験が少ないQAメンバーでもテスト自動化に参加できる体制を作りたい
• リグレッションテストを定期的に自動実行し、継続的に品質を安定させたい

• mabl

• ノーコードで直感的に操作できること: QAメンバー全員が使えること
• 初期構築のスピード: 早期にテスト自動化を立ち上げられること
• 日本語サポート: 国内企業として日本語でのサポートがあること
• メール通知や外部連携のテスト対応: kickflowはメール通知や外部連携機能が豊富なため、最低限の連携テストができること

• GUIベースで直感的にシナリオを作成・編集できるため、プログラミング経験が少ないメンバーでも参加しやすい
• メール通知の確認や外部連携のテストなど、コードベースでは実装コストが高い機能も容易に実装できる
• AIによる自己修復機能で、UIの軽微な変更に対してメンテナンスコストを抑えられる
• 日本企業として日本語でのサポートが充実している
• 新機能のリリース頻度が高い

改善したかった課題はどれくらい解決されたか

• リグレッションテストの大部分を自動化でき、工数を大幅に削減
• 業務委託メンバーを含むQAメンバー全員がテスト自動化に参加できる体制が実現
• 毎朝の定期実行により、デグレードの早期検知が可能になった

どのような成果が得られたか

• 初期からメインツールとして採用し、最大380シナリオを運用
• メール通知確認や外部連携テストなど、コードベースでは実装コストが高い機能のテストを実現
• テストの属人化が解消され、チーム全体でテスト資産を共有・メンテナンスできるようになった

• 複雑なシナリオ（条件分岐が多いワークフロー、複数ユーザーの操作が絡むケース）を安定して実行させるための試行錯誤
• テストデータの事前準備と後片付け（クリーンアップ処理）の設計
• どこまでをAutifyで自動化し、どこからを手動テストで残すかの線引き
• どうしても安定化しないテストの取り扱い

• E2Eテスト自動化の第一歩として非常に優れたツールです。ノーコードで立ち上げスピードが速く、プログラミング経験が少ないメンバーでもすぐに使い始められます。
• メール通知確認や外部連携テストなど、コードベースでは実装が難しい領域で特に力を発揮します。
• 一方で、シナリオ数が増えてくるとUIの変更時のメンテナンスコストが課題になることがあります。将来的にコードベースのツールへの移行も視野に入れつつ、適材適所で使い分けることをお勧めします。

• 現在、Autifyで運用しているシナリオのうち、移行したほうが運用コストが下がるものはPlaywrightへ段階的に移行中
• メール通知確認など、Autifyでしか実現できないテストは引き続きAutifyで運用予定
• コスト削減と保守性向上のため、コードベースのツールと組み合わせた最適な構成を目指している