generate-application-test-plan
starsforks
How to install generate-application-test-plan?
anhtester/codex-testing-kit/generate-application-test-plan
$npx -y skills add anhtester/codex-testing-kit --skill generate-application-test-planKhám phá ứng dụng web, sinh test plan và test scenarios. Hỗ trợ 2 mode — PLAN (chỉ test plan) và FULL (test plan + automation skeleton).
SKILL.md
| 1 | # Workflow: Khám Phá Ứng Dụng & Sinh Test Plan |
| 2 | |
| 3 | > **BẮT BUỘC (MANDATORY SKILL):** Bạn PHẢI nạp và đọc kỹ nội dung của skill **`$qa-automation-engineer`** (tại `.agents/skills/qa-automation-engineer/SKILL.md`) trước khi bắt đầu. Ngoài ra, tham khảo thêm skill **`$requirements-analyzer`** và **`$ui-debug-agent`** để hỗ trợ phân tích UI. |
| 4 | |
| 5 | Workflow này giúp agent tự động khám phá một ứng dụng web, phân tích cấu trúc, xác định các modules/user flows quan trọng, và sinh ra Test Plan hoàn chỉnh. |
| 6 | |
| 7 | ## ⚠️ Nguyên tắc thực thi |
| 8 | |
| 9 | - **Tất cả output bằng Tiếng Việt** |
| 10 | - **KHÔNG đoán** cấu trúc app — phải inspect DOM thực tế qua MCP/browser tools |
| 11 | - **Phải chờ user xác nhận** scope tại Bước 2 trước khi sinh chi tiết |
| 12 | - Nếu user chưa cung cấp URL → hỏi trước khi bắt đầu |
| 13 | |
| 14 | ## 2 Chế độ (Mode) |
| 15 | |
| 16 | | Mode | Khi nào sử dụng | Output | |
| 17 | |---|---|---| |
| 18 | | **PLAN** (mặc định) | User cần khám phá app, lập test plan, xác định scenarios | Modules, User Flows, Test Scenarios, Priority | |
| 19 | | **FULL** | User yêu cầu thêm automation skeleton hoặc nói "full automation suite" | Như PLAN + Manual Test Cases + Automation Skeleton (POM + Test classes) | |
| 20 | |
| 21 | > Nếu user nói "generate full automation suite", "bootstrap automation", hoặc yêu cầu code → tự động chuyển sang **Mode FULL**. |
| 22 | |
| 23 | ## Các bước thực hiện |
| 24 | |
| 25 | ### Bước 1: Tiếp nhận & Khám phá ứng dụng (Recon) |
| 26 | |
| 27 | 1. Nhận URL ứng dụng từ user |
| 28 | 2. Sử dụng **MCP browser tools** (Playwright MCP) để mở ứng dụng: |
| 29 | - `browser_navigate` → URL |
| 30 | - `browser_resize(1920, 1080)` → desktop viewport |
| 31 | - `browser_snapshot` → thu thập cấu trúc DOM |
| 32 | 3. Khám phá **navigation menus**, sidebar, header để xác định các modules chính |
| 33 | 4. Lần lượt truy cập từng module chính, dùng `browser_snapshot` để ghi nhận: |
| 34 | - Tên module / trang |
| 35 | - Các thành phần UI chính (forms, tables, buttons, modals) |
| 36 | - Các action có thể thực hiện (CRUD, search, filter, export...) |
| 37 | 5. Nếu app yêu cầu đăng nhập → hỏi user cung cấp credentials hoặc dùng fixture sẵn có |
| 38 | |
| 39 | ### Bước 2: Phân tích & Xác nhận scope (Analysis — CHECKPOINT) |
| 40 | |
| 41 | 1. Tổng hợp kết quả khám phá thành danh sách: |
| 42 | - **Modules đã phát hiện** (tên, mô tả ngắn, số lượng features) |
| 43 | - **User Flows chính** (Happy Path cho mỗi module) |
| 44 | - **Dependencies** giữa các modules (nếu có) |
| 45 | 2. Đánh giá **Risk Level** sơ bộ cho mỗi module: |
| 46 | - 🔴 **High Risk** — Module core, ảnh hưởng nhiều user, logic phức tạp |
| 47 | - 🟡 **Medium Risk** — Module phụ trợ, sử dụng thường xuyên |
| 48 | - 🟢 **Low Risk** — Module ít sử dụng, ít thay đổi |
| 49 | 3. **⏸️ DỪNG LẠI — Trình bày cho user review:** |
| 50 | - Danh sách modules + risk level |
| 51 | - User flows đã xác định |
| 52 | - Hỏi user: "Bạn muốn tập trung vào modules nào? Có flow nào cần bổ sung?" |
| 53 | 4. **Chờ user xác nhận** scope trước khi sang Bước 3 |
| 54 | |
| 55 | ### Bước 3: Sinh Test Scenarios & Priority |
| 56 | |
| 57 | 1. Với mỗi module/flow đã được user xác nhận, sinh test scenarios: |
| 58 | - **Happy Path** — luồng chính thành công |
| 59 | - **Negative Path** — nhập sai, thiếu dữ liệu, lỗi validation |
| 60 | - **Edge Cases** — boundary values, concurrent access, empty states |
| 61 | 2. Gán **Priority** cho mỗi scenario dựa trên Risk Level: |
| 62 | - **P1 (Critical)** — Core flows, regression blockers, dữ liệu nhạy cảm |
| 63 | - **P2 (High)** — Main features, tính năng sử dụng thường xuyên |
| 64 | - **P3 (Medium)** — Secondary features, UI/UX checks |
| 65 | - **P4 (Low)** — Nice-to-have, cosmetic checks |
| 66 | |
| 67 | ### Bước 4: Đóng gói Test Plan (Output — Mode PLAN) |
| 68 | |
| 69 | 1. Tạo **artifact** `test_plan.md` với cấu trúc: |
| 70 | - **Tổng quan ứng dụng** — mục đích, tech stack (nếu xác định được), URL |
| 71 | - **Danh sách Modules** — bảng gồm: Module, Mô tả, Risk Level, Số scenarios |
| 72 | - **User Flows** — mô tả từng flow chính (steps) |
| 73 | - **Test Scenarios** — bảng: `| ID | Module | Scenario | Priority | Loại (Happy/Negative/Edge) |` |
| 74 | - **Automation Candidates** — đánh dấu scenarios nào nên tự động hóa và lý do |
| 75 | 2. Nếu user chọn **Mode PLAN** → **KẾT THÚC** tại đây |
| 76 | |
| 77 | ### Bước 5: Sinh Manual Test Cases (Mode FULL) |
| 78 | |
| 79 | > Chỉ thực hiện khi ở **Mode FULL** |
| 80 | |
| 81 | 1. Chuyển test scenarios (Bước 3) thành **manual test cases đầy đủ**: |
| 82 | - TC ID, Module, Test Title, Pre-conditions, Test Steps, Expected Results, Test Data, Priority |
| 83 | 2. Test Data phải **cụ thể** (không placeholder chung chung) |
| 84 | 3. Xuất dưới dạng bảng Markdown trong artifact |
| 85 | |
| 86 | ### Bước 6: Sinh Automation Skeleton (Mode FULL) |
| 87 | |
| 88 | > Chỉ thực hiện khi ở **Mode FULL** |
| 89 | |
| 90 | 1. Xác định **tech stack** automation (hỏi user nếu chưa rõ): |
| 91 | - Mặc định: Playwright + TypeScript (hoặc Selenium + Java theo preference) |
| 92 | 2. Sinh **Page Object classes** cho mỗi module: |
| 93 | - Locator thu thập từ DOM thực tế (Bước 1), KHÔNG đoán |
| 94 | - Methods tương tác rõ nghĩa |
| 95 | 3. Sinh **Test class skeleton** cho top-priority scenarios (P1, P2) |
| 96 | 4. Đảm bảo tuân thủ **POM pattern** và **locator strategy** theo rules |
| 97 | |
| 98 | ## Output |
| 99 | |
| 100 | ### Mode PLAN |
| 101 | - Artifact `test_plan.md` gồm: App overview, Modules, U |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
