@relipa/ai-flow-kit 0.1.3 → 0.1.4-beta.0

package/custom/skills/test-skills/categories/01-test-design/01.01.boundary-value-analysis.md

@@ -0,0 +1,30 @@
+# 01.01. Boundary Value Analysis (Phân tích giá trị biên)
+
+## Mục đích
+Đảm bảo kiểm tra các điểm tới hạn (ranh giới) nơi lỗi thường xảy ra nhất. Kỹ thuật này giúp tối ưu hóa số lượng test case bằng cách tập trung vào các giá trị tại biên của các phân vùng tương đương, thay vì kiểm tra mọi giá trị trong dải.
+
+## Kiến thức cần có
+- Khái niệm về Phân vùng tương đương (Equivalence Partitioning).
+- Hiểu biết về dải giá trị (range), độ dài (length) và các kiểu dữ liệu (data types).
+- Logic nghiệp vụ và các điều kiện ràng buộc của hệ thống.
+
+## Quy trình thực hiện
+1. **Xác định tham số:** Liệt kê các tham số đầu vào hoặc điều kiện cần kiểm tra.
+2. **Xác định dải giá trị:** Xác định dải giá trị hợp lệ cho từng tham số (Ví dụ: Tuổi từ 18 đến 60).
+3. **Xác định các giá trị biên:** Tìm các giá trị tối thiểu (Min) và tối đa (Max).
+4. **Chọn các giá trị kiểm thử:**
+   - Tại biên: Min, Max.
+   - Sát biên (hợp lệ): Min+1, Max-1.
+   - Ngoài biên (không hợp lệ): Min-1, Max+1.
+5. **Kiểm tra độ dài:** Đối với chuỗi, kiểm tra độ dài 0 (rỗng), 1, Max, Max+1.
+
+## Checklist
+- [ ] Đã xác định đúng giá trị Min và Max dựa trên yêu cầu (SRS)?
+- [ ] Đã bao gồm các giá trị biên hợp lệ (Min, Max)?
+- [ ] Đã bao gồm các giá trị biên không hợp lệ (Min-1, Max+1)?
+- [ ] Đã xem xét các trường hợp đặc biệt như rỗng (empty), null, hoặc khoảng trắng (space)?
+- [ ] Đã kiểm tra giới hạn vật lý của kiểu dữ liệu (ví dụ: giá trị lớn nhất của Integer)?
+
+## Output mong đợi
+- Danh sách các giá trị biên cụ thể cho từng tham số.
+- Các Test case bao phủ đầy đủ các kịch bản tại ranh giới (hợp lệ và không hợp lệ).

package/custom/skills/test-skills/categories/01-test-design/01.02.equivalence.partitioning.md

@@ -0,0 +1,27 @@
+# 01.02. Equivalence Partitioning (Phân vùng tương đương)
+
+## Mục đích
+Chia dữ liệu đầu vào thành các nhóm (phân vùng) mà hệ thống xử lý theo cách tương tự nhau. Kỹ thuật này giúp giảm số lượng test case cần thực thi mà vẫn đảm bảo độ bao phủ tối đa bằng cách chỉ cần kiểm tra một giá trị đại diện cho mỗi vùng.
+
+## Kiến thức cần có
+- Hiểu về các loại dữ liệu đầu vào (String, Number, Date, v.v.).
+- Hiểu biết về logic nghiệp vụ và các quy tắc xử lý của ứng dụng.
+- Khả năng phân loại dữ liệu thành các nhóm hợp lệ và không hợp lệ.
+
+## Quy trình thực hiện
+1. **Xác định đầu vào:** Liệt kê tất cả các trường dữ liệu hoặc điều kiện đầu vào của tính năng.
+2. **Chia phân vùng:**
+   - **Vùng hợp lệ (Valid):** Các giá trị mà hệ thống phải chấp nhận và xử lý đúng.
+   - **Vùng không hợp lệ (Invalid):** Các giá trị mà hệ thống phải từ chối hoặc báo lỗi.
+3. **Chọn giá trị đại diện:** Chọn ít nhất một giá trị tiêu biểu từ mỗi phân vùng để đưa vào test case.
+4. **Thiết kế test case:** Mỗi test case nên bao phủ một hoặc nhiều vùng hợp lệ, nhưng mỗi vùng không hợp lệ nên được kiểm tra bởi một test case riêng biệt để tránh lỗi bị che lấp.
+
+## Checklist
+- [ ] Đã xác định đầy đủ các vùng hợp lệ dựa trên đặc tả?
+- [ ] Đã xác định đầy đủ các vùng không hợp lệ (sai kiểu dữ liệu, ngoài dải)?
+- [ ] Có vùng nào bị chồng chéo (overlapping) hoặc bị bỏ sót không?
+- [ ] Mỗi phân vùng đã có ít nhất một giá trị đại diện cụ thể?
+
+## Output mong đợi
+- Bảng phân vùng tương đương (Equivalence Class Table).
+- Danh sách các Test case đại diện cho tất cả các phân vùng đã xác định.

package/custom/skills/test-skills/categories/01-test-design/01.03.decision-table.md

