Testing & Debugging Skills

Viết test case (TC) trên FARE từ spec đã có — mỗi AC của userstory / mỗi flow của usecase → n TC theo kỹ thuật ISTQB (positive / negative / boundary / equivalenceclass / statetransition / errorguessing). Tạo doc testcase container và batch createtestcases. Dùng khi QA nhận spec đã ready hoặc khi PM bàn giao task type=TEST.

Review backlog định kỳ — quét task lệch trạng thái (INPROGRESS không activity, DONE chưa verify, TODO không owner / quá hạn), bug triage (sắp xếp severity / assign), phát hiện task mồ côi (không module / không spec). Đề xuất hành động sửa và CHỜ User chốt — KHÔNG tự đổi trạng thái hàng loạt.

Khi TC fail (hoặc QA phát hiện bug ngoài TC), format báo cáo reproducible (steps + expected vs actual + env + evidence), phân biệt severity (mức nghiêm trọng kỹ thuật) ↔ priority (mức ưu tiên xử lý), HỎI USER trước khi createtasks(type=BUG) (rule §5), gắn linkedtaskid về TC fail + task feature gốc để truy nguồn.

Xử lý yêu cầu thay đổi (change request) trên một spec đã có. Đọc bản đã duyệt, đánh giá impact (UC/US/test/task liên quan), sửa nội dung trên draft (KHÔNG ghi đè bản approved), log change, đề xuất submit cho duyệt. Dùng khi User báo "khách đổi yêu cầu", "yêu cầu mới phát sinh trên spec A", hoặc khi cần re-version một tài liệu đã chốt.

Khám phá ngữ cảnh đủ sâu cho một artifact FARE (tài liệu, đặc tả/SRS, ERD, task, test case, màn hình UI) TRƯỚC KHI phân tích, đánh giá hay tách tài liệu. Dùng khi được yêu cầu đọc/phân tích/đánh giá một tài liệu FARE, kiểm tra "tài liệu này có vấn đề gì", truy nguồn một yêu cầu, hoặc chuẩn bị tách/chuẩn hóa tài liệu. Dạy agent dùng MCP fare tools theo từng tầng và xuất ra Bản đồ ngữ cảnh dùng lại được cho các skill phía sau.

Làm sạch FORM của tài liệu nháp local (bảng HTML lồng rối → markdown sạch) trước khi đẩy lên FARE. Giữ nguyên 100% nội dung. Dùng khi User thấy một bản nháp chưa gọn và muốn tối ưu lại.

Tách một tài liệu nguyên khối thành nhiều tài liệu FARE — xử lý từng phần, nháp local trước khi đẩy, trung thực với nguồn.

Ước lượng effort cho Module/Submodule/Function (Function Point analysis) bằng cách gán đúng ID attribute (complexity 1-5, scope 6-10, clarity 11-15) và đối chiếu effort-matrix. Phân biệt rõ module.effortest (man-days) ↔ task.esteffort (giờ). Dùng khi PM cần ước lượng để xếp sprint, hoặc khi BA chia cây module có dữ liệu effort từ nguồn.

Quản Epic (initiative cross-module) trên FARE — tạo Epic mới, đổi status (planned/inprogress/atrisk/done/archived), gán owner + dates, bulk assign tasks (max 500), close khi 100% task DONE (rule cứng). Vai PM. Phân biệt Epic ≠ Module ≠ Campaign (xem fare-mcp-integration).

TRƯỚC khi sửa 1 symbol (function/class/method), quét blast radius qua FARE code intelligence — codequery (tìm theo concept), codecontext (360° symbol), codeimpact (upstream/downstream), coderoutemap (luồng API). Phân loại rủi ro d=1/2/3; HIGH/CRITICAL → báo User & chờ chốt trước khi sửa. Chỉ dành cho project đã có code index trên FARE.

Dùng MCP của FARE đúng & an toàn — bản đồ tới tài liệu canonical của FARE, các bẫy không hiển nhiên và pattern bắt buộc.

Dựng / hoàn thiện cây Module → Submodule → Function 3 cấp cho một phạm vi nghiệp vụ. Mục đích BA-light là có chỗ để gắn spec (moduleid cấp Function) — KHÔNG sa đà ước lượng effort chi tiết (đó là vai PM). Dùng khi spec chưa có moduleid để gắn, hoặc cần xếp lại cây module cho khớp nghiệp vụ.

Chấm / kiểm toán một cây plan item (theme › epic › story) ĐÃ CÓ trên FARE theo rubric chất lượng — mỗi story/epic/theme + cấu trúc tổng thể đạt chuẩn chưa (nghiệm thu được, đúng trục giá trị, tầng thật không giả, đủ 3 tầng). Báo cáo điểm + đề xuất sửa, CHỜ User chốt — KHÔNG tự restructure. Dùng trước go-live / handoff PM, hoặc khi nghi cây phân rã sai. Dựng cây mới → fare-plan-breakdown.

Hiểu & vận hành mô hình Plan của FARE — master plan vs month plan, version DRAFT vs PUBLIC, cách tạo / cập nhật month plan cho 1 sprint mà KHÔNG động vào master. Agent CHỈ chuẩn bị DRAFT — quyết publish (PUBLIC) là việc của User.

Sau khi dev code xong, TỰ kiểm trước khi push & handoff sang QA — đối chiếu DoD trong task description, đối chiếu TC linked, set metastatus="VERIFYING" + addcomment evidence (commit hash, file đụng, TC nào đã pass tay, link branch/PR). KHÔNG tự set DONE — đó là sau khi QA verify hoặc User confirm. KHÔNG tự code; chỉ xác minh & sync metadata.

Viết MỚI đặc tả nghiệp vụ trên FARE — Use Case, User Story, BRD/SRS/PRD/requirement (richtext) và Glossary — từ một yêu cầu nghiệp vụ. Dùng khi User cần tạo đặc tả từ đầu, KHÔNG phải tách tài liệu có sẵn.

Chia 1 Function (đã có spec) thành n task implementable cho dev pickup. Dùng khi PM nhận một function có spec đầy đủ (UC/US/SRS gắn moduleid) và cần tạo task BE/FE/DB/test/infra sẵn sàng cho dev. KHÔNG tự code, KHÔNG tự verify.

Pickup 1 task từ backlog đúng quy trình — chọn task hợp lý (priority, blocker, assignee), đọc HẾT spec/ERD/API doc/Figma trỏ tới trong description, set metastatus="INPROGRESS" + addcomment mô tả phạm vi sắp làm. Dùng đầu mỗi phiên dev. KHÔNG tự code; chỉ chuẩn bị bối cảnh.

Chạy verify cho test cases trên FARE — ghi verifyhistory atomic qua updatetestcase(verify={...}), cập nhật verifystatus (passed/failed/blocked/skipped); đối chiếu task type=TEST của PM (đủ điều kiện DONE khi mọi TC linked passed). KHÔNG tự fix code khi fail (Dev), KHÔNG tự sửa TC khi thấy sai (QA-author).

Xây ma trận truy vết requirement ↔ usecase ↔ userstory ↔ testcase ↔ module/function ↔ task cho một phạm vi (project / module / 1 doc). Phát hiện gap (yêu cầu không có UC, UC không có AC, function không có test, task không có doc). Dùng khi User muốn biết "yêu cầu nào chưa được phủ", trước khi go-live / bàn giao QA.