はじめに
こんにちは。プロダクト品質部のSです。
プロダクトの成長に伴い、私たちは常に「リリースのスピード」と「品質の担保」の両立という課題に直面しています。
今回は、増大し続けるリグレッションテストの負荷を解消すべく取り組んだ、テスト自動化フィジビリティ（実現可能性）調査の道のりをご紹介します。
1. リリース頻度の増加とテスト工数の肥大化：訪れた「限界」
私たちのチームでは、新機能の追加や不具合改修をいち早くお客様に届けるため、リリースサイクルの高速化を進めています。
しかし、そこで壁となったのがリグレッションテストの工数です。
- 開発サイド： 「1日でも早くバリューを届けたい（アクセル）」
- QAサイド： 「影響範囲を確実に網羅し、デグレードを防ぎたい（ブレーキ）」
この両者を両立させる鍵が「テスト自動化」でした。
自動化の最大の武器は、高い再現性を持って24時間365日、何度でも同じテストを実行できることです。
私たちは、最もクリティカルなメイン業務フローを自動化の対象に据えました。
2. なぜ「コードベースのテスト自動化ツール」だったのか：エンジニアが品質に責任を持ち、作りこむための自動化を目指して
自動化ツール選定において、私たちが重視したのは「WebとiOSの両プラットフォームを一気通貫でテストできること」、そして「開発エンジニアが主体となってメンテナンスし続けられること」です。
ノーコードツールの導入も検討しましたが、最終的にコードベースのテスト自動化ツールを選択しました。その理由は以下の通りです。
- 拡張性の高さ：複雑なロジックをコードで柔軟に記述できる。
- 管理の親和性：開発フローの中にテストコードを組み込み、レビューやバージョン管理を容易にする。
- 初期費用の抑制：必要な機能に絞ってスモールスタートが可能。
3. 自動化フィジビリティ：一気通貫シナリオの壁
フィジビリティ調査を進める中で、いくつかの技術的挑戦（壁）が見えてきました。
特に苦労したのは、「Webで操作した内容を、iOSアプリ側で確認する」といったデバイスを跨ぐ一気通貫のシナリオです。
- 実装難易度： 異なるプラットフォームの要素を一つのフローで扱うため、スクリプトの構造が複雑化しやすくなります。
WebとiOS、知見のあるエンジニアが違うことも想定されるため、役割分担を決めて対応する必要性がありました。 - 実行の信頼性： ネットワーク遅延やデバイスの処理速度の差により、要素指定（セレクタ）でエラーが発生することがありました。
これに対し、待機処理の最適化や、要素特定の精度を上げるチューニングを地道に行う必要性がありました。
4. 調査結果：50%以上のテストが自動化可能という「光」
フィジビリティ調査の結果、リグレッションテスト項目の50%以上が自動化可能であるという具体的な展望が開けました。
この50%を自動テストに委ねることで、「常に一定の品質が担保される安心感」を手に入れることができます。
これにより、これまで手動のリグレッションテストに費やしていた膨大な時間を、より高度な探索的テストや新機能の品質向上といった、人間にしかできないクリエイティブな検証活動へ大胆にシフトさせる見込みが立ちました。
5. 今後の展望：テストを「資産」へ
今回のフィジビリティ調査を経て、ようやくスタートラインに立てたという実感が湧いています。もちろん、自動テストを導入したからといって、すぐに全ての課題が解決するわけではありません。
今後は、特定した50%の項目を順次実装し、CI/CDパイプラインへ組み込んでいく予定です。私たちが目指しているのは、単に「テストを自動化すること」ではなく、「開発エンジニアが自信を持ってリリースできるための支え」を作ることです。
自動テストを運用していく中では、仕様変更に伴うメンテナンスや、不安定なテスト（Flaky Test）との戦いも予想されます。ナレッジを積み上げて、少しずつ「自分たちのプロダクトを守る資産」として育てていければと考えています。
最後に、スパイダープラスでは仲間を募集中です。
スパイダープラスにちょっと興味が出てきたなという方がいらっしゃったらお気軽にご連絡ください。
