こんにちは。
最近家でパンを焼きまくっているhacomono QAのpiroこと廣田です。
この記事を開いてくれたQAエンジニアのあなた、
もしかすると、なんとなくコードに対しての苦手意識を持っていたりしませんか？
まさに私がそうでした。
開発経験もなく、ホワイトボックステストの経験も少なく、
コード＝よく分からないもの
と思ってしまっていて、正直苦手だなと感じていました。
そんな状況から抜け出そうと覚悟を決めて半年間、コードベースの自動テスト実装と向き合った記録をここに残しておこうと思います。題して、
開発経験0のQAエンジニアである私が、コードベースのテスト自動化ツール”Playwright”を使って、E2E自動テストを実装するまでの記録
そのまんまですね。
内容はこんな感じです。
【今回話すこと】
- どのような背景でE2E自動テストを書くようになったか
- コードベースの自動テストを書くに当たってどういった取り組みを行なったか
【今回話さないこと】
- 具体的なテストコードの書き方やコツ
- 自動テスト実行やメンテナンス、運用面の話
はじまり
きっかけはチームの大きな課題でした。
開発組織全体で、「リリースの頻度を、2週に1度から1週に1度に上げる」という大きなテーマがあり、QAのリグレッションテストがボトルネックの1つとなっていました。
というのも当時我々が行なっていたリグレッションテストは、ローコードテスト自動化ツールmabl（Link）で実装されたものと、手動でやるテストの両方が存在しており、手動分は100シナリオを超えていて、頑張っても全部で1日半くらいはかかるボリュームでした。
この課題を解決するために、まずは手動分のテストをPlaywrightで自動化しようというプロジェクトが立ち上がりました。コードに苦手意識があった私は、これを1つの成長機会だと捉え、飛び込んでみることにしました。ここまでが2025年1月、今から半年前のお話。
ここからは時系列順に、やって良かった取り組みを書いていきます。
取り組み①: 技術日誌
チームメンバー4,5人で毎日集まって、教わりながら実際にテストコードを実装して進めました。
初めたての頃は本当に毎日が新しい学びの連続でした。
私は覚えなければいけないことを取りこぼさないよう、技術日誌としてNotionページにその日学んだことをメモしていきました。忘れないためのメモくらいの感覚で始めましたが、振り返ると多くの効果があったと思います。
- 再び同じ問題で躓いた時に見返せる
- 自分の学びをOutputすることで固着させる
- 他の誰かが同じ問題に直面した時のナレッジになる
- 自分自身の日々の着実な成長を実感できる
今見返すと、テストコードの書き方はもちろん、
gitの操作やVSCodeの使い方、自動テストの戦略、「分からーーん！！」みたいな心の叫びなど、色んなことが書いてました。
取り組み②: ペアプロ・PRレビュー
徐々に慣れてきたタイミングで、ペアプログラミング（以下ペアプロ）をやってみることにしました。
それまでも4,5人で同期的に集まって、気軽に質問できる場だったのですが、
全員がそれぞれ持っている疑問点を決められた時間内に全て解消するのは難しかったため、2,3人のグループに分かれてペアプロをやってみることにしました。
ペアプロの具体のやり方はこうです。
- コードを書いていくドライバーと、サポート役のナビゲーターに分かれる
- ドライバーは常に自分の考えを口に出しながら作業を進め、
ナビゲーターは常にレビューしつつドライバーをサポートする役割 - 1人がずっと固定の役割を担うのではなく、適宜交代して行う
このタイミングではまだ分からないことの方が多かったですが、
ドライバーもナビゲーターも交代で担いました。
これは作業効率のUPというより、学習の効率UPに役立ちました。
他の人の考え方ややり方を学び、それを自分が別の人とペアプロをやる時にOutputして…といった具合に、チームで上手く学習のサイクルを回すことができました。
同時期、PRレビューにも積極的に参加するようになりました。
当然レビューすること自体も大切ですが、自分にとってPRレビューは学習の機会の1つでもありました。熟練メンバーの理路整然としたコードを見るだけで、真似したいポイントが山ほど見つかります。
他メンバーのPRは、テストコーディングにおけるアイデアの宝庫です。
取り組み③: AIツールの活用
5月頃、社内ではAIツールが積極的に活用されている状況で、
QAもAIツールを実際の品質保証活動に使い始めました。
テストコード実装の補助ツールとしての使い方もその1つです。
自分が主に使ったのはGemini、Github Copilot、Cursorの3つです。
それまでは1人で壁に当たった時、playwrightの公式ドキュメントとにらめっこしたり、
Qiitaなどで記事が上がっていないか何回もWeb検索したりと、1つ課題を解消するためにやたらと時間がかかっていました。
が、Geminiに「これに困っていて…」と投げてみると、キレイにまとまった情報がスルスル出てきます。色んなWebページを開いては閉じ…していた時間とはオサラバすることができました。
さらにその後github copilotを使ってみると自分が書いているコードを参照しながら
あれこれ助言をくれたり、解決策を提示してくれたりと、課題解決までのスピードが段違いに上がりました。
さらにさらにCursorを使ってみると、それまでやっていたペアプロのようなことがAI Agentとできるようになりました。
プロンプトを渡せば、0→1でテストコードのドラフトを書いてくれるし、レビューして〜とか、リファクタリングして〜というお願いもきっちりやってくれます。なんて賢い…！
Cursorに投げるプロンプトのイメージ
下記の条件でE2E自動テストスクリプトを書いてください。 ## 目的 - xxxなユーザーが、yyyした時、zzzができることを確認する ## 実装の必須事項 - テストには@xxx, @yyyの2つのタグを付ける - xxxの処理は既存の関数を使ってAPI経由で行う ## テスト実装内容 前提条件 <beforeEach> - xxx, yyyのデータ作成 - zzzのデータ作成 - aaaを可能にするため、bbbをONにする テストステップ<test> 1. aaaの状態でbbb画面にアクセス 2. 必要な情報を入力 3. 前提条件で作成したデータを選択 4. ccc画面でdddを選択し、処理を完了させる 5. eeeの状態でfffを行い、gggができることを確認 事後処理<afterEach> ・xxxのデータ無効化 ・yyyのデータ無効化 ・zzzのデータ無効化
AIを活用することで、実装スピードは格段に速くなりました。
初めたての頃、実装からマージまで3,4週間かかっていたのが、
今や早くて1週間足らずで済むようになりました。
まとめ
これまでやってきて今私が感じていることを2つ書いて終わりたいと思います。
1つ目は、これらの取り組みとは別の大事なポイントについて。
開発経験0だった私が 今はAIを活用しながら1人でもplaywrightでテストを実装できるようになりました。今回話してきた取り組みももちろんですが、この半年間毎日テストコードを書き続けたというのも、ここまで辿り着いた1つの要因だと思います。
まさに「継続は力なり」。当然だろと言われてしまいそうですが、これは真理です。
継続することでのみ、力を得られる、と言っても過言ではないと私は考えます。
2つ目は、「自動テストができる」ということについて。
やればやるほど、どこまで行けば「自動テストができる」と言えるのだろうか？と考えるようになりました。前述の通り、テストコードを書くのは今やAIに任せられる時代です。
そんな今、人であるQAエンジニアに求められる「自動テスト」のスキルは、別のところにありそうです。
まずは、自動テストは品質保証における1つの手段に過ぎないこと。
何を自動テストでやるべきか、自動テストでどんな問題を解決したいか、
手段として適切に扱うことができるかどうかは、人間が考えるべき領域です。
そして、目的に基づいて、どのようなテストを書くべきかを考え、どのように運用するべきか、判断すること。ここまでできてようやく、「自動テストができる」と言えるのではないかと思います。
この半年間で苦手を1つ克服できたことを誇りに思いながら、
QAエンジニアとして品質向上のためにできることをこれからも増やしていきます。
最後に、根気強くペアプロに付き合ってくれたチームメンバーに絶大な感謝を！
ご覧いただきありがとうございました。
💁 関連記事
