🧑💻 はじめに
QAエンジニアとして働いていると、
- PlaywrightでE2Eテストを書いてみたい
- APIテストを実践してみたい
- GitHub ActionsでCI/CDを構築してみたい
と思うことはありませんか？
私自身も以前から興味はあったのですが、学習を進める中で一つ大きな壁がありました。
それは、
テスト対象のアプリがない
ということです。
もちろん学習用のサンプルアプリは数多く存在します。
ただ、自分で要件を考え、自分で品質を担保しながらテストを書く経験をしたいと思うと、なかなかちょうど良い題材が見つかりませんでした。
さらに私は開発者ではなくQAエンジニアです。
アプリを一から開発すること自体のハードルも高く、
- テスト自動化を学びたい
- APIテストもやりたい
- CI/CDも触りたい
と思いながらも、なかなか最初の一歩を踏み出せませんでした。
そこで今回は発想を変え、
AI（Codex）を使ってテスト対象のアプリそのものを作る
ことにしました。
コードの大部分はAIに任せ、私はQAエンジニアとして
- 要件を考える
- テストしやすさを設計する
- 品質を確認する
ことに集中します。
結果として、
- Todoアプリ開発
- APIテスト
- PlaywrightによるE2Eテスト
- GitHub ActionsによるCI/CD
まで一通り構築することができました。
この記事では、その過程で学んだことや、QAエンジニアだからこそ感じたAI活用のポイントを紹介します。
🎯 今回の目的
今回の目的は「すごいアプリを作ること」ではありません。
目的はあくまで、
QAエンジニアとして、自動化と品質保証の流れを理解すること
です。
そのため、以下を強く意識しました。
- 作るものは極限までシンプルにする
- AI（Codex）をフル活用する
- 自動化前提で開発する
- テストしやすい設計を意識する
🧱 まずはアプリ開発
最初に作ったのはシンプルなTodoアプリです。
構成
- フロントエンド：HTML + JavaScript
- バックエンド：Node.js（Express）
- データ保存：メモリ管理
今回はあえてDBは使用しませんでした。
理由はシンプルで、
テスト自動化の学習に集中したかったから
です。
実装した機能
- ログイン / ログアウト
- Todo追加
- Todo一覧表示
- Todo削除
機能としては非常にシンプルですが、
「テストしやすいこと」
を最優先に考えました。
🤖 AIにコードを書かせても「テストしやすいアプリ」は勝手にできない
今回、実装自体はほぼCodexに任せました。
最初は、
AIに作らせれば簡単にテスト対象を用意できるだろう
と思っていました。
しかし実際にはそう簡単ではありませんでした。
例えば、
Todoアプリを作って
だけでは、
- 要素を特定しづらい
- data-testidがない
- API仕様が曖昧
- テストデータの扱いが不明確
など、自動テストを書く立場からすると扱いづらい実装になることがありました。
そこで、
Node.jsとExpressでTodoアプリを作成して
Playwrightでテストを書く前提で実装して
data-testidを付与して
ログイン機能とCRUD機能を実装して
のように、QA視点の要件を細かく伝えるようにしました。
ここで気づいたのは、
AI時代でも「何を作るべきか」を定義する力は人間側に必要
ということです。
特にQAエンジニアが普段行っている、
- 要件整理
- テスト観点の洗い出し
- 境界値の意識
- リスク分析
といった考え方は、AI活用においても非常に重要だと感じました。
実際には、コードを書くことよりも
- 何を作るか
- 何をテストするか
- どう品質を担保するか
を考える時間の方が長かった印象です。
AIが開発を支援してくれる時代だからこそ、QAエンジニアの強みである「品質を考える力」がより重要になると感じました。
🔌 APIテストを実装
アプリ作成後、次にAPIテストを実装しました。
UIテストだけで品質を確認するのではなく、まずAPI単位で品質を担保することを意識しました。
APIテストには次のようなメリットがあります。
- UI変更の影響を受けにくい
- ロジック単位で確認できる
- 障害発生時の切り分けがしやすい
テストした内容
- ログインAPI
- Todo追加API
- Todo取得API
- Todo削除API
など、基本的なCRUD操作を確認しました。
実際に触ってみると、
「まずAPIで品質を固める」
ことの重要性を強く感じました。
E2Eテストだけでは原因特定が難しいケースでも、APIテストがあることで問題箇所を素早く絞り込めます。
🧪 PlaywrightでE2Eテスト
API確認後はPlaywrightでE2Eテストを実装しました。
実装したシナリオ
- 正常ログイン
- Todo追加
- Todo削除
- 空入力バリデーション
- ログアウト
など、実際のユーザー操作を想定したテストを作成しました。
👀 「見えるテスト」にして理解を深めた
今回はあえて、
headless: false
に設定し、ブラウザを表示した状態で実行しました。
さらに、
slowMo: 500
を設定して動作をゆっくり確認できるようにしています。
これが想像以上に効果的でした。
自分で作ったアプリが、
- AIで生成したコード
- 自分で設計したテスト
によって動いている様子を目で確認できるため、Playwrightの動きやテスト設計への理解が深まりました。
⚙️ GitHub ActionsでCI/CD
最後にGitHub Actionsを利用してCI/CD環境を構築しました。
コードがPushされたタイミングで、
- APIテスト
- Playwrightテスト
を自動実行するようにしました。
🧠 CIで学んだこと
実際にCIを導入すると、
ローカルでは成功するのにCIでは失敗する
という問題が普通に発生します。
例えば、
- 起動待ち不足
- 環境変数の設定漏れ
- 非同期処理のタイミング差
- 実行環境の違い
などです。
ここで初めて、
テストは「自動で継続実行されてこそ価値がある」
ということを実感しました。
ローカルで一度成功しただけでは品質保証とは言えず、継続的に実行できる仕組みまで含めて初めて品質活動になるのだと学びました。
🧠 QAエンジニアだからこそ得られた学び
今回の経験を通して感じたのは、
自動化を学ぶために、必ずしも開発者になる必要はない
ということです。
AIを活用すれば、アプリ実装のハードルは以前より大きく下がっています。
一方で、
- 何を品質として担保するのか
- どこを自動化するべきか
- どのレイヤーでテストするべきか
を考える力は依然として重要です。
むしろAIがコードを書く時代だからこそ、
- テスト戦略を考える
- 品質リスクを見つける
- 継続的に品質を監視する
といったQAエンジニアの価値はさらに高まっていくと感じました。
✍️ まとめ
今回、
- アプリを作る
- APIで品質を確認する
- Playwrightでユーザー操作を確認する
- GitHub Actionsで継続実行する
ところまで、小さく一通り経験することができました。
プログラミング経験が少なくても、
「品質をどう担保するか」
という視点を持っていれば、AIを相棒にかなり実践的な学習ができると思います。
🔚 おわりに
次回は、
- APIテストの詳細
- Playwrightの設計方針
- GitHub Actionsでハマったポイント
- AIとテスト自動化の付き合い方
などについても記事にしていきたいと思います。
同じように、
「開発経験がないから無理かも」
と感じているQAエンジニアの方に、AIを活用しながら新しい技術へ挑戦するきっかけになれば嬉しいです。
✨未経験から学べます！一緒に挑戦していきましょう✨