QAエンジニアが0からPlaywrightを導入してテスト工数を削減

ツール導入前の課題

　既存のデスクトップアプリをクラウドに移行するプロジェクトにリソースを割いて開発を進めていました。 一方で、積極的な機能開発は行わないものの、定期的なコンテンツ更新やライブラリ、ミドルウェアのアップデートが必要な保守運用フェーズのプロダクトを並行して抱えていました。この保守プロダクトにおける定期的なアップデートのたびに、安全性を確認するためのリグレッションテストを手動で行う必要がありました。一回あたりの工数は0.5人日程度ですが、積み重なると無視できない負担となっていました。この工数を減らしてメインのプロダクトへのリソースを増やしたいという思いがありました。

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

　保守プロダクトのテストを自動化することで、ライブラリやインフラ更新時などの最低限の品質保証にかかるリソースを最小限にして、メインのプロダクトへのリソースを最大化できる状態

• 弊社の他プロダクトで利用している既存の有料ノーコードツール

• 費用

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

• テスト実行時間の大幅な短縮：0.5人日程度の工数が10~20分程度

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

• メインプロダクトにリソースを割きながら保守運用プロダクトの品質も保つことができた

実装リソースと技術スキルのギャップ

プログラミング知識の不足とFlaky Testの量産

　今回は開発チーム主導ではなく、普段プログラミング業務を行っていないQAエンジニアが主体となって実装を担当しました。Playwrightは直感的な操作でテストコードを生成できるため、基本的な表示確認などのシンプルなテストであれば、経験が浅くても比較的スムーズに作成することが可能です。
　しかし、条件分岐を含む複雑なテストシナリオの実装や、メンテナンス性を考慮したコード構成、実行パフォーマンスを意識した効率的なテストコードの作成には、やはりプログラミングの基礎知識が不可欠でした。これらのことを考慮できてなかったために導入初期の段階では、要素の描画を待たずにアクションを起こしてしまったり、並列実行時のデータの競合を考慮できていなかったりと、非同期処理と環境分離の理解不足から、Flaky Testを量産してしまいました。
　この課題に対しては、生成AIにテストコードとエラー内容を確認させて問題点を指摘してもらったり、フロントエンドエンジニアの方に相談したりして少しずつリファクタリングしていきました。

設計の考慮不足によるコードの肥大

　また設計面では準備不足がありました。テストケースが増えるにつれ、重複したセレクタと操作手順が量産されていき、コードが肥大化していく問題に直面しました。POM(Page Object Model)という、画面ごとのセレクタ定義や操作ロジックを専用のクラスに集約するデザインパターンがあります。このPOMを早期に導入しておけば保守性、可読性の高いテストコードを作成できたと思います。現状のプロダクトでは、「今後積極的に機能開発をしていかない」、「現状のままでもテスト結果は安定している」ということからPOMの導入は行いませんでした。 　

何をテストするのかを明確にしておく

　E2Eテストは便利ですが、実装・保守のコストは安くありません。どういった課題を解決したくて、それを実現するためにはどういったテストを実装する必要があるのかを検討することが必要です。

設計は慎重に、実装は柔軟に

　事前の設計には時間をかけるべきだと思います。今回は最初からPOMを導入していなかったためテストコードが肥大化してしまう問題点に直面しました。修正にかかる実行時間と現状の状態を考えてPOMベースにリファクタリングすることは見送りましたが、最初からPOMを導入しておけばよかったと後悔しています。今回の私のケースのようにならないために、できるだけ手戻りがないように事前の設計は大事だと思います。

　一方で綺麗に書こうと思ったり、完璧を求め過ぎると時間がかかってしまいます。目的を達成することを大事にして、できる範囲で対応をしていくことが大事です。

　QAエンジニア全員が高度なコーディングスキルを持っているわけではありませんが、品質保証の専門家としてE2Eテストを作成・運用することには大きな価値があると考えています。 そのため今後は、AIエージェントやMCP等の生成AIを活用し、コーディングスキルに依存しすぎずにPlaywrightを実装できる、新しい自動化の形に挑戦していきたいです。