generate-application-test-plan
Skill28 starsChanged 4 months agoMITView on GitHub
Khá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).
In this repository26 other files it gives its agents.
- AGENTS.mdAGENTS.md
- analyze-flaky-testsSkill
- analyze-requirement-documentSkill
- fetch-jira-requirementsSkill
- flaky-test-analyzerSkill
- framework-architectSkill
- generate-api-tests-from-swaggerSkill
- generate-automation-frameworkSkill
- generate-automation-from-testcasesSkill
- generate-automation-from-ui-flowSkill
- generate-combinatorial-test-dataSkill
- generate-cross-module-test-planSkill
- generate-locatorSkill
- generate-manual-testcases-rbtSkill
- generate-requirements-from-websiteSkill
- generate-testcases-from-requirementsSkill
- generate-test-dataSkill
- import-test-results-xraySkill
- jira-integrationSkill
- locator-healer-agentSkill
- qa-automation-engineerSkill
- rbt-manual-testingSkill
- requirements-analyzerSkill
- smart-locator-agentSkill
- test-data-generatorSkill
- ui-debug-agentSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 88
Test Data phải cụ thể (không placeholder chung chung)
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Workflow: Khám Phá Ứng Dụng & Sinh Test Plan
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-analyzervà$ui-debug-agentđể hỗ trợ phân tích UI.
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.
⚠️ Nguyên tắc thực thi
- Tất cả output bằng Tiếng Việt
- KHÔNG đoán cấu trúc app — phải inspect DOM thực tế qua MCP/browser tools
- Phải chờ user xác nhận scope tại Bước 2 trước khi sinh chi tiết
- Nếu user chưa cung cấp URL → hỏi trước khi bắt đầu
2 Chế độ (Mode)
| Mode | Khi nào sử dụng | Output |
| 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 |
| 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) |
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.
Các bước thực hiện
Bước 1: Tiếp nhận & Khám phá ứng dụng (Recon)
- Nhận URL ứng dụng từ user
- Sử dụng MCP browser tools (Playwright MCP) để mở ứng dụng:
browser_navigate→ URLbrowser_resize(1920, 1080)→ desktop viewportbrowser_snapshot→ thu thập cấu trúc DOM
- Khám phá navigation menus, sidebar, header để xác định các modules chính
- Lần lượt truy cập từng module chính, dùng
browser_snapshotđể ghi nhận:- Tên module / trang
- Các thành phần UI chính (forms, tables, buttons, modals)
- Các action có thể thực hiện (CRUD, search, filter, export...)
- 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ó
Bước 2: Phân tích & Xác nhận scope (Analysis — CHECKPOINT)
- Tổng hợp kết quả khám phá thành danh sách:
- Modules đã phát hiện (tên, mô tả ngắn, số lượng features)
- User Flows chính (Happy Path cho mỗi module)
- Dependencies giữa các modules (nếu có)
- Đánh giá Risk Level sơ bộ cho mỗi module:
- 🔴 High Risk — Module core, ảnh hưởng nhiều user, logic phức tạp
- 🟡 Medium Risk — Module phụ trợ, sử dụng thường xuyên
- 🟢 Low Risk — Module ít sử dụng, ít thay đổi
- ⏸️ DỪNG LẠI — Trình bày cho user review:
- Danh sách modules + risk level
- User flows đã xác định
- Hỏi user: "Bạn muốn tập trung vào modules nào? Có flow nào cần bổ sung?"
- Chờ user xác nhận scope trước khi sang Bước 3
Bước 3: Sinh Test Scenarios & Priority
- Với mỗi module/flow đã được user xác nhận, sinh test scenarios:
- Happy Path — luồng chính thành công
- Negative Path — nhập sai, thiếu dữ liệu, lỗi validation
- Edge Cases — boundary values, concurrent access, empty states
- Gán Priority cho mỗi scenario dựa trên Risk Level:
- P1 (Critical) — Core flows, regression blockers, dữ liệu nhạy cảm
- P2 (High) — Main features, tính năng sử dụng thường xuyên
- P3 (Medium) — Secondary features, UI/UX checks
- P4 (Low) — Nice-to-have, cosmetic checks
Bước 4: Đóng gói Test Plan (Output — Mode PLAN)
- Tạo artifact
test_plan.mdvới cấu trúc:- Tổng quan ứng dụng — mục đích, tech stack (nếu xác định được), URL
- Danh sách Modules — bảng gồm: Module, Mô tả, Risk Level, Số scenarios
- User Flows — mô tả từng flow chính (steps)
- Test Scenarios — bảng:
| ID | Module | Scenario | Priority | Loại (Happy/Negative/Edge) | - Automation Candidates — đánh dấu scenarios nào nên tự động hóa và lý do
- Nếu user chọn Mode PLAN → KẾT THÚC tại đây
Bước 5: Sinh Manual Test Cases (Mode FULL)
Chỉ thực hiện khi ở Mode FULL
- Chuyển test scenarios (Bước 3) thành manual test cases đầy đủ:
- TC ID, Module, Test Title, Pre-conditions, Test Steps, Expected Results, Test Data, Priority
- Test Data phải cụ thể (không placeholder chung chung)
- Xuất dưới dạng bảng Markdown trong artifact
Bước 6: Sinh Automation Skeleton (Mode FULL)
Chỉ thực hiện khi ở Mode FULL
- Xác định tech stack automation (hỏi user nếu chưa rõ):
- Mặc định: Playwright + TypeScript (hoặc Selenium + Java theo preference)
- Sinh Page Object classes cho mỗi module:
- Locator thu thập từ DOM thực tế (Bước 1), KHÔNG đoán
- Methods tương tác rõ nghĩa
- Sinh Test class skeleton cho top-priority scenarios (P1, P2)
- Đảm bảo tuân thủ POM pattern và locator strategy theo rules
Output
Mode PLAN
- Artifact
test_plan.mdgồm: App overview, Modules, User Flows, Test Scenarios (có Priority), Automation Candidates
Mode FULL
- Tất cả output của Mode PLAN, cộng thêm:
- Manual Test Cases (bảng Markdown)
- Page Object classes
- Test class skeletons
- Assertions validating expected behavior
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

