playwright-qa

Playwright QA ワークフロー

QA エンジニア向け：テストコードを取り巻く作業です。何をテストするか、不具合をどう報告するか、手動テスト一式をどう自動化するか、テストをどう評価するかを説明します。

ガイドは4つです。Playwright API のガイドである core/ を基盤とし、内容を繰り返すのではなく、そちらへのリンクを掲載しています。

ガイド一覧

作業内容	ガイド
チケット／PRD／受け入れ条件から、テストケース、リスクの優先順位、ジェネレーター用のテスト計画を作成する	test-design.md
テスト失敗の原因がアプリのバグ、テストのバグ、フレークのどれかを見極め、バグを報告し、その間テストをどう扱うかを判断する	bug-reports.md
手動テストケースまたは CSV エクスポートから、ケース ID 付きの Playwright テスト仕様を作成する	manual-to-automated.md
Playwright テストや PR をレビューし、リントルールを確認し、テストが失敗することを実証する	test-review.md

基本ルール

1. 境界条件と異常系を最初に確認する：バグは正常系ではなく、ルールの境界に潜んでいます。
2. 証明できる最も低いレイヤーを使う：ルールは API レベルで、連携と重要なフローは E2E でテストします。
3. 報告する前に分類する：アプリのバグ、テストのバグ、フレーク、環境のいずれかを分類します。通常はトレースを見れば判断できます。
4. 発生頻度は数値で表す：--repeat-each=20 を使えば N/20 で示せます。「ときどき」ではありません。
5. 既知のバグには、課題へのリンク付きで test.fail() を使う：テストを削除したり、アサーションを緩めたりしてはいけません。
6. 失敗しないテストでは何も守れません：一度機能を壊し、テストが失敗することを確認します。
7. 自動化したテストにはケース ID を残す：結果を手動テスト一式に対応付けられます。