すでに使っているE2Eテストと、これから詰めるべきテスト計画
1. はじめに
月商1000万円を目指して、新規プロジェクトを進めている。
このブログでは、プロジェクトの具体的な企画内容はまだ公開しない。
ただし、開発の進め方、AI活用、費用、スケジュール、品質管理、課題については記録している。
今回は、現状のテスト自動化と、今後のテスト計画について書く。
サービス開発では、機能を作るだけでは足りない。
作ったものが正しく動くか、ユーザーが迷わず使えるか、データが壊れないか、スマホでも問題なく使えるかを確認する必要がある。
特に今回のプロジェクトは、単なる静的ページではなく、ユーザー操作、データ更新、管理者機能、履歴、ランキング、通知、将来的な運用まで関わる。
そのため、テストはかなり重要なテーマになっている。
2. PlaywrightによるE2Eテストはすでに使っている
現時点で、E2Eテストにはすでに Playwright を使っている。
つまり、「これからE2Eテストを導入するかどうか」という段階ではない。
すでに、画面操作ベースで主要な導線を確認する方向には進んでいる。
Playwrightを使うことで、ブラウザ上で実際のユーザー操作に近い形の確認ができる。
たとえば、以下のような確認が対象になる。
画面が表示されるか
ボタンやリンクが機能するか
主要導線を通れるか
入力・保存・表示が成立するか
画面遷移が想定通りか
エラーで落ちないか
スマホ相当の表示で大きく崩れないか
これはかなり重要である。
単体テストでは、個別の関数や処理は確認できる。
しかし、実際にユーザーが画面を操作したときに流れが成立するかは、E2Eテストで確認した方が分かりやすい。
3. ただし、E2Eテストを増やしすぎる問題もある
一方で、E2Eテストは便利だが、増やしすぎると重くなる。
これはすでに意識している課題である。
E2Eテストは、実際のブラウザ操作に近い確認ができる反面、以下のような問題もある。
実行に時間がかかる
テストが増えるとメンテナンスが重くなる
UI変更でテストが壊れやすい
テストコード自体の修正が必要になる
本質的でない表示変更で失敗することがある
開発スピードを落とす可能性がある
そのため、何でもPlaywrightで自動化すればよいとは考えていない。
重要なのは、どの導線をE2Eで守るかである。
4. E2Eで守るべきもの
現時点で、Playwrightで優先して守るべきなのは、サービス全体に影響する主要導線である。
具体的には、以下のようなものを優先したい。
| 優先度 | E2Eで確認したい対象 |
|---|---|
| 高 | 新規登録・ログイン後の主要導線 |
| 高 | メイン画面が表示されること |
| 高 | 基本操作の一連の流れ |
| 高 | 重要画面で致命的なエラーが出ないこと |
| 高 | データ作成・更新・表示の基本流れ |
| 中 | 管理者画面の基本操作 |
| 中 | スマホ幅での主要導線 |
| 中 | 空データ時の表示 |
| 中 | エラー時の最低限の復帰導線 |
| 低 | 細かい文言・装飾・演出 |
E2Eテストは、サービスの骨格を守るために使う。
逆に、細かい文言やデザインの微調整までE2Eで厳密に見ると、テストが壊れやすくなる。
そこは人手確認やレビューで補う方がよい。
5. 自動化できるものと、人手で見るべきもの
テスト自動化は重要だが、すべてを自動化できるわけではない。
Playwrightで確認しやすいのは、主に以下である。
画面が開く
ボタンが押せる
入力できる
保存される
遷移できる
エラーが出ない
表示要素が存在する
権限によって表示が変わる
一方で、人手で見た方がよいものもある。
初回ユーザーが本当に迷わないか
画面の雰囲気が伝わるか
情報量が多すぎないか
操作していて楽しいか
文言が自然か
スマホでストレスがないか
サービスの魅力が伝わるか
また使いたいと思えるか
このあたりは、自動テストでは判断しにくい。
E2Eテストは「動くか」を見るには強い。
しかし、「使いたいと思うか」「分かりやすいか」「面白いか」は、人間が見る必要がある。
6. 現状の課題
現時点でのテスト面の課題は、主に以下である。
6.1 E2Eテストの対象範囲を広げすぎないこと
Playwrightを使っているからこそ、どこまで自動化するかを慎重に決める必要がある。
何でもE2Eに入れると、開発が重くなる。
そのため、まずは以下に絞りたい。
壊れると致命的な導線
毎回手動確認すると大変な導線
リリース判定で必ず確認したい導線
データ破損や権限ミスにつながる導線
逆に、頻繁に変わるUIや、体験の良し悪しに関わる部分は、人手確認を併用する。
6.2 テストデータの整備
E2Eテストでは、テストデータも重要になる。
データがない状態、データがある状態、権限が違う状態、管理者状態、通常ユーザー状態などをどう用意するか。
ここが曖昧だと、テストが安定しない。
今後は、以下を整理する必要がある。
E2E用のテストユーザー
管理者テストユーザー
初期データ
空データ状態
複数データ状態
異常系データ
テスト後のクリーンアップ方針
E2Eテストは、シナリオだけでなく、データ設計もセットで考える必要がある。
6.3 スマホ確認の扱い
今回のサービスでは、スマホ対応が重要になる。
Playwrightでも、ビューポートを変えてスマホ相当の確認はできる。
しかし、実際のスマホでの操作感までは完全には分からない。
そのため、スマホについては以下を組み合わせる必要がある。
Playwrightでスマホ幅の主要導線を確認する
PCブラウザのレスポンシブ確認を行う
実機スマホで人手確認する
プレオープンで実ユーザーの端末でも確認する
スマホは、画面サイズだけでなく、指で押しやすいか、スクロールしやすいか、情報量が多すぎないかも重要になる。
ここは人手確認がかなり重要になる。
6.4 AI生成コードの確認
AIを使って開発しているため、AIが生成したコードが意図通りかを確認する必要がある。
E2Eテストは、その確認にも役立つ。
ただし、E2Eが通ったからといって、すべて正しいわけではない。
内部ロジックが本当に正しいか
権限チェックが十分か
想定外の操作に耐えられるか
データ整合性が保たれるか
将来拡張に耐えられるか
こうした部分は、コードレビューや仕様確認も必要になる。
つまり、Playwrightは重要だが、品質保証の一部であって全部ではない。
7. プレオープンをテスト計画に組み込む
正式公開前には、プレオープンのような形で、少人数に触ってもらうことも考えている。
これは単なる宣伝ではなく、テストの一部として位置づけたい。
プレオープンで確認したいのは、以下である。
初回ユーザーがどこで迷うか
どの画面で離脱するか
どの説明が足りないか
どの操作が分かりにくいか
スマホで問題なく使えるか
想定外の使い方をされないか
不具合報告が上がるか
サービスの価値が伝わるか
継続利用したいと思うか
作っている本人は、仕様を知っている。
だから、自然に操作できてしまう。
しかし、初めて触る人は違う。
そのギャップを確認するために、プレオープンは重要になる。
8. 今後詰めるべきテスト計画
今後は、テスト計画をさらに具体化する必要がある。
特に整理すべきなのは、以下である。
8.1 フェーズ別のテスト基準
一人用確認版、限定公開版、初期サービスイン版では、求める品質水準が違う。
| フェーズ | テストの目的 |
|---|---|
| 一人用確認版 | 自分が通しで触り、中心体験が成立するか確認 |
| 限定公開版 | 少人数が迷わず使えるか、致命的不具合がないか確認 |
| 初期サービスイン | 一般ユーザーが使っても破綻しないか確認 |
| 収益化段階 | 課金・運用・問い合わせ対応まで含めて確認 |
最初から正式公開レベルの品質を求めすぎると、開発が止まる。
ただし、致命的な不具合を放置したまま公開するわけにもいかない。
フェーズごとに、どこまで確認するかを決める必要がある。
8.2 自動テストと人手テストの分担
自動テストと人手テストの役割分担も明確にしたい。
| 確認内容 | 方法 |
|---|---|
| 主要導線が通るか | Playwright |
| 重要画面が落ちないか | Playwright |
| データ保存・更新が成立するか | Playwright＋必要に応じて手動確認 |
| 権限チェックが効くか | Playwright＋コード確認 |
| スマホ幅で大きく崩れないか | Playwright＋実機確認 |
| 初回ユーザーが迷わないか | 人手確認 |
| 文言が自然か | 人手確認 |
| 魅力が伝わるか | 人手確認 |
| 継続したいと思えるか | プレオープン |
この分担を決めておくことで、テスト自動化に過度な期待をせず、必要な人手確認も計画に組み込める。
8.3 不具合報告の導線
プレオープンや限定公開を行うなら、不具合報告の導線も必要になる。
最低限、以下を受け取れるようにしたい。
どの画面で起きたか
何をしようとしたか
何が起きたか
使用端末
ブラウザ
発生日時
スクリーンショット
再現手順
最初から大きなサポートシステムを作る必要はない。
ただし、報告を受け取れる導線は必要である。
9. 現時点の方針
現時点でのテスト方針は、以下である。
PlaywrightによるE2Eテストはすでに活用している
ただし、E2Eの対象は主要導線に絞る
テストを増やしすぎて開発を重くしない
テストデータとテストユーザーを整理する
スマホはPlaywright確認と実機確認を併用する
UI/UXの良し悪しは人手確認を重視する
プレオープンを実ユーザーテストとして活用する
不具合報告導線を整備する
リリース判定チェックリストを作る
最終的な品質判断は人間が行う
10. 今回の結論
E2Eテストは、すでにPlaywrightを使っている。
その意味では、テスト自動化は未着手ではない。
すでに、画面操作ベースで主要導線を守る方向には進んでいる。
ただし、今後の課題は多い。
どこまでE2Eで確認するのか。
どこから人手で見るのか。
テストデータをどう作るのか。
スマホ実機確認をどう組み込むのか。
プレオープンをどうテスト計画に入れるのか。
リリース判定をどう行うのか。
これらを詰める必要がある。
自動テストは重要である。
しかし、自動テストだけでは、ユーザー体験の良し悪しは判断できない。
最終的には、Playwrightによる自動確認、人手による操作確認、プレオープンでの実ユーザー反応を組み合わせる必要がある。
月商1000万円を目指すなら、作るだけでは足りない。
安心して使えること、迷わず使えること、また使いたいと思えることが必要になる。
そのために、今後はテスト計画も本格的に詰めていきたい。
0 件のコメント:
コメントを投稿