@@ -0,0 +1,26 @@
+# 01.03. Decision Table (Bảng quyết định)
+
+## Mục đích
+Hệ thống hóa việc kiểm thử các quy tắc nghiệp vụ phức tạp, nơi kết quả phụ thuộc vào sự kết hợp của nhiều điều kiện đầu vào khác nhau. Kỹ thuật này đảm bảo mọi tổ hợp logic đều được xem xét và không có kịch bản nào bị bỏ sót.
+
+## Kiến thức cần có
+- Logic Boolean (AND, OR, NOT).
+- Hiểu sâu về các quy tắc nghiệp vụ (Business Rules) và sự phụ thuộc giữa các điều kiện.
+- Khả năng phân tích hệ quả (Actions) từ các nguyên nhân (Conditions).
+
+## Quy trình thực hiện
+1. **Liệt kê Điều kiện (Conditions):** Xác định tất cả các yếu tố đầu vào ảnh hưởng đến kết quả.
+2. **Liệt kê Hành động (Actions):** Xác định tất cả các kết quả hoặc phản ứng có thể xảy ra của hệ thống.
+3. **Xây dựng ma trận tổ hợp:** Tạo các cột tương ứng với tất cả các kết hợp của điều kiện (T/F hoặc Yes/No).
+4. **Xác định hành động cho từng cột:** Điền kết quả mong đợi cho mỗi tổ hợp điều kiện.
+5. **Tối ưu hóa bảng:** Loại bỏ các cột không thể xảy ra trong thực tế hoặc gộp các cột có cùng hành động nếu có điều kiện không ảnh hưởng (Don't care).
+
+## Checklist
+- [ ] Đã liệt kê đầy đủ tất cả các điều kiện đầu vào?
+- [ ] Đã xác định chính xác các hành động đầu ra tương ứng?
+- [ ] Các tổ hợp logic đã bao quát toàn bộ các trường hợp có thể xảy ra?
+- [ ] Đã xử lý hoặc loại bỏ các kịch bản "bất khả thi" một cách hợp lý?
+
+## Output mong đợi
+- Bảng quyết định (Decision Table) hoàn chỉnh.
+- Tập hợp các Test case được trích xuất trực tiếp từ các quy tắc (Rules) trong bảng.

package/custom/skills/test-skills/categories/01-test-design/01.04.state.transition.md

@@ -0,0 +1,26 @@
+# 01.04. State Transition (Chuyển đổi trạng thái)
+
+## Mục đích
+Kiểm tra khả năng của hệ thống trong việc chuyển đổi giữa các trạng thái khác nhau theo đúng quy trình nghiệp vụ. Kỹ thuật này đặc biệt quan trọng cho các hệ thống có vòng đời đối tượng phức tạp (như quản lý đơn hàng, quy trình phê duyệt).
+
+## Kiến thức cần có
+- Khái niệm về Trạng thái (State) và Sự kiện (Event/Trigger).
+- Hiểu biết về vòng đời của đối tượng trong hệ thống.
+- Kỹ năng vẽ hoặc đọc Sơ đồ chuyển đổi trạng thái (State Transition Diagram).
+
+## Quy trình thực hiện
+1. **Xác định các trạng thái:** Liệt kê tất cả các trạng thái mà đối tượng có thể trải qua (vd: Mới, Đang xử lý, Hoàn thành, Đã hủy).
+2. **Xác định sự kiện kích hoạt:** Tìm các hành động hoặc điều kiện gây ra sự thay đổi từ trạng thái này sang trạng thái khác.
+3. **Xây dựng Sơ đồ/Bảng chuyển đổi:** Mô tả các đường đi hợp lệ giữa các trạng thái.
+4. **Phân tích chuyển đổi không hợp lệ:** Xác định các sự kiện không được phép xảy ra tại một trạng thái nhất định (vd: Đã hủy thì không thể Hoàn thành).
+5. **Thiết kế Test case:** Bao phủ các luồng đi qua mọi trạng thái và kiểm tra các đường chuyển đổi sai.
+
+## Checklist
+- [ ] Đã bao phủ tất cả các trạng thái có thể có của đối tượng?
+- [ ] Đã kiểm tra tất cả các chuyển đổi hợp lệ (Positive paths)?
+- [ ] Đã kiểm tra các chuyển đổi không hợp lệ để đảm bảo hệ thống chặn đúng (Negative paths)?
+- [ ] Đã kiểm tra trạng thái ban đầu (Initial state) và trạng thái kết thúc (Final state)?
+
+## Output mong đợi
+- Sơ đồ chuyển đổi trạng thái (State Transition Diagram) hoặc Bảng chuyển đổi.
+- Danh sách Test case bao phủ các trạng thái và các bước chuyển đổi quan trọng.

package/custom/skills/test-skills/categories/01-test-design/01.05.pairwise.md

@@ -0,0 +1,25 @@
+# 01.05. Pairwise (Kiểm thử từng cặp)
+
+## Mục đích
+Tối ưu hóa số lượng test case khi hệ thống có quá nhiều tham số đầu vào và tổ hợp của chúng là quá lớn. Kỹ thuật này dựa trên nguyên lý hầu hết các lỗi được gây ra bởi sự tương tác giữa tối đa hai tham số.
+
+## Kiến thức cần có
+- Hiểu về các tham số đầu vào và các giá trị tương ứng của chúng.
+- Sử dụng các công cụ hỗ trợ tạo tổ hợp (như PICT, AllPairs) để tiết kiệm thời gian.
+- Khả năng xác định các ràng buộc (Constraints) giữa các tham số.
+
+## Quy trình thực hiện
+1. **Liệt kê tham số:** Xác định tất cả các biến đầu vào cần tổ hợp.
+2. **Xác định giá trị:** Liệt kê các giá trị cụ thể cho mỗi tham số (nên kết hợp với Phân vùng tương đương).
+3. **Tạo tổ hợp Pairwise:** Sử dụng thuật toán hoặc công cụ để sinh ra danh sách các bộ dữ liệu sao cho mọi cặp giá trị (Parameter A, Parameter B) đều xuất hiện ít nhất một lần.
+4. **Rà soát ràng buộc:** Điều chỉnh hoặc loại bỏ các tổ hợp không thực tế hoặc bị cấm bởi quy tắc nghiệp vụ.
+
+## Checklist
+- [ ] Đã liệt kê đầy đủ các tham số và giá trị quan trọng?
+- [ ] Các tổ hợp sinh ra đã đảm bảo mọi cặp giá trị đều được kiểm tra?
+- [ ] Đã xem xét các ràng buộc giữa các tham số để tránh dữ liệu vô nghĩa?
+- [ ] Số lượng test case đã được tối ưu so với phương pháp Cartesian Product?
+
+## Output mong đợi
+- Bảng tổ hợp kiểm thử (Pairwise Table).
+- Danh sách Test case với các bộ dữ liệu tối ưu.

package/custom/skills/test-skills/categories/01-test-design/01.06.error-guessing.md

@@ -0,0 +1,28 @@
+# 01.06. Error Guessing (Đoán lỗi)
+
+## Mục đích
+Sử dụng kinh nghiệm, trực giác và kiến thức chuyên sâu về hệ thống của tester để tìm ra các lỗi mà các phương pháp có cấu trúc có thể bỏ sót. Kỹ thuật này tập trung vào các tình huống "ngoại lệ" và các điểm yếu thường gặp của phần mềm.
+
+## Kiến thức cần có
+- Kinh nghiệm thực tế về các loại lỗi phổ biến trong phát triển phần mềm.
+- Hiểu biết về công nghệ, kiến trúc và các lỗi lịch sử của dự án.
+- Tư duy "phá hoại" (Ad-hoc testing mindset).
+
+## Quy trình thực hiện
+1. **Phân tích rủi ro:** Xác định các khu vực nhạy cảm hoặc phức tạp trong mã nguồn.
+2. **Liệt kê kịch bản lỗi:** Dự đoán các sai sót của người dùng hoặc các điều kiện hệ thống bất thường.
+3. **Thiết kế kịch bản đặc biệt:**
+   - Dữ liệu rỗng, ký tự lạ, SQL Injection/XSS đơn giản.
+   - Thao tác nhanh, nhấn nút nhiều lần (Double click).
+   - Ngắt kết nối mạng giữa chừng, hết bộ nhớ, timeout.
+4. **Thực thi và điều chỉnh:** Thử nghiệm các kịch bản và mở rộng dựa trên phản hồi của hệ thống.
+
+## Checklist
+- [ ] Đã liệt kê các trường hợp đầu vào "cực đoan" (Special characters, zero, null)?
+- [ ] Đã kiểm tra các kịch bản về hiệu năng hoặc tài nguyên (Low memory, slow network)?
+- [ ] Đã thử các hành động không theo trình tự logic của người dùng?
+- [ ] Đã dựa trên các lỗi thực tế từng xảy ra trong quá khứ của hệ thống?
+
+## Output mong đợi
+- Danh sách các Test Scenarios ngoại lệ (Edge cases).
+- Các lỗi tiềm ẩn hoặc rủi ro được phát hiện thông qua kinh nghiệm.

package/custom/skills/test-skills/categories/02-ui-testing/02.01.UI-layout.md

@@ -0,0 +1,29 @@
+# 02.01. UI Layout (Bố cục giao diện)
+
+## Mục đích
+Đảm bảo giao diện người dùng (UI) hiển thị chính xác, nhất quán và thẩm mỹ trên các trình duyệt, thiết bị và độ phân giải màn hình khác nhau. Kỹ thuật này giúp phát hiện các lỗi về thẩm mỹ và trải nghiệm người dùng ngay từ lớp giao diện.
+
+## Kiến thức cần có
+- Kiến thức cơ bản về CSS/HTML Layout.
+- Hiểu biết về Responsive Design và các điểm ngắt (Breakpoints).
+- Sử dụng công cụ Inspect của trình duyệt để kiểm tra thuộc tính phần tử.
+- Tài liệu thiết kế (Figma, Adobe XD, Zeplin, v.v.).
+
+## Quy trình thực hiện
+1. **Đối chiếu thiết kế:** So sánh giao diện thực tế với bản vẽ thiết kế để kiểm tra độ chính xác về pixel, màu sắc, font chữ.
+2. **Kiểm tra đa trình duyệt:** Mở ứng dụng trên Chrome, Firefox, Safari, Edge để phát hiện sự khác biệt về hiển thị.
+3. **Kiểm tra Responsive:** Thay đổi kích thước trình duyệt hoặc dùng trình giả lập thiết bị để kiểm tra layout trên Mobile, Tablet và Desktop.
+4. **Kiểm tra Spacing:** Sử dụng công cụ để đo khoảng cách (Padding, Margin) giữa các thành phần.
+5. **Kiểm tra trạng thái:** Xem xét hiển thị của các phần tử khi Hover, Active, Disabled, hoặc khi dữ liệu quá dài.
+
+## Checklist
+- [ ] Căn lề và khoảng cách (Alignment & Spacing) có nhất quán và đúng thiết kế?
+- [ ] Font chữ, kích thước, màu sắc có đúng chuẩn Design System?
+- [ ] Hình ảnh, Icon có bị méo, vỡ hoặc lệch vị trí không?
+- [ ] Văn bản có bị tràn (overflow), cắt xén (truncated) hoặc che khuất phần tử khác?
+- [ ] Giao diện có hiển thị ổn định khi phóng to/thu nhỏ (Zoom) trình duyệt?
+
+## Output mong đợi
+- Danh sách các lỗi về giao diện (UI Bugs).
+- Ảnh chụp màn hình so sánh giữa thiết kế và thực tế (nếu có sai lệch).
+- Báo cáo xác nhận tính tương thích trên các thiết bị/trình duyệt mục tiêu.

package/custom/skills/test-skills/categories/02-ui-testing/02.02.form-validation.md

@@ -0,0 +1,57 @@
+# 02.02. Form Validation (Kiểm tra biểu mẫu) - Comprehensive Matrix
+
+## Mục đích
+Đảm bảo toàn diện tính hợp lệ, an toàn, khả năng tiếp cận (Accessibility), tính tương thích và trải nghiệm người dùng (UX) cho mọi loại input trên giao diện hệ thống. Tài liệu này tích hợp các yêu cầu phân tích từ Báo cáo Phân tích Yêu cầu 16 mục để làm cơ sở thiết kế test case chi tiết.
+
+## Quy trình kiểm thử (Validation Strategy)
+1. **Phân tích kỹ thuật:** Phân vùng tương đương (Equivalence Partitioning) & Phân tích biên (Boundary Value Analysis) cho các trường dữ liệu.
+2. **Kiểm tra loại dữ liệu (Type Validation):** Đảm bảo đúng định dạng, kiểu dữ liệu yêu cầu.
+3. **Kiểm tra quy tắc nghiệp vụ (Business Logic Validation):** Kiểm tra sự ràng buộc, phụ thuộc động giữa các trường và các quy tắc nghiệp vụ ngầm định.
+4. **Kiểm tra an toàn & rủi ro (Security & Risk Validation):** Ngăn chặn mã độc, bypass validation.
+5. **Kiểm tra khả năng tiếp cận & tương thích (Accessibility & Compatibility):** Hỗ trợ Screen Reader, bàn phím và đa thiết bị.
+
+---
+
+## Bảng Ma trận Kiểm thử Validation (Comprehensive Matrix)
+
+| Loại Input | Checklist Validation chi tiết (Áp dụng cho cả Required & Optional) | Ánh xạ Req ID liên quan (Từ Báo cáo 16 mục) |
+| :--- | :--- | :--- |
+| **Text/Password (All)** | - Trạng thái: Bắt buộc (Required) hoặc Không bắt buộc (Optional).<br>- Độ dài: Giới hạn ký tự tối thiểu/tối đa (Min/Max length).<br>- Xử lý khoảng trắng: Tự động loại bỏ khoảng trắng đầu/cuối (Trimming).<br>- Duy nhất: Kiểm tra tính trùng lặp dữ liệu (Unique).<br>- Định dạng: Kiểm tra theo biểu thức chính quy (Regex - email, số điện thoại, mật khẩu mạnh).<br>- Loại ký tự đặc biệt: Ký tự Latin, Kanji, Katakana, Halfwidth/Fullwidth.<br>- Bảo mật: Kiểm tra chèn thẻ script (XSS Injection), mã SQL (SQL Injection).<br>- Thao tác: Kiểm tra sao chép/dán (Copy/Paste), tự động hoàn thành (Autofill). | **Req_08** (Validations)<br>**Req_07** (Business Rules)<br>**Req_15** (Risks)<br>**Req_12** (Compatibility) |
+| **Number/Price/Quantity** | - Trị số: Giá trị tối thiểu/tối đa (Min/Max value).<br>- Dấu số: Cho phép số âm hay chỉ cho phép số dương, số 0.<br>- Số thập phân: Số lượng chữ số sau dấu phẩy (Decimal places).<br>- Định dạng: Hiển thị phân tách hàng nghìn (ví dụ: 1,000,000).<br>- Ràng buộc nhập: Vô hiệu hóa nhập chữ cái và ký tự đặc biệt từ bàn phím.<br>- Tương thích thiết bị di động: Hiển thị bàn phím ảo dạng số (Numeric Keypad). | **Req_08** (Validations)<br>**Req_12** (Compatibility)<br>**Req_07** (Business Rules) |
+| **Date/Time Picker** | - Định dạng: Định dạng hiển thị chuẩn (YYYY/MM/DD, DD/MM/YYYY hh:mm).<br>- Logic thời gian: Ngày quá khứ, hiện tại, tương lai; logic so sánh (Ngày bắt đầu <= Ngày kết thúc).<br>- Phương thức nhập: Cho phép nhập tay (manual input) kết hợp chọn từ lịch hiển thị (datepicker popup).<br>- Đơn vị thời gian: Giờ hoạt động, định dạng 12h/24h. | **Req_08** (Validations)<br>**Req_07** (Business Rules)<br>**Req_12** (Compatibility) |
+| **Dropdown (Select)** | - Trạng thái mặc định: Hiển thị placeholder thích hợp (ví dụ: "Vui lòng chọn...").<br>- Danh sách lựa chọn: Dữ liệu tải động từ DB hoặc danh sách tĩnh cố định.<br>- Thao tác: Khả năng tìm kiếm nhanh (Search/Filter) trong dropdown dài, khả năng đa chọn (Multi-select).<br>- Phím tắt: Điều hướng lên/xuống bằng phím mũi tên và chọn bằng Enter. | **Req_07** (Business Rules)<br>**Req_11** (Accessibility)<br>**Req_08** (Validations) |
+| **Radio / Checkbox** | - Trạng thái mặc định: Trạng thái được check/uncheck mặc định khi load form.<br>- Ràng buộc chọn: Đối với Radio, chỉ cho phép chọn duy nhất 1 option tại một thời điểm. Đối với Checkbox, hỗ trợ chọn nhiều hoặc "Chọn tất cả" (Select All).<br>- Kích thước vùng click: Vùng click bao gồm cả nhãn chữ (label) đi kèm. | **Req_07** (Business Rules)<br>**Req_11** (Accessibility) |
+| **Toggle / Switch** | - Trạng thái mặc định: On/Off, Active/Inactive.<br>- Tác vụ kích hoạt: Bật/tắt dẫn đến ẩn/hiển thị trường dữ liệu khác tức thì hoặc kích hoạt API chạy ngầm. | **Req_07** (Business Rules)<br>**Req_10** (API/External System) |
+| **File Upload (Image/Doc)** | - Định dạng file: Chỉ chấp nhận phần mở rộng/MIME type hợp lệ (ví dụ: .png, .jpg, .pdf).<br>- Kích thước file: Dung lượng file tối đa cho phép (Max upload size).<br>- Số lượng: Số lượng file tối đa có thể upload cùng lúc (Single/Multi-upload).<br>- Tính toàn vẹn/Bảo mật: Ngăn chặn upload file giả mạo đuôi (File spoofing), kiểm tra mã độc trong file.<br>- Trải nghiệm: Hỗ trợ tính năng kéo và thả (Drag & Drop), tiến trình upload (Progress bar). | **Req_08** (Validations)<br>**Req_15** (Risks) |
+| **Rich Text Editor** | - Giới hạn dữ liệu: Độ dài tối đa ký tự (bao gồm cả thẻ HTML ẩn).<br>- Định dạng sao chép: Xử lý làm sạch định dạng khi copy/paste văn bản từ Word/Web.<br>- Bảo mật: Loại bỏ hoàn toàn các thẻ `<script>`, `<iframe>` nguy hại. | **Req_08** (Validations)<br>**Req_15** (Risks) |
+| **Multi-select / Tag Inputs** | - Số lượng: Số lượng tag tối thiểu/tối đa được phép chọn.<br>- Ràng buộc trùng: Không cho phép thêm trùng lặp cùng một tag.<br>- Thao tác xóa: Dễ dàng xóa tag bằng nút "x" hoặc phím Backspace. | **Req_08** (Validations)<br>**Req_11** (Accessibility) |
+| **Hidden Input** | - Tính đúng đắn: Dữ liệu ẩn (ID, Token) khớp với DB hoặc Session hiện tại.<br>- Bảo mật: Không thể chỉnh sửa hoặc thao túng dữ liệu ẩn thông qua công cụ Inspect Element/Developer Tools để bypass logic nghiệp vụ. | **Req_15** (Risks)<br>**Req_02** (Scope Boundary) |
+
+---
+
+## Checklist tổng quát (Áp dụng cho mọi trường & Form)
+
+### 1. Phân quyền và Phạm vi kiểm thử (Scope & Permissions)
+- [ ] **Trạng thái UI theo vai trò (Req_06 & Req_02):** Kiểm tra xem các trường thông tin có hiển thị đúng trạng thái (Enabled/Disabled/Read-only) tương ứng với quyền của tài khoản đang đăng nhập hay không.
+- [ ] **Bám sát phạm vi kiểm thử (Req_02 & Req_16):** Chỉ thực hiện test các input thuộc Scope chỉ định của màn hình/tính năng, không mở rộng kiểm thử sang các module ngoài phạm vi.
+
+### 2. Trải nghiệm người dùng & Thông báo lỗi (UX & Error Handling)
+- [ ] **Thời điểm kiểm tra (Validation Trigger):** Lỗi phải hiển thị đúng lúc (khi bấm Submit hoặc ngay khi người dùng Focus out/Blur khỏi trường nhập).
+- [ ] **Nội dung thông báo lỗi (Req_08):** Thông báo lỗi phải rõ ràng, chỉ rõ tên trường bị lỗi và cách khắc phục (ví dụ: "Email không đúng định dạng", không thông báo chung chung như "Lỗi nhập liệu").
+- [ ] **Giữ lại dữ liệu lỗi (UX):** Hệ thống không được tự động xóa (clear) các dữ liệu người dùng đã nhập lỗi khi hiển thị thông báo lỗi, để người dùng dễ sửa đổi.
+- [ ] **Tập trung con trỏ (Focus):** Sau khi Submit thất bại, tự động chuyển tiêu điểm (Focus) vào trường nhập liệu bị lỗi đầu tiên từ trên xuống dưới.
+
+### 3. Khả năng tiếp cận (Accessibility - Req_11)
+- [ ] **Liên kết nhãn (Labeling):** Mọi trường input phải được liên kết chính xác với một thẻ `<label>` bằng thuộc tính `for` tương ứng với `id` của input đó.
+- [ ] **Thuộc tính ARIA:** Các trường bắt buộc phải có thuộc tính `aria-required="true"`. Khi có thông báo lỗi hiển thị, input tương ứng phải được bổ sung thuộc tính `aria-invalid="true"` và trỏ tới ID của thông báo lỗi qua `aria-describedby`.
+- [ ] **Thông báo lỗi động (Aria Live):** Khung chứa thông báo lỗi phải sử dụng `aria-live="assertive"` để Screen Reader ngay lập tức đọc nội dung lỗi cho người dùng khiếm thị khi nó xuất hiện.
+
+### 4. Tính tương thích & Bảo mật (Compatibility & Security - Req_12 & Req_15)
+- [ ] **Bản phím ảo trên di động (Req_12):** Hiển thị đúng loại bàn phím ảo trên Mobile/Tablet (ví dụ: bàn phím chữ cái cho Text, bàn phím số/number cho Number, bàn phím email chứa phím `@` cho Email).
+- [ ] **Chống Bypass Validation (Req_15):** Kiểm tra xem hệ thống có xử lý validate ở phía Server (Server-side validation) hay không. Thử nghiệm gửi dữ liệu lỗi bằng cách vô hiệu hóa Javascript trên trình duyệt hoặc gọi API trực tiếp qua công cụ (Postman/Fiddler) để đảm bảo API từ chối dữ liệu không hợp lệ.
+
+---
+
+## Hướng dẫn thực hiện
+Khi thiết kế test case (Bước 03. Test Scenario & Case Builder), QA bắt buộc phải đối chiếu **TẤT CẢ các trường nhập liệu** trong màn hình kiểm thử với bảng **Ma trận kiểm thử Validation** này. 
+*Lưu ý: Ngay cả đối với các trường Không bắt buộc (Optional Fields), nếu người dùng có nhập dữ liệu, QA vẫn phải thực hiện kiểm thử đầy đủ các quy tắc validation tương ứng (như Trimming, loại ký tự đặc biệt, độ dài tối đa).*

package/custom/skills/test-skills/categories/02-ui-testing/02.03.navigation.md

@@ -0,0 +1,27 @@
+# 02.03. Navigation (Điều hướng)
+
+## Mục đích
+Đảm bảo luồng di chuyển của người dùng giữa các trang, các phần của ứng dụng diễn ra liền mạch, đúng logic nghiệp vụ và không có các liên kết bị lỗi hoặc ngõ cụt.
+
+## Kiến thức cần có
+- Hiểu biết về User Flow (Luồng người dùng).
+- Khái niệm về Sitemap và cấu trúc liên kết nội bộ.
+- Kiến thức về Breadcrumbs, Pagination (Phân trang) và Deep Linking.
+
+## Quy trình thực hiện
+1. **Kiểm tra Menu & Links:** Click vào tất cả các mục menu, footer links, và các liên kết trong nội dung để đảm bảo dẫn đến đúng trang.
+2. **Kiểm tra Nút Back/Forward:** Sử dụng tính năng quay lại và tiến tới của trình duyệt để xác nhận trạng thái trang được bảo toàn hoặc cập nhật đúng.
+3. **Kiểm tra Breadcrumbs:** Xác nhận đường dẫn phân cấp hiển thị đúng vị trí hiện tại và có thể click để quay lại các cấp cha.
+4. **Kiểm tra Phân trang:** Kiểm tra việc chuyển trang, nhảy trang và hiển thị số lượng bản ghi trên mỗi trang.
+5. **Kiểm tra Deep Link:** Sao chép URL của một trang cụ thể và mở trong tab ẩn danh để xem hệ thống có dẫn trực tiếp đến trang đó (hoặc yêu cầu login) đúng hay không.
+
+## Checklist
+- [ ] Có liên kết nào dẫn đến trang lỗi 404 hoặc trang trắng không?
+- [ ] Các liên kết mở trong tab mới (target="_blank") có hoạt động đúng yêu cầu?
+- [ ] Menu có làm nổi bật (Highlight) mục hiện tại khi người dùng đang ở trang đó?
+- [ ] Sau khi thực hiện một hành động (vd: lưu), hệ thống có điều hướng về đúng trang mong đợi?
+- [ ] Logo ứng dụng có luôn dẫn về trang chủ khi được click?
+
+## Output mong đợi
+- Sơ đồ các luồng điều hướng chính đã được kiểm thử.
+- Danh sách các lỗi liên kết (Broken links) hoặc lỗi điều hướng logic.

package/custom/skills/test-skills/categories/02-ui-testing/02.04.localization.md

@@ -0,0 +1,27 @@
+# 02.04. Localization (Địa phương hóa)
+
+## Mục đích
+Đảm bảo ứng dụng hiển thị chính xác ngôn ngữ, định dạng dữ liệu và tuân thủ các quy tắc văn hóa của người dùng ở từng vùng địa lý khác nhau (i18n & l10n).
+
+## Kiến thức cần có
+- Khái niệm Internationalization (i18n) và Localization (l10n).
+- Hiểu biết về các bộ mã ký tự (UTF-8).
+- Quy tắc định dạng ngày tháng, tiền tệ, số điện thoại của các quốc gia mục tiêu.
+
+## Quy trình thực hiện
+1. **Chuyển đổi ngôn ngữ:** Thay đổi Locale/Ngôn ngữ trong cài đặt ứng dụng hoặc trình duyệt.
+2. **Kiểm tra dịch thuật:** Rà soát toàn bộ giao diện (Labels, Buttons, Tooltips, Messages) để đảm bảo không còn văn bản tiếng gốc (hardcoded).
+3. **Kiểm tra định dạng:** Xác nhận ngày tháng (vd: DD/MM/YYYY vs MM/DD/YYYY), tiền tệ (vd: $, VND), và dấu phân cách hàng ngàn/thập phân hiển thị đúng.
+4. **Kiểm tra Layout:** Xem xét giao diện khi chuyển sang ngôn ngữ có từ ngữ dài (vd: tiếng Đức) hoặc ngắn để đảm bảo không vỡ layout.
+5. **Kiểm tra hình ảnh/icon:** Đảm bảo các hình ảnh hoặc biểu tượng không gây hiểu lầm hoặc vi phạm văn hóa địa phương.
+
+## Checklist
+- [ ] Mọi văn bản hiển thị trên UI đã được dịch hoàn toàn?
+- [ ] Ký tự đặc biệt (có dấu, chữ tượng hình) hiển thị đúng, không lỗi font?
+- [ ] Định dạng số và tiền tệ có phù hợp với quốc gia đã chọn?
+- [ ] Thời gian hiển thị có đúng với múi giờ (Timezone) của người dùng không?
+- [ ] Có lỗi layout (vỡ khung, tràn chữ) do độ dài văn bản dịch khác nhau?
+
+## Output mong đợi
+- Bảng đối chiếu dịch thuật đã kiểm tra.
+- Danh sách các lỗi về font chữ, định dạng hoặc nội dung chưa được địa phương hóa.

package/custom/skills/test-skills/categories/02-ui-testing/02.05.accessibility.md

@@ -0,0 +1,27 @@
+# 02.05. Accessibility (Khả năng tiếp cận)
+
+## Mục đích
+Đảm bảo ứng dụng có thể được sử dụng bởi tất cả mọi người, bao gồm cả những người khuyết tật (khiếm thính, khiếm thị, khó khăn về vận động), tuân thủ các tiêu chuẩn quốc tế như WCAG.
+
+## Kiến thức cần có
+- Hiểu biết về chuẩn WCAG (Web Content Accessibility Guidelines) 2.1.
+- Kiến thức về ARIA labels và các thuộc tính hỗ trợ tiếp cận trong HTML.
+- Cách sử dụng Screen Readers (NVDA, VoiceOver) và phím tắt bàn phím.
+
+## Quy trình thực hiện
+1. **Kiểm tra bàn phím:** Sử dụng phím Tab, Enter, Space để điều hướng và tương tác với toàn bộ ứng dụng mà không cần chuột. Xác nhận vị trí Focus luôn rõ ràng.
+2. **Kiểm tra Screen Reader:** Kích hoạt trình đọc màn hình để nghe xem các thành phần (nút, hình ảnh, thông báo) có được mô tả đúng chức năng không.
+3. **Kiểm tra độ tương phản:** Sử dụng công cụ để đo tỷ lệ tương phản giữa văn bản và nền (đảm bảo đạt tối thiểu 4.5:1 cho văn bản thường).
+4. **Kiểm tra Alt Text:** Xác nhận tất cả hình ảnh có ý nghĩa đều có thuộc tính `alt` mô tả nội dung.
+5. **Kiểm tra khả năng Zoom:** Phóng to trình duyệt lên 200% và đảm bảo nội dung vẫn đọc được, không bị chồng chéo hay mất thông tin.
+
+## Checklist
+- [ ] Có thể thực hiện mọi chức năng quan trọng chỉ bằng bàn phím?
+- [ ] Các thành phần giao diện không có văn bản (vd: icon button) có nhãn ARIA mô tả không?
+- [ ] Trạng thái Focus có hiển thị khung viền (outline) rõ ràng không?
+- [ ] Màu sắc không phải là phương tiện duy nhất để truyền tải thông tin (vd: báo lỗi không chỉ dùng màu đỏ mà cần có text/icon)?
+- [ ] Video có phụ đề hoặc bản dịch văn bản (transcript) đi kèm?
+
+## Output mong đợi
+- Báo cáo đánh giá mức độ tuân thủ WCAG.
+- Danh sách các rào cản tiếp cận và đề xuất cải thiện trải nghiệm cho người khuyết tật.

package/custom/skills/test-skills/categories/03-business-testing/03.01.CRUD-testing.md

@@ -0,0 +1,51 @@
+# Kiểm thử CRUD (Create, Read, Update, Delete)
+
+## Mục đích (Purpose)
+Đảm bảo tính toàn vẹn, chính xác và bảo mật của dữ liệu thông qua bốn thao tác cơ bản: Tạo mới (Create), Hiển thị (Read), Cập nhật (Update) và Xóa (Delete). Kỹ năng này giúp xác minh rằng hệ thống xử lý các thực thể dữ liệu đúng theo yêu cầu nghiệp vụ và các ràng buộc kỹ thuật.
+
+## Kiến thức cần có (Required Knowledge)
+- Hiểu biết về cấu trúc dữ liệu của thực thể cần kiểm thử (các trường thông tin, kiểu dữ liệu, ràng buộc).
+- Nắm vững quy tắc nghiệp vụ (Business Rules) liên quan đến việc tạo, sửa, xóa dữ liệu.
+- Kiến thức về Database (SQL/NoSQL) để kiểm tra dữ liệu thực tế.
+- Hiểu về phân quyền (Permissions/Roles) cho từng thao tác.
+
+## Quy trình thực hiện (Process)
+1. **Phân tích thực thể:** Xác định các trường dữ liệu, trường bắt buộc, định dạng dữ liệu và các ràng buộc duy nhất (Unique constraints).
+2. **Thiết kế kịch bản Create:** Kiểm thử các trường hợp dữ liệu hợp lệ, không hợp lệ, trùng lặp và các ràng buộc nghiệp vụ khi tạo mới.
+3. **Thiết kế kịch bản Read:** Kiểm thử hiển thị danh sách, chi tiết, tìm kiếm, lọc, phân trang và sắp xếp.
+4. **Thiết kế kịch bản Update:** Kiểm thử cập nhật một phần hoặc toàn bộ thông tin, kiểm tra tính toàn vẹn dữ liệu sau khi cập nhật.
+5. **Thiết kế kịch bản Delete:** Kiểm thử xóa mềm (soft delete), xóa cứng (hard delete) và các ràng buộc khi xóa (dữ liệu đang được sử dụng ở nơi khác).
+6. **Xác minh Database:** Đối chiếu kết quả trên giao diện (UI) với dữ liệu thực tế trong cơ sở dữ liệu.
+
+## Checklist
+### Create (Tạo mới)
+- [ ] Dữ liệu hợp lệ được lưu đúng và đủ vào Database.
+- [ ] Các trường bắt buộc (Mandatory fields) được kiểm tra lỗi nếu để trống.
+- [ ] Các ràng buộc định dạng (Email, Số điện thoại, Ngày tháng) hoạt động đúng.
+- [ ] Kiểm tra lỗi khi nhập dữ liệu trùng lặp cho các trường duy nhất (Username, Mã nhân viên, ...).
+- [ ] Xử lý các ký tự đặc biệt, khoảng trắng đầu/cuối chuỗi.
+
+### Read (Hiển thị)
+- [ ] Dữ liệu hiển thị trên danh sách khớp với Database.
+- [ ] Trang chi tiết hiển thị đầy đủ và chính xác thông tin thực thể.
+- [ ] Tìm kiếm (Search) hoạt động đúng với các từ khóa khác nhau.
+- [ ] Các bộ lọc (Filter) trả về đúng kết quả mong đợi.
+- [ ] Phân trang (Pagination) hoạt động mượt mà và đúng số lượng bản ghi.
+- [ ] Sắp xếp (Sorting) đúng theo thứ tự tăng/giảm dần.
+
+### Update (Cập nhật)
+- [ ] Cập nhật thành công khi thay đổi dữ liệu hợp lệ.
+- [ ] Các trường không cho phép sửa (ReadOnly) không thể thay đổi.
+- [ ] Kiểm tra tính toàn vẹn: Cập nhật thực thể này không làm ảnh hưởng sai lệch đến thực thể khác.
+- [ ] Xử lý xung đột (Concurrency): Hai người cùng sửa một bản ghi cùng lúc.
+
+### Delete (Xóa)
+- [ ] Thông báo xác nhận xuất hiện trước khi xóa.
+- [ ] Bản ghi bị xóa không còn xuất hiện trong danh sách và tìm kiếm.
+- [ ] Kiểm tra ràng buộc khóa ngoại: Không cho phép xóa nếu dữ liệu đang được sử dụng (nếu nghiệp vụ yêu cầu).
+- [ ] Kiểm tra xóa mềm: Dữ liệu ẩn trên UI nhưng vẫn còn trong DB với cờ `is_deleted = true`.
+
+## Output mong đợi (Expected Output)
+- Bộ tài liệu Test Cases chi tiết bao phủ đầy đủ các khía cạnh của CRUD cho thực thể.
+- Danh sách các lỗi (Bugs) liên quan đến xử lý dữ liệu (nếu có).
+- Báo cáo xác nhận tính ổn định của các thao tác dữ liệu cơ bản.

package/custom/skills/test-skills/categories/03-business-testing/03.02.workflow-testing.md

@@ -0,0 +1,44 @@
+# Kiểm thử Quy trình nghiệp vụ (Workflow Testing)
+
+## Mục đích (Purpose)
+Đảm bảo rằng các luồng quy trình nghiệp vụ (Business Workflows) hoạt động chính xác, xuyên suốt từ điểm bắt đầu đến điểm kết thúc theo đúng tài liệu đặc tả. Kiểm thử này tập trung vào sự phối hợp giữa các tính năng đơn lẻ để hoàn thành một mục tiêu kinh doanh cụ thể.
+
+## Kiến thức cần có (Required Knowledge)
+- Hiểu rõ sơ đồ quy trình nghiệp vụ (Flowchart/Activity Diagram).
+- Nắm vững các trạng thái của thực thể (Entity States) và điều kiện chuyển trạng thái.
+- Hiểu về các vai trò (Roles) tham gia vào từng bước của quy trình.
+- Kiến thức về các hệ thống bên thứ ba có tham gia vào luồng (nếu có).
+
+## Quy trình thực hiện (Process)
+1. **Xác định các luồng nghiệp vụ:** Liệt kê tất cả các kịch bản có thể xảy ra từ Happy Path đến Edge Cases.
+2. **Xác định các điểm chạm (Touchpoints):** Xác định các bước, các màn hình và các hành động người dùng cần thực hiện.
+3. **Thiết kế kịch bản Happy Path:** Kiểm thử luồng lý tưởng nhất, không có lỗi xảy ra.
+4. **Thiết kế kịch bản Alternate/Exception Paths:** Kiểm thử các nhánh rẽ, các trường hợp lỗi hoặc xử lý ngoại lệ (ví dụ: hủy thanh toán, từ chối phê duyệt).
+5. **Kiểm thử chuyển giao vai trò:** Nếu quy trình cần nhiều người tham gia, hãy kiểm thử việc bàn giao dữ liệu và thông báo giữa các vai trò.
+6. **Kiểm thử tích hợp:** Đảm bảo dữ liệu được truyền đúng giữa các module hoặc hệ thống khác nhau trong quy trình.
+
+## Checklist
+### Luồng chính (Happy Path)
+- [ ] Quy trình hoàn thành thành công từ đầu đến cuối mà không gặp lỗi.
+- [ ] Trạng thái của dữ liệu thay đổi đúng sau mỗi bước.
+- [ ] Các thông báo thành công hiển thị đúng lúc.
+
+### Luồng nhánh & Ngoại lệ (Alternate/Exception Paths)
+- [ ] Hệ thống xử lý đúng khi người dùng chọn các hướng đi khác nhau (ví dụ: Thanh toán bằng COD vs Thẻ tín dụng).
+- [ ] Các điều kiện rẽ nhánh (Decision points) hoạt động chính xác.
+- [ ] Xử lý đúng khi quy trình bị ngắt quãng (mất mạng, hết phiên làm việc, đóng trình duyệt).
+- [ ] Thông báo lỗi rõ ràng và hướng dẫn người dùng cách khắc phục khi đi vào luồng ngoại lệ.
+
+### Trạng thái & Dữ liệu (State & Data)
+- [ ] Dữ liệu không bị mất hoặc sai lệch khi chuyển qua các bước.
+- [ ] Các ràng buộc nghiệp vụ (Business Constraints) được áp dụng đúng tại từng bước.
+- [ ] Lịch sử quy trình (Audit Log) được ghi lại đầy đủ và chính xác.
+
+### Vai trò & Thông báo (Roles & Notifications)
+- [ ] Chỉ những vai trò được phép mới có thể thực hiện các bước tương ứng.
+- [ ] Thông báo (Email, Push, In-app) được gửi đúng người, đúng thời điểm sau mỗi hành động quan trọng.
+
+## Output mong đợi (Expected Output)
+- Danh sách các kịch bản kiểm thử luồng (End-to-End Scenarios) bao phủ toàn bộ quy trình nghiệp vụ.
+- Ma trận chuyển đổi trạng thái (State Transition Matrix) nếu quy trình phức tạp.
+- Kết quả kiểm thử xác nhận quy trình hoạt động ổn định và logic nghiệp vụ chính xác.

package/custom/skills/test-skills/categories/03-business-testing/03.03.permission-testing.md

@@ -0,0 +1,41 @@
+# Kiểm thử Phân quyền (Permission Testing)
+
+## Mục đích (Purpose)
+Xác minh rằng hệ thống thực thi đúng các quy tắc kiểm soát truy cập (Access Control), đảm bảo người dùng chỉ có thể truy cập và thực hiện các hành động trong phạm vi quyền hạn được cấp. Việc này giúp bảo vệ tính bảo mật, toàn vẹn của dữ liệu và ngăn chặn các hành vi truy cập trái phép.
+
+## Kiến thức cần có (Required Knowledge)
+- Hiểu về các mô hình phân quyền: RBAC (Role-Based Access Control), ABAC (Attribute-Based Access Control).
+- Nắm vững Ma trận phân quyền (Permission Matrix) của dự án.
+- Hiểu về sự khác biệt giữa Phân quyền dọc (Vertical) và Phân quyền ngang (Horizontal).
+- Cách thức hệ thống quản lý Session, Token và Cookie để duy trì quyền hạn.
+
+## Quy trình thực hiện (Process)
+1. **Phân tích Ma trận phân quyền:** Liệt kê các vai trò (Roles) và các quyền (Permissions/Actions) tương ứng trên từng tài nguyên.
+2. **Thiết kế kịch bản Phân quyền dọc (Vertical Access):** Kiểm tra xem người dùng ở vai trò thấp hơn có thể truy cập tính năng của vai trò cao hơn (ví dụ: User truy cập trang Admin) hay không.
+3. **Thiết kế kịch bản Phân quyền ngang (Horizontal Access):** Kiểm tra xem người dùng có cùng vai trò có thể truy cập hoặc thao tác dữ liệu của nhau (ví dụ: User A sửa đơn hàng của User B) hay không.
+4. **Kiểm thử Truy cập ẩn danh (Unauthenticated Access):** Xác minh các tài nguyên bảo mật không thể truy cập nếu chưa đăng nhập.
+5. **Kiểm thử Thay đổi quyền hạn (Dynamic Permissions):** Xác minh hệ thống phản ứng thế nào khi quyền của một người dùng bị thay đổi trong khi họ đang đăng nhập (áp dụng ngay hay cần đăng nhập lại).
+6. **Kiểm thử Phân quyền mức dữ liệu (Data-level Security):** Xác minh người dùng chỉ thấy dữ liệu họ được phép thấy (ví dụ: Nhân viên chỉ thấy khách hàng của mình phụ trách).
+
+## Checklist
+### Phân quyền dọc (Vertical Access)
+- [ ] Người dùng không có quyền Admin không thể truy cập URL/API của Admin.
+- [ ] Các Menu, Button của tính năng không có quyền phải bị ẩn hoặc disable.
+- [ ] Trả về lỗi 403 Forbidden khi cố tình truy cập trái phép qua URL.
+
+### Phân quyền ngang (Horizontal Access)
+- [ ] Không thể xem/sửa/xóa dữ liệu của người dùng khác bằng cách thay đổi ID trên URL/API (IDOR vulnerability).
+- [ ] Dữ liệu riêng tư của người dùng này không hiển thị trong các báo cáo/danh sách của người dùng kia.
+
+### Truy cập chưa đăng nhập (Unauthenticated)
+- [ ] Hệ thống chuyển hướng về trang Login khi truy cập trang bảo mật mà chưa đăng nhập.
+- [ ] API trả về lỗi 401 Unauthorized khi thiếu Token/Session.
+
+### Trạng thái hệ thống khi thay đổi quyền
+- [ ] Khi bị thu hồi quyền, người dùng mất quyền truy cập ngay lập tức hoặc sau một khoảng thời gian ngắn quy định.
+- [ ] Khi được cấp thêm quyền, các tính năng mới xuất hiện và hoạt động đúng mà không cần can thiệp kỹ thuật phức tạp.
+
+## Output mong đợi (Expected Output)
+- Ma trận kiểm thử phân quyền đã được xác minh.
+- Danh sách các lỗ hổng bảo mật liên quan đến truy cập trái phép (nếu có).
+- Báo cáo xác nhận hệ thống an toàn về mặt kiểm soát truy cập.

package/custom/skills/test-skills/categories/03-business-testing/03.04.dependency-validation.md

@@ -0,0 +1,40 @@
+# Kiểm thử Ràng buộc phụ thuộc (Dependency Validation)
+
+## Mục đích (Purpose)
+Xác minh tính toàn vẹn và sự ổn định của hệ thống khi có các mối quan hệ phụ thuộc giữa các dữ liệu, các module hoặc các dịch vụ bên ngoài. Đảm bảo rằng sự thay đổi hoặc lỗi ở một thành phần phụ thuộc không làm sụp đổ toàn bộ hệ thống hoặc gây ra dữ liệu rác/mồ côi.
+
+## Kiến thức cần có (Required Knowledge)
+- Hiểu về quan hệ thực thể (ER Diagram) trong cơ sở dữ liệu (One-to-One, One-to-Many, Many-to-Many).
+- Kiến thức về các ràng buộc Database: Primary Key, Foreign Key, Cascading (Delete/Update).
+- Hiểu về kiến trúc hệ thống (Microservices, Third-party APIs) và các điểm phụ thuộc.
+- Nắm vững logic nghiệp vụ về sự phụ thuộc tính năng (ví dụ: Tính năng A chỉ hoạt động nếu tính năng B đã được cấu hình).
+
+## Quy trình thực hiện (Process)
+1. **Xác định các mối quan hệ phụ thuộc:** Liệt kê các thành phần Master-Detail, Parent-Child hoặc các Service-to-Service dependencies.
+2. **Kiểm thử Ràng buộc dữ liệu (Data Dependency):** Thử thực hiện các thao tác Xóa/Cập nhật dữ liệu Master khi đang có dữ liệu Detail phụ thuộc.
+3. **Kiểm thử Hiệu ứng dây chuyền (Cascading Effects):** Kiểm tra xem các bản ghi con có được xử lý đúng (xóa theo, set null, hoặc báo lỗi) khi bản ghi cha bị tác động.
+4. **Kiểm thử Phụ thuộc Module (Module Dependency):** Tắt hoặc thay đổi cấu hình của một module nguồn và kiểm tra phản ứng của các module đích phụ thuộc.
+5. **Kiểm thử Phụ thuộc Dịch vụ bên ngoài (Service Dependency):** Giả lập tình huống dịch vụ bên thứ ba (ví dụ: Cổng thanh toán, Bản đồ) bị chậm hoặc ngừng hoạt động (Mocking/Stubbing).
+6. **Kiểm thử Phục hồi:** Xác minh hệ thống tự phục hồi hoặc hoạt động lại bình thường khi thành phần phụ thuộc có lại.
+
+## Checklist
+### Ràng buộc dữ liệu & Database
+- [ ] Không cho phép xóa bản ghi cha nếu đang có bản ghi con tham chiếu (nếu cấu hình No Action/Restrict).
+- [ ] Dữ liệu con bị xóa hoàn toàn khi dữ liệu cha bị xóa (nếu cấu hình Cascade Delete).
+- [ ] Không có "dữ liệu mồ hôi" (Orphan data) tồn tại trong Database sau các thao tác xóa.
+- [ ] Cập nhật ID ở bản ghi cha thì ID ở bản ghi con cũng được cập nhật đồng bộ (nếu cấu hình Cascade Update).
+
+### Phụ thuộc tính năng & Module
+- [ ] Thông báo lỗi rõ ràng khi người dùng cố truy cập tính năng mà các điều kiện tiên quyết chưa được thỏa mãn.
+- [ ] Module phụ thuộc không bị "crash" (lỗi trắng trang/lỗi 500) khi module nguồn bị tắt.
+- [ ] Dữ liệu mặc định (Fallback data) được hiển thị khi dữ liệu từ module phụ thuộc không có sẵn.
+
+### Phụ thuộc dịch vụ bên ngoài
+- [ ] Hệ thống hiển thị trạng thái đang xử lý (Loading) hoặc thông báo bảo trì khi dịch vụ ngoài bị chậm/lỗi.
+- [ ] Cơ chế Retry hoạt động đúng (nếu có) khi gọi dịch vụ ngoài thất bại.
+- [ ] Dữ liệu được đồng bộ lại (Sync) sau khi dịch vụ bên ngoài hoạt động trở lại.
+
+## Output mong đợi (Expected Output)
+- Ma trận các mối quan hệ phụ thuộc được xác định rõ ràng.
+- Bộ Test Scenarios kiểm tra các tình huống lỗi phụ thuộc (Negative Testing).
+- Báo cáo về khả năng chịu lỗi và tính toàn vẹn dữ liệu của hệ thống.

package/custom/skills/test-skills/categories/03-business-testing/03.05.notification-testing.md

@@ -0,0 +1,43 @@
+# Kiểm thử Thông báo (Notification Testing)
+
+## Mục đích (Purpose)
+Đảm bảo hệ thống gửi các loại thông báo (Email, SMS, Push Notification, In-app) đến đúng đối tượng, đúng thời điểm và với nội dung chính xác theo sự kiện kích hoạt (Trigger events). Kiểm thử này giúp tăng cường trải nghiệm người dùng và đảm bảo tính kịp thời của thông tin.
+
+## Kiến thức cần có (Required Knowledge)
+- Hiểu về các kênh thông báo được hỗ trợ (Email, SMS, Push, Webhook).
+- Nắm vững các kịch bản kích hoạt thông báo (ví dụ: đăng ký thành công, quên mật khẩu, đơn hàng mới).
+- Hiểu về cấu trúc Template (chỗ đặt biến dynamic như {Name}, {Order_ID}).
+- Kiến thức về các nhà cung cấp dịch vụ thông báo (Firebase, AWS SES, Twilio, ...).
+- Hiểu về cơ chế lập lịch (Cronjobs) cho các thông báo không gửi tức thì.
+
+## Quy trình thực hiện (Process)
+1. **Xác định các sự kiện kích hoạt:** Liệt kê tất cả hành động người dùng hoặc hệ thống sẽ sinh ra thông báo.
+2. **Kiểm thử Nội dung (Content Testing):** Xác minh các biến trong template được render đúng dữ liệu thực tế. Kiểm tra định dạng (HTML/Text), font chữ, hình ảnh, link đính kèm.
+3. **Kiểm thử Đa ngôn ngữ:** Nếu hệ thống hỗ trợ nhiều ngôn ngữ, hãy kiểm tra thông báo hiển thị đúng ngôn ngữ theo cấu hình của người nhận.
+4. **Kiểm thử Người nhận (Recipient Testing):** Xác minh thông báo được gửi đúng danh sách To, Cc, Bcc. Đảm bảo người dùng đã block hoặc unsubscribe sẽ không nhận được thông báo.
+5. **Kiểm thử Thời gian (Timing Testing):** Kiểm tra độ trễ (Latency). Xác minh thông báo được gửi ngay lập tức hoặc đúng khung giờ đã đặt lịch.
+6. **Kiểm thử Hiệu năng & Giới hạn:** Kiểm tra việc gửi thông báo hàng loạt (Bulk notifications) và cơ chế giới hạn tần suất gửi (Rate limiting/Spam filter).
+
+## Checklist
+### Nội dung thông báo
+- [ ] Tên người gửi (Sender Name) và Email người gửi đúng cấu hình.
+- [ ] Tiêu đề (Subject) và nội dung (Body) không có lỗi chính tả, đúng template.
+- [ ] Các biến dynamic ({Username}, {OTP}, ...) hiển thị đúng giá trị.
+- [ ] Các liên kết (Links/CTAs) trong thông báo hoạt động và dẫn tới đúng trang.
+- [ ] Hình ảnh hiển thị đúng, không bị vỡ hoặc lỗi link.
+
+### Logic gửi thông báo
+- [ ] Thông báo được kích hoạt ngay sau khi sự kiện xảy ra.
+- [ ] Không gửi trùng lặp (Duplicate) một nội dung thông báo cho cùng một người trong một sự kiện.
+- [ ] Thông báo In-app xuất hiện và có thể đọc/xóa/đánh dấu đã đọc.
+- [ ] Số lượng tin nhắn/email gửi đi không vượt quá giới hạn cho phép (nếu có).
+
+### Thiết bị & Môi trường
+- [ ] Push notification hiển thị đúng trên các nền tảng khác nhau (iOS, Android, Web).
+- [ ] Email hiển thị tốt trên các trình duyệt và ứng dụng mail phổ biến (Gmail, Outlook).
+- [ ] SMS gửi đến đúng đầu số và nhà mạng của người dùng.
+
+## Output mong đợi (Expected Output)
+- Danh sách Test Cases bao phủ toàn bộ các kịch bản thông báo.
+- Ảnh chụp màn hình/Bằng chứng (Evidence) về nội dung thông báo trên các kênh.
+- Báo cáo về tỷ lệ gửi thành công và độ trễ của thông báo.