# Gate 2 — Skills luôn áp dụng (Scenario Building) > **File gộp — giảm số lệnh Read khi Gate chạy** (xem `docs/internal/Token Problems.md` §3.6, Vấn đề F). Nội dung dưới đây là bản sao nguyên văn từ các file gốc cùng thư mục (liệt kê ở mỗi mục `## From:`) — **các file gốc vẫn là nguồn sự thật**, dùng để sửa/tham chiếu độc lập từng kỹ thuật. Khi sửa 1 kỹ thuật: sửa file gốc trước, rồi copy lại đúng phần đã sửa vào file gộp này để giữ đồng bộ. ## From: 00-core/00.03.test-scenario-builder.md # Mục đích Thiết kế và xây dựng danh sách các kịch bản kiểm thử (Test Scenarios - High-level) bao phủ toàn bộ các khía cạnh nghiệp vụ, phi chức năng và rủi ro được chỉ ra trong Báo cáo phân tích yêu cầu (16 mục tiêu chuẩn) và Báo cáo phân tích rủi ro, đảm bảo không bỏ sót bất kỳ luồng xử lý nào. # Input - **Báo cáo Phân tích Yêu cầu (Requirement Analysis Report) đã xác định rõ phạm vi (In-Scope)**: Chỉ tập trung xây dựng Test Scenarios/Checklist cho các tính năng và luồng nghiệp vụ nằm trong phạm vi kiểm thử đã được xác định, tuyệt đối không thiết kế lan man ra ngoài phạm vi. Báo cáo này bao gồm thông tin chi tiết về 16 hạng mục dữ liệu sau: 1. *Module/Màn hình/Feature cụ thể đang test* (Để bám sát đúng phạm vi) 2. *Ranh giới scope* (Xác định rõ In-Scope và Out-of-Scope) 3. *Feature Overview* 4. *Main Flow* 5. *Alternative Flows* 6. *User Roles / Permissions* 7. *Business Rules* 8. *Validations (input/output)* 9. *State / Status liên quan* 10. *API / External System liên quan (nếu có)* 11. *Accessibility Requirements (WCAG, screen reader)* 12. *Compatibility (Browser/Device/OS support)* 13. *Test Data dependencies* 14. *Third-party integrations* 15. *Risk / điểm dễ lỗi* 16. *Out of Scope* - **Báo cáo Phân tích Rủi ro (00.02.risk-analysis.md)**. - **Đọc file quy ước chung (QA_Writing_Standards.md)**. - **Tài liệu bổ trợ (nếu có):** Thiết kế UI/UX (Figma/Mockups), API Specifications, DB Schema. # Quy trình thực hiện ## 1. Thiết kế Kịch bản Đa chiều dựa trên các mục dữ liệu Phân tích Yêu cầu ### A. Nhóm Chức năng (Functional Scenarios) - **Happy Path (Luồng chạy đúng chuẩn):** Thiết kế dựa trên **Mục 3 (Feature Overview)** và **Mục 4 (Main Flow)** của Báo cáo phân tích yêu cầu. Đảm bảo toàn bộ luồng chính hoạt động đúng khi người dùng nhập đúng dữ liệu và thực hiện đúng trình tự. - **Alternative/Exception Flows (Luồng phụ và Luồng lỗi ngoại lệ):** Thiết kế dựa trên **Mục 5 (Alternative Flows)** và **Mục 9 (State / Status liên quan)**. Kịch bản bao gồm việc chuyển đổi trạng thái sai lệch, hủy thao tác giữa chừng, mất kết nối, timeout hoặc nhập sai thông tin ở luồng phụ. - **Permission & Role-based (Kịch bản phân quyền):** Thiết kế dựa trên **Mục 6 (User Roles / Permissions)**. Đảm bảo mỗi kịch bản kiểm tra khả năng truy cập hợp lệ, chặn truy cập trái phép và kiểm tra lỗ hổng leo thang đặc quyền. - **Business Rules & Data Validations (Quy tắc nghiệp vụ & Kiểm tra dữ liệu):** Thiết kế dựa trên **Mục 7 (Business Rules)** và **Mục 8 (Validations)**. Áp dụng kỹ thuật phân tích biên, phân vùng tương đương để kiểm tra logic tính toán, ràng buộc dữ liệu đầu vào (độ dài, ký tự đặc biệt) và cấu trúc đầu ra. - **Integration & E2E (Kịch bản tích hợp):** Thiết kế dựa trên **Mục 10 (API / External System liên quan)**. Đảm bảo tính toàn vẹn dữ liệu truyền giữa các API và cập nhật thông tin chính xác trong Database. ### B. Nhóm Phi chức năng (Non-Functional Scenarios) - **Accessibility (Tính tiếp cận):** Thiết kế dựa trên **Mục 11 (Accessibility Requirements)**. Kiểm tra tính năng tương thích với Screen Reader cho người khiếm thị, khả năng điều hướng bằng bàn phím (tab, enter) và độ tương phản màu sắc theo chuẩn WCAG. - **Compatibility (Tính tương thích):** Thiết kế dựa trên **Mục 12 (Compatibility)**. Đảm bảo giao diện hiển thị đúng chuẩn và chức năng hoạt động mượt mà trên nhiều trình duyệt (Chrome, Safari, Firefox), hệ điều hành (iOS, Android, Windows) và kích thước màn hình khác nhau (PC, Mobile, Tablet). ### C. Nhóm Môi trường & Dữ liệu Kiểm thử (Test Environment & Data Scenarios) - **Data-Driven (Dữ liệu đặc biệt):** Thiết kế dựa trên **Mục 13 (Test Data dependencies)**. Kịch bản chạy kiểm thử lặp với các bộ dữ liệu nền/tài khoản đặc thù khác nhau (ví dụ: tài khoản bị khóa, số dư âm, khách hàng VIP). - **Third-Party Integration Mocking (Tích hợp bên thứ ba):** Thiết kế dựa trên **Mục 14 (Third-party integrations)**. Kịch bản kiểm tra khả năng xử lý khi API của bên thứ ba trả về lỗi, timeout hoặc trả về phản hồi không mong muốn. ### D. Nhóm Kịch bản Rủi ro (Risk-Based Scenarios) - Thiết kế dựa trên **Mục 15 (Risk / điểm dễ lỗi)** từ Báo cáo phân tích yêu cầu kết hợp với danh sách phân loại rủi ro từ Báo cáo phân tích rủi ro. Tập trung vào kịch bản kiểm tra khả năng tự phục hồi lỗi hệ thống (Error Recovery) và kiểm thử phá hủy (Destructive Testing) ở các vùng nghiệp vụ phức tạp. ## 2. Rà soát Độ bao phủ (Coverage Review) - Xây dựng bảng ma trận để đảm bảo 100% các mục quan trọng (từ mục 1 đến 16 của Báo cáo phân tích yêu cầu) đều được kiểm thử và ánh xạ sang ít nhất một kịch bản kiểm thử tương ứng. --- # Mẫu Bảng Kịch bản Kiểm thử & Traceability Matrix (Template) ```markdown # DANH SÁCH KỊCH BẢN KIỂM THỬ (TEST SCENARIOS LIST) | Scenario ID | Feature/Module | Check List | Scenario Type | Target Req ID (1-16) | Priority | Test Data / Dependency | |-------------|----------------|------------|---------------|----------------------|----------|------------------------| | TS_01_001 | [Tên Feature] | [Mô tả kịch bản] | Happy Path | Req_04 (Main Flow) | High | [Dữ liệu cần thiết] | | TS_01_002 | [Tên Feature] | [Mô tả kịch bản] | Negative | Req_08 (Validations) | Medium | [Dữ liệu cần thiết] | | TS_01_003 | [Tên Feature] | [Mô tả kịch bản] | Exception | Req_09 (Status) | High | [Dữ liệu cần thiết] | | TS_01_004 | [Tên Feature] | [Mô tả kịch bản] | Permission | Req_06 (Roles) | High | [Dữ liệu cần thiết] | | TS_01_005 | [Tên Feature] | [Mô tả kịch bản] | Accessibility | Req_11 (Access) | Low | [Screen Reader tool] | | TS_01_006 | [Tên Feature] | [Mô tả kịch bản] | Risk-based | Req_15 (Risks) | High | [Dữ liệu giả lập] | ``` --- # Output Bảng danh sách kịch bản kiểm thử (Test Scenarios) hoàn chỉnh bao gồm: - **Test Scenarios List** chi tiết, đa chiều (Functional, Non-functional, Risk-based). - **Traceability Matrix** được tích hợp sẵn thông qua cột ánh xạ nguồn gốc yêu cầu (Target Req ID). - **Phân loại Priority** và xác định rõ ràng **Test Data/Dependency** cho từng kịch bản. ⚠️ **LƯU Ý QUAN TRỌNG KHI THỰC HIỆN:** - Trình bày rõ ràng dưới dạng bảng (table). - Các mô tả kịch bản (Check List) cần ở mức High-level, tập trung vào mục tiêu kiểm thử thay vì chi tiết từng bước click chuột. - Đảm bảo tính bao phủ (Coverage) triệt để đối với cả 16 điểm phân tích từ Báo cáo phân tích yêu cầu. - Chỉ tạo các kịch bản nằm trong ranh giới In-scope (đã thống nhất tại Mục 2 của Báo cáo phân tích yêu cầu). --- ## From: 01-test-design/01.06.error-guessing.md # 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. --- ## From: 03-business-testing/03.02.workflow-testing.md # 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.