QAエンジニアがテスト自動化に挑戦した話 〜ノーコードからPlaywrightへの第一歩〜

🍀この記事はこんな方におすすめ

• ノーコードツールの自動化に限界を感じているQAエンジニアの方
• Playwrightに興味があるけど「コードが書けるか不安...」と躊躇している方
• リグレッションテストに時間かかって困っているQAチームの方
• 自動化の成功事例だけでなく、リアルな失敗談や苦労話も知りたい方
• エンジニアとの協働でQA業務を自動化したいと考えているマネージャーの方

はじめに

QAエンジニアとして日々品質保証に取り組む中で、リグレッションテストの効率化は永遠の課題ですよね。今回は、私がノーコードツールからPlaywrightへの移行を決断し、悪戦苦闘しながら自動化を推進した経験をお話しします。
同じようにプログラミングによる自動化に踏み出そうとしているQAの方々に、少しでも参考になればと思います。

なぜPlaywrightを選んだのか

私たちのチームでは、リリース毎にリグレッションテストを実施し、最低限の品質担保を行っていました。すでにノーコードツールでの自動化は進んでいたのですが、いくつかの課題に直面していました。

ノーコードツールの限界

• メモリ制限により動作が不安定
• ローカル環境での実行が困難
• カスタマイズの柔軟性に欠ける

これらの課題を解決すべく、複数の自動化ツールを検証した結果、Playwrightを選択しました。

Playwrightを選んだ理由

1. 推奨環境での安定動作 - ほぼすべてのテストケースが安定して動作
2. コード生成機能 - 単純なテストであればブラウザ操作でテストコードの生成が可能
3. 学習コストの低さ - 段階的に学習できる環境

コードを書くQAの苦悩

正直に告白します。「少しはコード書いた経験もあるし、簡単なツールも作ったことあるから、できるかなー」なんて考えていた自分が恥ずかしいです。
実際、過去にちょっとしたスクリプトを書いたり、簡単な自動化ツールを作ったりした経験はありました。でも、本格的なテスト自動化フレームワークの構築は、まったく別次元の話だったのです。
QAとしてコードをバリバリ書いていたわけではない私にとって、以下の壁は想像以上に高いものでした。知識として知っていることと、実際にプロダクションレベルで実装することの間には、大きなギャップがあったのです。

直面した課題

1. コード管理の壁
   「Gitは使ったことあるけど、プロジェクトでの本格的な運用は...」
   「ブランチ戦略って何がベストプラクティス？」
2. CI/CDパイプラインの構築
   「CI/CDの概念は理解してるけど、実際の構築は...」
   「GitHub Actionsの設定ファイル、YAMLの書き方が...」
   はい、今までほぼ活用したことがありません！調査しながら手探りで進めました。
3. ファイルの肥大化問題
   最も深刻だったのは、ファイルの肥大化です。

• 冗長的なコードの増加
• ベタ書きの山
• 同じような処理の重複
  エンジニアの方に見せたら、きっと眉をひそめるようなコードでした...。DRY原則？SOLID原則？言葉は知っていても、内容などは理解してませんでした。

それでも見えた希望の光

とりあえず1日10件ペースでテストケースを書き続け、ようやく動かせるレベルに到達。そして実行してみると...
なんと6〜8時間かかっていたテストが、直列実行でも2時間で完了！
この瞬間、苦労が報われた気がしました。

実行時間の可視化で新たな発見

「各テストケースの実行時間ってどのくらいなんだろう？」
そんな疑問から、実行開始から終了までの時間を取得する機能を実装してみました。すると、驚きの事実が判明しました。
異常に早く終わっているテストケースが複数存在する！
確認観点に「◯◯がないこと」というチェックポイントの実装ミスがあることが発覚！

// 悪い例
expect(page.locator('.error-message')).not.toBeVisible();
// → ページ遷移に失敗していても「表示されていない」でOKになってしまう

そりゃそうですよね。ページ遷移できていなくても、要素が表示されていなければテストはパスしてしまいます...。

エンジニアとの協働による飛躍

一定の成果は出たものの、リファクタリングには実践的な経験不足を痛感しました。理論は分かっていても、実際にクリーンなコードを書くのは別の話でした。ここで、エンジニアの方に協力を仰ぎ、本格的な改善に着手しました。

実装した改善内容

1. コードのリファクタリング
- 冗長なコードの整理と共通化
- 重複処理の関数化
- ベタ書きされた値の変数化・設定ファイル化
- テストコードの可読性向上
2. GitHub ActionsでのCI実行
- プルリクエスト時の自動実行
- 定期実行の設定
3. 実行時間短縮のための並列処理化
- workers設定の最適化
- シャーディングの活用
4. テスト前提条件のAPI化
- UIを経由しないテストデータ作成
- セットアップ時間の大幅短縮
5. 固定データから動的処理への移行
- テストデータの動的生成
- 実行タイミングに依存しないテスト設計
6. テストケース間の依存性排除
- 各テストの独立性確保
- 並列実行時の安定性向上
SREチームのサポートも得て、現在はカバレッジ率90%超えを達成！しかも実行時間は十数分まで短縮できました。

新たな課題：サーバー負荷問題

順調に進んでいると思っていた矢先、新たな問題が発生しました。

問題の発覚

サーバー費削減の一環で、4vCPUから2vCPUにインスタンスをダウングレードしたところ、エラー検知の仕組みに引っかかってしまいました。
原因は明白でした：

• 各テストケースのAPI化により、サーバーへのリクエスト数が激増
• 並列処理により、短時間に大量のAPIコールが集中

暫定対応策

1. 無駄なAPIコールの削減
   • 重複するデータ作成の統合
   • キャッシュの活用
2. 並列度の調整
   • workers数の最適化
   • シャーディング設定の見直し
3. 負荷分散の工夫
   • APIコールのタイミング調整
   • 段階的な実行戦略
     なんとかエラーが出ないレベルまで抑えることができましたが、まだまだ改善の余地があります。

振り返りと今後の展望

学んだこと

1. 知識と実践のギャップを認識する
   • 概念を知っていることと実装できることは違う
   • 実践を通じて初めて本当の理解が得られる
2. 段階的なアプローチの重要性
   • 最初から完璧を求めない
   • 小さな成功を積み重ねる
3. エンジニアとの協働の価値
   • QAの視点とエンジニアの技術力の融合
   • お互いの強みを活かした開発
4. 継続的な改善の必要性
   • 一度作って終わりではない
   • 新たな課題への柔軟な対応

QAエンジニアの皆さんへ

プログラミングによる自動化は確かにハードルが高いと思われがちです。でも、一歩踏み出せば必ず道は開けます。

• 最初のコードが汚くても大丈夫
• わからないことは素直に聞く
• 小さな成功体験を大切に

私もまだまだ学習中ですが、この経験を通じて確実に成長できました。皆さんも、ぜひ挑戦してみてください！

おわりに

自動化の道は決して平坦ではありませんが、チーム全体の生産性向上に大きく貢献できる素晴らしい取り組みです。これからも改善を続けながら、より良い品質保証の仕組みを作っていきたいと思います。
同じような課題に直面している方がいれば、ぜひ情報交換させてください。一緒に、QAの未来を作っていきましょう！
—
最後に、、、

株式会社COMPASSでは一緒に教育をより良くしていく仲間を募集しています。

少しでも興味を持っていただけた方は、以下よりお気軽にご応募ください。

https://careers.qubena.com/

とりあえず話をきいてみたい！という方はぜひカジュアル面談に来ていただけると幸いです。

https://pitta.me/matches/tLPwBNbVWjhn