| name | screen_strategy |
| description | Khung chiến lược test theo Screen archetype (List/Form/Detail...) — dùng trong /plan-tcs để viết Strategy Summary trước khi phân rã Component. Không dùng độc lập. |
Screen Strategy
Cách dùng
Skill này không dùng độc lập — chỉ được /plan-tcs gọi tới, sau khi đã liệt kê Component (bước 3b) và trước khi gắn Component Type/Risk Level.
Quy trình:
- Xác định archetype của Screen từ Summary + AC trong
analysis.md: List/Search, Form (Create/Edit), Detail/View, hoặc không khớp archetype nào → dùng Fallback.
- Đọc section tương ứng bên dưới.
- Viết Strategy Summary 3-5 bullet cho Screen đó — bắt buộc tham chiếu tên component hoặc AC ID thật đã xác định cho Screen này. Không paste nguyên bullet mẫu bên dưới mà không điều chỉnh.
- Self-check trước khi lưu: nếu bullet nào không gắn với component/AC cụ thể nào của Screen đang xử lý → viết lại, không hỏi user.
Archetype: List / Search
Screen hiển thị danh sách bản ghi, thường có Search/Filter/Sort/Pagination/Row Action.
Nguyên tắc:
- Test độc lập từng chức năng trước: Search, mỗi Filter riêng, Sort, Pagination, Row Action, Bulk Action — không test toàn bộ tổ hợp giữa chúng (tăng theo cấp số nhân, khó bảo trì).
- Chỉ chọn 1-2 tổ hợp có rủi ro/nghiệp vụ cao để test kết hợp (VD: Filter theo trạng thái quan trọng + Sort theo cột tiền tệ) — không cần test mọi tổ hợp.
- Permission: dùng Permission Matrix (Role × Action) thay vì lặp lại toàn bộ TC cho từng Role.
- Data Display: verify đúng số lượng bản ghi, đúng cột, mapping đúng dữ liệu, đúng định dạng ngày/số/tiền tệ/trạng thái.
- Boundary data: 0 record, 1 record, vừa đủ 1 trang, nhiều hơn 1 trang.
- Search: áp EP/BVA — tìm chính xác, tìm 1 phần, ký tự đặc biệt/SQL/script.
- Screen State: Loading, Empty Data, Error, Permission Denied.
- Refresh sau thao tác: danh sách cập nhật đúng sau Create/Update/Delete hoặc quay lại từ Detail.
Ví dụ bullet Strategy Summary (điều chỉnh theo component thật của Screen đang xử lý):
- Test độc lập [tên Search field], [tên Filter A], [tên Filter B], Sort theo [tên cột], Pagination — không test toàn bộ tổ hợp
- Tổ hợp ưu tiên: [Filter A] + Sort [cột tiền tệ] — do liên quan số liệu tài chính hiển thị (AC-XX)
- Permission Matrix cho [Role A/B/C] trên [Row Action tên thật] thay vì lặp TC theo role
- Boundary data cho [tên bảng/danh sách]: 0 record, 1 record, đủ 1 trang, nhiều trang
Archetype: Form (Create/Edit)
Screen nhập liệu để tạo mới hoặc chỉnh sửa bản ghi.
Nguyên tắc:
- Test field-level trước (mỗi field độc lập, xem
component_checklist Section A) — chỉ sau đó mới xét cross-field validation (field phụ thuộc field khác, VD Confirm Password phụ thuộc Password).
- Phân biệt rõ Create vs Edit nếu hành vi khác nhau (VD: Edit có sẵn giá trị cũ, field nào bị khóa không cho sửa).
- Submit/Cancel/Dirty state: rollback đúng khi Cancel, cảnh báo khi rời trang có thay đổi chưa lưu, double-submit không tạo 2 bản ghi.
- Không test tổ hợp toàn bộ field sai cùng lúc — mỗi field 1 nhóm TC validation riêng (đã có
component_checklist), Strategy Summary chỉ nêu field nào có phụ thuộc chéo cần test riêng.
Ví dụ bullet Strategy Summary:
- Field-level validation riêng cho [tên field 1], [tên field 2]... theo component_checklist
- Cross-field: [Field B] phụ thuộc [Field A] — test A đổi thì B reset/validate lại đúng
- Create vs Edit khác nhau ở: [nêu khác biệt thật, VD field X bị khóa khi Edit]
- Dirty-state: rời trang khi chưa lưu → confirm dialog; Cancel → không lưu thay đổi
Archetype: Detail / View
Screen hiển thị chi tiết 1 bản ghi, có thể kèm action.
Nguyên tắc:
- Data mapping: mọi field hiển thị đúng nguồn dữ liệu, đúng định dạng, không thiếu/thừa so với bản ghi gốc.
- Related-data consistency: nếu Detail hiển thị data từ bảng/module liên quan, verify đúng đồng bộ khi data gốc thay đổi.
- Action theo quyền: action trên Detail (Edit/Delete/Approve...) chỉ hiện/enable đúng theo Role — dùng Permission Matrix nếu nhiều role.
- Không tồn tại/đã xóa: truy cập Detail của record không tồn tại hoặc đã bị xóa → error rõ ràng, không crash.
Ví dụ bullet Strategy Summary:
- Data mapping đúng cho toàn bộ field trên [tên Screen], đối chiếu [tên AC/nguồn dữ liệu]
- Related-data: [tên data liên quan] đồng bộ đúng khi bản ghi gốc thay đổi
- Permission Matrix cho action [tên action thật] theo Role [A/B/C]
- Record không tồn tại/đã xóa → error rõ ràng, không crash
Fallback — Screen không khớp archetype nào
Dùng khi Screen không phải List/Form/Detail rõ ràng (Dashboard, Wizard nhiều bước, Settings...).
Nguyên tắc chung:
- Liệt kê các nhóm chức năng độc lập của Screen (không gộp chung).
- Test từng nhóm độc lập trước — không test toàn bộ tổ hợp giữa các nhóm.
- Chỉ chọn tổ hợp có rủi ro nghiệp vụ cao hoặc luồng sử dụng phổ biến để test kết hợp.
- Nếu có yếu tố phân quyền lặp lại nhiều nơi trên Screen → dùng Permission Matrix thay vì lặp TC theo role.
Ví dụ bullet Strategy Summary:
- Nhóm chức năng độc lập của [tên Screen]: [nhóm 1], [nhóm 2], [nhóm 3]
- Test độc lập từng nhóm trước, chỉ kết hợp [nhóm X] + [nhóm Y] do [lý do rủi ro/nghiệp vụ thật]
- Permission Matrix cho [Role thật] nếu phân quyền lặp ở nhiều nhóm chức năng
