自動テストのツラみを解決！Autify導入でめざす誰でも管理可能なE2Eテストの実現

1. E2E自動テストコード管理コストの増加

OSSツールによるE2E自動テストのメンテナンスにコスト増加が問題になっていました。
ライブラリ更新、コードメンテナンスの手間などがあげられます。

2. 手動による受け入れテストの手間

レバテックでは、マーケ、ディレクターの方たちが受け入れテストを実施しています。 チェックリストを使って受け入れテストを実施していますが、過去の障害対応などによりチェック項目が増えテスト工数が増加しました。
また、マーケ、ディレクター目線でE2Eテストをソースコードで実装すると何をしているか把握できず共通認識が取れない状況も発生していました。

3. 意図しないバグの発生

度々システム変更に伴う意図しない箇所でのバグが発生していました。
Aだけを変更したはずがBで問題が発生し、しばらく発見されず機会損失に繋がっていたという感じです。

つまり、テストに対して工数が膨らんでいて、かつちゃんと運用している（つもり）にも関わらず一定バグが発生している状態でした。

• Autify
• MagicPod
• mabl
• BugBug

• メンテナンスコストが削減できるか
• 操作容易性（ノーコードであるか）
  • 非エンジニアでも自動テストが作れるか
    • 直感的に自動テストが作成できるか
    • 専門的な知識が必要なく運用できそうか

• 直感的に操作ができる点
  • 通常通り画面操作するだけで自動的にAutifyにシナリオが記録される
  • アサーション設定がわかりやすい
  • 非エンジニアに実際にトライアル中試してもらい好評だった
• AIによるメンテナンスコードの削減
  • 変更後、シナリオを修正しなくてもAIが頑張って最後までテストしてくれる（大幅に変更が入ると最後までいかないです。）
  • テスト結果画面から簡単にシナリオのメンテナンスが出来てシナリオを作り直すケースが少ない
• 充実した公式ドキュメント
• サポート体制
  • 契約後のオンボーディング
  • チャットボットによるカスタマーサポート

レビュー投稿時点で導入から3ヶ月程度のため大きな成果はまだ出ていません。
具体的な定量的な成果が出てきたら更新したいと思います。

3ヶ月時点の成果（個人的な感想も含みます）は下記になります。

• 一部、受入テスト項目をAutifyに移行したことで確認工数を短縮できている
• 主要機能を定期的に確認しているため、リリースに対する心理的安全性と変更容易性が上がっていると感じる
  • シナリオが増えれば、さらに向上しそうな手応えがあります
• 間接的ですが、AutifyをきっかけにE2E自動化テストを見直すきっかけになり、各チームで議論が活発になっている

• 複数チームでの運用を視野に入れていたため、事前に混乱が生じないよう命名規則やタグ付けルールを作成した
  • なお、管理を分けるワークスペースというオプションが存在する
    • 追加費用が掛かるのと、ルール整備すればなんとかなりそうだったので導入しなかった
• 契約上、テスト実行ステップ数に制限があるので超過しないようなルール作りと監視する仕組みを構築した
  • CI連携禁止、全シナリオの定期実行は1日1回までとし、シナリオの個別実行は自由
    • 現時点のルールであり、実行件数を加味して緩和する可能性あり
  • シナリオ命名ルールを工夫して、チームごとの実行ステップ数を可視化した
  • AutifyのAPIからデイリーで総実行件数を取得して閾値を超えたらSlackへ通知するようにした
• ステップ数制限に関して注意喚起をした結果、メンバーがツール利用に慎重になりすぎて初動が鈍くなった

まだ、導入から間もないですがAutifyは非常に優れたプロダクトだと感じます。
直感的な操作で専門性がなくてもテストが作成できるため、エンジニア以外の職種の方と協業しているチームで、テストツールを探していれば候補に含める価値はあると感じています。

一方で他ツールと比べて費用が高いことや、テスト実行ステップ数に制限がある点などやりづらい部分があるのも事実ですが、（なお、制限を超えても利用はでき、超過分は従量課金となります。）費用対効果以外の開発者体験などの見えづらい部分にも目を向けて検討してみてはいかがでしょうか。