Tmpl Tcm 001 Test Case Mapping
| Trường kiểm soát | Giá trị |
|---|---|
| Artifact ID | TMPL-TCM-001 |
| Tên tệp được kiểm soát | /03-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md |
| Tiêu đề artifact | Tmpl Tcm 001 Test Case Mapping |
| Status | IN_REVIEW |
| Version | v0.9.0 |
| Owner | Principal IT Business Analyst / Technical Curriculum Author |
| Trách nhiệm Owner | Duy trì định danh, tên tệp, metadata, trạng thái, phiên bản, lịch sử thay đổi và ranh giới dữ liệu mô phỏng của template. Owner bảo toàn tính nhất quán quản trị khi template được liên kết trong corpus. |
| Giới hạn thẩm quyền Owner | Owner không tự xác lập baseline, không ghi nhận approval, không xác nhận yêu cầu Nova Foods, không phê duyệt test case, không xác nhận chất lượng phần mềm, không diễn giải pháp lý và không cho phép triển khai production. |
| Last updated date | 2026-08-07 |
| Múi giờ quản trị | Asia/Ho_Chi_Minh |
| Locale áp dụng | vi-VN; bối cảnh Việt Nam; đơn vị tiền tệ mô phỏng VND |
| Phân loại artifact | Controlled four-tier template; template có kiểm soát gồm bốn tầng nội dung phục vụ học tập và truy vết test case. |
| Case study | Nova Foods Trading & Manufacturing — mô phỏng giáo dục. |
| Ranh giới dữ liệu | Chỉ dùng dữ liệu tổng hợp. Tên khách hàng, nhà cung cấp, nhân sự, mã hàng, số chứng từ, số tiền, trạng thái ERP, API payload và kết quả kiểm thử trong artifact này không đại diện dữ liệu thật, cấu hình thật, giao dịch thật hoặc bằng chứng vận hành của Nova Foods. |
| Ranh giới sử dụng | Artifact phục vụ đào tạo IT Business Analyst và mô phỏng ERP. Không phải test plan vận hành, test evidence production, hồ sơ tuân thủ, xác nhận bảo mật, quyết định kế toán hoặc chỉ dẫn pháp lý. |
| Baseline reference | Chưa có baseline reference tại v0.9.0. IN_REVIEW không đồng nghĩa BASELINED. |
| Approval reference | Chưa có approval reference tại v0.9.0. Metadata, version, Owner hoặc nội dung template không tạo approval ngầm định. |
Change History
| Version | Date | Change | Status | Recorded by |
|---|---|---|---|---|
v0.9.0 |
2026-08-07 |
Khởi tạo metadata quản trị cho TMPL-TCM-001; xác lập tên tệp canonical, trạng thái IN_REVIEW, Owner, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND và ranh giới dữ liệu tổng hợp Nova Foods. |
IN_REVIEW |
Principal IT Business Analyst / Technical Curriculum Author |
Quy tắc dữ liệu mô phỏng: Mọi giá trị Nova Foods trong các tầng sau phải có mục đích học tập và khả năng truy vết nội bộ corpus. Không được thay dữ liệu tổng hợp bằng dữ liệu cá nhân, dữ liệu khách hàng, dữ liệu tài chính, bí mật kinh doanh, endpoint thật, credential, token, log production hoặc bằng chứng từ hệ thống thật. Nếu đầu vào chứa dữ liệu thật, dừng sử dụng trong template và chuyển cho Data Owner hoặc Security Owner xử lý theo thẩm quyền.
1. Tier 1 ? Metadata, Purpose, and Governance
Mục đích, phạm vi dùng và thẩm quyền
Mục đích. Template Test Case Mapping là mẫu kiểm soát liên kết giữa test case (ca kiểm thử), test basis (cơ sở kiểm thử) và bằng chứng kiểm thử. Cơ sở kiểm thử là requirement, business rule, acceptance criteria, dữ liệu, luồng hoặc hợp đồng API đã được định danh. Liên kết này giúp người học trả lời ba câu hỏi: kiểm thử cái gì, kiểm thử dựa trên nguồn nào, kết quả nào chứng minh phạm vi đã được kiểm thử. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi tên, giao dịch, dữ liệu và kết quả trong template chỉ là dữ liệu tổng hợp, không phải bằng chứng ERP thực tế.
| Nội dung | Quy tắc sử dụng |
|---|---|
| Khi dùng | Dùng khi đã có test basis có ID canonical và cần chứng minh coverage giữa yêu cầu với test case. Dùng cho functional test, negative test, quyền truy cập, tích hợp API, dữ liệu, accessibility hoặc security verification nếu phạm vi có nguồn phù hợp. |
| Khi không dùng | Không dùng để tạo requirement mới, quyết định business rule, phê duyệt release, xác nhận compliance, thay thế defect log, thay thế test execution record, hoặc thay thế risk register. Không dùng khi test basis chưa có nguồn, chưa có ID, mâu thuẫn hoặc thuộc thẩm quyền chưa được xác minh. |
| Tiêu chí dừng | Dừng lập mapping nếu một test case không chỉ ra được test basis; một test basis bị diễn giải thành quy tắc mới; hoặc kết quả mapping có thể bị hiểu là approval, baseline, production readiness hay xác nhận tuân thủ. |
| Ví dụ ranh giới | Một dòng liên kết TC-NF-... với BR-NF-... chỉ ghi nhận quan hệ cần kiểm thử. Dòng đó không xác nhận business rule đúng, không xác nhận hệ thống đã triển khai, không xác nhận người dùng đã chấp thuận. |
Metadata quản trị owner. Artifact này có trạng thái IN_REVIEW. Trạng thái này xác nhận nội dung còn được review; không xác nhận baseline, approval, release readiness, compliance hay quyền đưa vào production.
| Trường metadata | Giá trị | Trách nhiệm hoặc giới hạn |
|---|---|---|
| Artifact ID | TMPL-TCM-001 |
Khóa canonical của template. Owner bảo toàn ID này trong mọi sửa đổi được kiểm soát. |
| Tên tệp canonical | /03-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md |
Owner duy trì nội dung trong tệp này. Bản PDF, bản sao bài tập hoặc bản trích dẫn không thay thế tệp canonical. |
| Loại artifact | Controlled curriculum template | Artifact hỗ trợ học tập và truy vết kiểm thử. Artifact không phải test execution record, release approval hoặc hồ sơ vận hành. |
| Trạng thái quản trị | IN_REVIEW |
Reviewer đánh giá nội dung, nguồn, ID và ranh giới thẩm quyền. Không chuyển trạng thái thành baseline hoặc approved nếu không có bản ghi kiểm soát phù hợp. |
| Owner role | Principal IT Business Analyst / Technical Curriculum Author |
Owner duy trì cấu trúc template, tính nhất quán ID, liên kết nguồn, lịch sử thay đổi và ranh giới dữ liệu mô phỏng. |
| Owner identity | Không được xác lập trong artifact này | Không suy diễn cá nhân, chữ ký, chức danh pháp lý hoặc quyền phê duyệt từ owner role. |
| Custody boundary | /03-templates/ |
Owner quản trị template trong source boundary này; owner không sở hữu requirement, business rule, API contract, dữ liệu production hoặc quyết định release. |
| Review authority | Reviewer có thẩm quyền theo artifact kiểm soát liên quan | Reviewer kiểm tra traceability, nguồn và tính đúng của thay đổi trong phạm vi được giao; review không tự tạo approval nghiệp vụ hoặc vận hành. |
| Change authority | Principal IT Business Analyst / Technical Curriculum Author đối với thay đổi không đổi ý nghĩa nghiệp vụ |
Owner được sửa định dạng, liên kết ID và mô tả truy vết. Thay đổi semantic phải escalation đến chủ sở hữu nguồn. |
| Escalation authority | Business Owner, QA Owner, Technical Architect, Security Owner, Legal/Compliance Owner hoặc Accounting Owner | Role có thẩm quyền quyết định nguồn thuộc phạm vi của role đó. Owner ghi nhận và chuyển escalation; owner không thay role này quyết định. |
| Approval authority | Không được xác lập trong artifact này | Không ghi approval, baseline, sign-off hoặc production authorization chỉ dựa trên template hay owner role. |
| Retention và change record | Artifact kiểm soát có version, ngày theo Asia/Ho_Chi_Minh, lý do, phạm vi ảnh hưởng và liên kết artifact liên quan |
Owner ghi thay đổi để reviewer truy vết. Không sửa im lặng hoặc đổi ID để khớp dữ liệu ví dụ. |
Owner và người tiêu thụ. Owner là Principal IT Business Analyst / Technical Curriculum Author. Owner duy trì cấu trúc template, tính nhất quán ID, liên kết nguồn, lịch sử thay đổi và ranh giới dữ liệu mô phỏng. Owner không có quyền tự tạo baseline, ghi nhận approval, xác nhận requirement Nova Foods, diễn giải pháp lý, quyết định kế toán, xác nhận bảo mật hoặc cho phép production. Người tiêu thụ gồm Business Analyst để kiểm tra traceability; QA/Test Analyst để thiết kế và rà coverage; Product Owner hoặc Business Owner để xem phạm vi cần xác nhận; Developer và Technical Architect để hiểu liên kết giữa hành vi cần kiểm thử với thiết kế đã được cấp thẩm quyền; reviewer để phát hiện liên kết thiếu hoặc sai nguồn.
Điều kiện đầu vào. Trước khi lập mapping, phải có artifact nguồn được kiểm soát, ID canonical và phạm vi kiểm thử xác định. ID và quan hệ truy vết tuân theo /01-curriculum/TRACEABILITY_ID_REGISTRY.md; business rule chỉ tham chiếu từ /01-curriculum/CANONICAL_BUSINESS_RULES.md; thuật ngữ dữ liệu và trường logic chỉ tham chiếu từ /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Nếu test basis là API, cần có mô tả HTTP/OAS phù hợp; nếu là accessibility, cần nguồn WCAG phù hợp; nếu là security, cần nguồn OWASP phù hợp. Nguồn pháp lý, kế toán, thuế, riêng tư và an toàn thực phẩm chỉ được ghi là Verification required hoặc project assumption nếu chưa được vai trò có thẩm quyền xác minh.
Đầu ra hạ nguồn. Mapping hoàn chỉnh là đầu vào cho test case detail, test execution record, defect triage, coverage review, UAT preparation và release-readiness assessment. Quan hệ hạ nguồn chỉ có giá trị truy vết: mapping không thay defect decision, không thay bằng chứng chạy test, không thay quyết định go-live.
Thẩm quyền và escalation. Owner được sửa lỗi định dạng, liên kết ID và mô tả truy vết khi không đổi ý nghĩa nghiệp vụ. Thay đổi test basis, business rule, acceptance criteria, dữ liệu nhạy cảm, quyền truy cập, API contract, diễn giải pháp lý hoặc tiêu chí release phải escalation đến chủ sở hữu tương ứng: Business Owner, QA Owner, Technical Architect, Security Owner, Legal/Compliance Owner hoặc Accounting Owner. Escalation bắt buộc khi nguồn canonical mâu thuẫn, ID chưa đăng ký, một test case liên kết nhiều nguồn có ý nghĩa xung đột, hoặc mapping có thể bị diễn giải thành quyết định vận hành Nova Foods thực tế.
Liên kết Manifest, ID Canonical, Chương, Nguồn và Kiểm soát Thay đổi
/03-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md là artifact template được kiểm soát. Định danh template phải luôn ghi nguyên dạng TMPL-TCM-001; không đổi thành TCM-001, TEST_CASE_MAPPING, tên dịch tiếng Việt, hay ID tự tạo. Lý do: TMPL-TCM-001 là khóa liên kết giữa template, manifest, registry truy vết và artifact áp dụng. Tên tệp canonical là /03-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md; bản xuất PDF, bản sao làm bài tập hoặc nội dung trích dẫn không thay thế tệp này.
| Hạng mục liên kết | Giá trị canonical | Cách dùng bắt buộc | Ranh giới |
|---|---|---|---|
| Manifest template | TEMPLATE_MANIFEST |
Kiểm tra ID, tên tệp, phạm vi template và dependency trước khi sửa nội dung. | Manifest là kế hoạch được kiểm soát, không phải baseline hay approval. |
| Registry ID | TRACEABILITY_ID_REGISTRY |
Dùng để kiểm tra cấu trúc và tính duy nhất của ID requirement, rule, data, interface, test case và evidence khi các Tier sau điền dữ liệu. | Không tự cấp ID nếu registry chưa đăng ký hoặc nguồn canonical mâu thuẫn. |
| Quy tắc nghiệp vụ | CANONICAL_BUSINESS_RULES |
Liên kết test case với business rule canonical, không chép lại rule thành nguồn chân lý mới. | Không diễn giải rule thành quyết định vận hành Nova Foods thực. |
| Dữ liệu logic | CANONICAL_DATA_DICTIONARY |
Liên kết test data, trường dữ liệu và giá trị kiểm thử với định nghĩa dữ liệu canonical. | Không suy diễn schema vật lý, API payload production hoặc dữ liệu thật. |
| Kiến trúc curriculum | 01_CURRICULUM_ARCHITECTURE |
Kiểm tra template phục vụ chuỗi học từ requirement, acceptance criteria, traceability đến test basis. | Không dùng template để sửa curriculum architecture. |
| Manifest chapter | CHAPTER_MANIFEST |
Kiểm tra chapter nào tạo test basis và chapter nào tiêu thụ kết quả mapping. | Không tạo chapter ID, dependency hoặc assessment ngoài manifest. |
| Source map | 00_SOURCE_MAP |
Kiểm tra phân loại nguồn và safe use boundary khi nêu thuật ngữ, kỹ thuật hoặc chuẩn. | Không biến nguồn tham khảo thành clause, nghĩa vụ pháp lý hay xác nhận compliance. |
Template này thuộc chuỗi chapter về requirement, acceptance criteria, traceability, testing và delivery readiness trong CHAPTER_MANIFEST. Lập luận: test case mapping chỉ có test basis khi requirement, rule, data và acceptance criteria đã tồn tại; vì vậy template không được dùng để phát minh requirement hay thay thế review nghiệp vụ. Nếu chapter manifest không chỉ rõ dependency hoặc canonical ID chưa tồn tại, giữ liên kết ở trạng thái cần xác minh và escalation đến Principal IT Business Analyst / Technical Curriculum Author để bảo toàn truy vết.
Nguồn phương pháp kiểm thử được phân loại primary testing syllabus: ISTQB CTFL Syllabus v4.0.1, URL https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf. Nguồn này hỗ trợ thuật ngữ test basis, test case, test condition và kỹ thuật black-box; không chứng minh Nova Foods đã áp dụng quy trình kiểm thử nào. BABOK Guide được phân loại nguồn BA cho thuật ngữ truy vết và quản trị yêu cầu; không được gán số trang hoặc điều khoản khi chưa kiểm tra licensed text. Mọi liên kết pháp lý, kế toán, riêng tư, an toàn thực phẩm hoặc hóa đơn phải giữ nhãn Verification required nếu chưa được role có thẩm quyền xác minh theo nguồn chính thức.
Mọi thay đổi ảnh hưởng TMPL-TCM-001, tên tệp, ID canonical, cấu trúc traceability, phân loại nguồn hoặc dependency chapter phải được ghi trong artifact kiểm soát với version, ngày theo Asia/Ho_Chi_Minh, lý do, phạm vi ảnh hưởng và liên kết artifact liên quan. Không sửa im lặng, không đổi ID để khớp dữ liệu ví dụ, không gọi thay đổi là baseline hoặc approved khi chưa có tham chiếu ghi nhận. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; toàn bộ dữ liệu dùng trong template là dữ liệu tổng hợp, không phải dữ liệu ERP, khách hàng, nhân sự hay vận hành thực.
2. Tier 2 ? Blank Copy-Paste-Ready Template
Dùng mẫu này để lập bản ghi ánh xạ test case (trường hợp kiểm thử): liên kết điều kiện cần kiểm thử với requirement, business rule, acceptance criterion, dữ liệu, kết quả và bằng chứng. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; chỉ nhập dữ liệu tổng hợp. Không dùng mẫu để tạo requirement, rule hoặc phê duyệt mới. Không dùng chuỗi dấu chấm lửng trong template hoặc bản ghi hoàn chỉnh vì chuỗi đó che giấu nội dung cần kiểm tra, làm đứt truy vết và không đủ điều kiện kiểm soát trước khi tạo baseline.
2.1. Thông tin kiểm soát bản ghi
| Trường | Giá trị điền |
|---|---|
| Template ID | TMPL-TCM-001 |
| Tên tệp kiểm soát | /03-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md |
| Test Case ID | <ID test case canonical, ví dụ theo registry đã đăng ký> |
| Tiêu đề test case | <mô tả ngắn hành vi cần xác minh> |
| Module ERP | <tên module hoặc miền nghiệp vụ> |
| Loại kiểm thử | <functional|integration|regression|negative|accessibility|security> |
| Mức ưu tiên | <Critical|High|Medium|Low> |
| Mức rủi ro | <High|Medium|Low> |
| Trạng thái bản ghi | <DRAFT|IN_REVIEW|READY_FOR_TEST|BLOCKED|EXECUTED|RETIRED> |
| Phiên bản bản ghi | <phiên bản, ví dụ v0.1.0> |
| Ngày cập nhật | <YYYY-MM-DD theo Asia/Ho_Chi_Minh> |
| Người soạn | <vai trò hoặc tên định danh mô phỏng> |
| Phạm vi dữ liệu | Synthetic data only |
| Locale | vi-VN |
| Múi giờ | Asia/Ho_Chi_Minh |
| Tiền tệ nếu áp dụng | VND |
| Ghi chú phạm vi | <nêu giới hạn test case; không ghi nhận approval hoặc baseline nếu chưa có tham chiếu> |
2.2. Test basis và mục tiêu kiểm thử
| Trường | Giá trị điền |
|---|---|
| Mục tiêu kiểm thử | <hành vi nghiệp vụ hoặc hệ thống cần chứng minh> |
| Test basis | <loại đầu vào: requirement, business rule, acceptance criterion, API contract, UI specification hoặc source khác> |
| Test basis ID | <ID canonical của đầu vào> |
| Artifact nguồn | <đường dẫn tệp controlled chứa đầu vào> |
| Phiên bản nguồn | <version nguồn hoặc Verification required nếu chưa xác định> |
| Phần nguồn | <heading, bảng, dòng hoặc định danh ổn định; không bịa số điều khoản> |
| Lý do liên kết | <giải thích nguồn nêu điều kiện nào và test case xác minh điều kiện đó ra sao> |
| Test condition | <điều kiện kiểm thử có thể quan sát> |
| Kỹ thuật thiết kế test | <equivalence partitioning|boundary value analysis|decision table|state transition|use case testing|error guessing> |
| Tiêu chí vào | <điều kiện phải có trước khi chạy test> |
| Tiêu chí thoát | <điều kiện xác định test hoàn tất> |
2.3. Phạm vi, tiền điều kiện và dữ liệu
| Trường | Giá trị điền |
|---|---|
| Trong phạm vi | <chức năng, giao dịch, API hoặc màn hình được kiểm thử> |
| Ngoài phạm vi | <chức năng liên quan nhưng không được kiểm thử bởi bản ghi này> |
| Tiền điều kiện nghiệp vụ | <trạng thái dữ liệu hoặc quy trình phải tồn tại> |
| Tiền điều kiện hệ thống | <môi trường, cấu hình mô phỏng, quyền truy cập cần có> |
| Vai trò thực hiện | <vai trò người dùng mô phỏng> |
| Quyền cần thiết | <tên quyền hoặc nhóm quyền mô phỏng> |
| Dữ liệu đầu vào | <ID dữ liệu tổng hợp, giá trị, đơn vị và trạng thái ban đầu> |
| Dữ liệu không được dùng | <PII thật, secret, token, mật khẩu, dữ liệu production hoặc dữ liệu khách hàng thật> |
| Tham chiếu secret nếu áp dụng | <secret reference dạng vault://<vault>/<path>#<key>; không ghi secret thực> |
| Môi trường chạy | <DEV|TEST|UAT mô phỏng hoặc môi trường được kiểm soát> |
2.4. Bảng bước thực hiện và kết quả mong đợi
| Bước | Hành động kiểm thử | Dữ liệu dùng | Kết quả mong đợi | Điểm kiểm tra | Kết quả thực tế | Trạng thái bước |
|---|---|---|---|---|---|---|
<số thứ tự bắt đầu từ 1> |
<thao tác rõ tác nhân, màn hình, API hoặc sự kiện> |
<dữ liệu tổng hợp dùng tại bước> |
<kết quả có thể quan sát và đối chiếu> |
<trường, thông báo, trạng thái, log hoặc bản ghi cần kiểm tra> |
<để trống khi chưa thực thi; điền quan sát thực tế khi chạy> |
<NOT_RUN|PASS|FAIL|BLOCKED|NOT_APPLICABLE> |
<số thứ tự tiếp theo> |
<thao tác rõ tác nhân, màn hình, API hoặc sự kiện> |
<dữ liệu tổng hợp dùng tại bước> |
<kết quả có thể quan sát và đối chiếu> |
<trường, thông báo, trạng thái, log hoặc bản ghi cần kiểm tra> |
<để trống khi chưa thực thi; điền quan sát thực tế khi chạy> |
<NOT_RUN|PASS|FAIL|BLOCKED|NOT_APPLICABLE> |
<số thứ tự xác nhận hoặc dọn dữ liệu test> |
<thao tác xác nhận kết quả cuối hoặc dọn dữ liệu test> |
<dữ liệu tổng hợp dùng tại bước> |
<kết quả cuối và trạng thái dữ liệu sau test> |
<bằng chứng cuối cần thu thập> |
<để trống khi chưa thực thi; điền quan sát thực tế khi chạy> |
<NOT_RUN|PASS|FAIL|BLOCKED|NOT_APPLICABLE> |
2.5. Quyết định, ngoại lệ và kết luận chạy test
| Trường | Giá trị điền |
|---|---|
| Quyết định cần xác minh | <điều kiện lựa chọn, phê duyệt, chặn, tính toán hoặc chuyển trạng thái> |
| Điều kiện đúng | <đầu vào hoặc trạng thái làm hệ thống đi theo nhánh đúng> |
| Kết quả nhánh đúng | <kết quả mong đợi khi điều kiện đúng> |
| Điều kiện sai | <đầu vào hoặc trạng thái làm hệ thống đi theo nhánh sai> |
| Kết quả nhánh sai | <kết quả mong đợi khi điều kiện sai> |
| Ngoại lệ dự kiến | <lỗi nghiệp vụ, lỗi kỹ thuật hoặc tình huống bị chặn cần xác minh> |
| Cách xử lý ngoại lệ mong đợi | <thông báo, rollback, giữ trạng thái, log hoặc escalation mong đợi> |
| Kết quả thực thi tổng | <NOT_RUN|PASS|FAIL|BLOCKED|NOT_APPLICABLE> |
| Ngày giờ thực thi | <YYYY-MM-DD HH:mm:ss theo Asia/Ho_Chi_Minh> |
| Người thực thi | <vai trò hoặc tên định danh mô phỏng> |
| Defect ID nếu fail | <ID defect canonical hoặc NOT_APPLICABLE> |
| Lý do blocked hoặc not applicable | <nguyên nhân và dependency chặn; NOT_APPLICABLE nếu không áp dụng> |
2.6. Bằng chứng và truy vết
| Loại liên kết | ID hoặc tham chiếu | Artifact hoặc vị trí | Mục đích liên kết | Trạng thái xác minh |
|---|---|---|---|---|
| Requirement | <requirement ID canonical> |
<đường dẫn artifact và vị trí> |
<test case chứng minh requirement nào> |
<VERIFIED|IN_REVIEW|Verification required> |
| Business rule | <business rule ID canonical hoặc NOT_APPLICABLE> |
<đường dẫn artifact và vị trí> |
<rule chi phối expected result> |
<VERIFIED|IN_REVIEW|Verification required> |
| Acceptance criterion | <acceptance criterion ID canonical hoặc NOT_APPLICABLE> |
<đường dẫn artifact và vị trí> |
<tiêu chí chấp nhận được kiểm thử> |
<VERIFIED|IN_REVIEW|Verification required> |
| Test data | <test data ID canonical> |
<nguồn dữ liệu tổng hợp> |
<dữ liệu tái lập được test> |
<VERIFIED|IN_REVIEW|Verification required> |
| Evidence | <evidence ID hoặc đường dẫn evidence kiểm soát> |
<ảnh chụp, log, response, report hoặc file kết quả> |
<chứng minh kết quả thực thi> |
<NOT_CAPTURED|CAPTURED|UNAVAILABLE> |
| Defect | <defect ID canonical hoặc NOT_APPLICABLE> |
<artifact quản lý defect> |
<liên kết lỗi khi test fail> |
<OPEN|RESOLVED|NOT_APPLICABLE> |
2.7. Lịch sử thay đổi, review và sign-off
| Phiên bản | Ngày | Người thay đổi | Nội dung thay đổi | Lý do thay đổi | Trạng thái review |
|---|---|---|---|---|---|
<version> |
<YYYY-MM-DD> |
<vai trò hoặc tên định danh mô phỏng> |
<mô tả thay đổi cụ thể> |
<nguồn hoặc defect dẫn đến thay đổi> |
<NOT_REVIEWED|IN_REVIEW|CHANGES_REQUESTED|ACCEPTED> |
| Vai trò review hoặc sign-off | Người được chỉ định | Quyết định | Ngày quyết định | Tham chiếu bằng chứng | Ghi chú thẩm quyền |
|---|---|---|---|---|---|
<Business Owner hoặc delegate được chỉ định> |
<tên định danh mô phỏng hoặc UNASSIGNED> |
<PENDING|ACCEPTED|REJECTED|NOT_REQUIRED> |
<YYYY-MM-DD hoặc NOT_RECORDED> |
<review record ID hoặc NOT_RECORDED> |
<không suy diễn approval từ việc điền tên> |
<QA Reviewer> |
<tên định danh mô phỏng hoặc UNASSIGNED> |
<PENDING|ACCEPTED|REJECTED|NOT_REQUIRED> |
<YYYY-MM-DD hoặc NOT_RECORDED> |
<review record ID hoặc NOT_RECORDED> |
<xác nhận chất lượng test, không thay business approval> |
<Technical Owner nếu cần quyết định kỹ thuật> |
<tên định danh mô phỏng hoặc UNASSIGNED> |
<PENDING|ACCEPTED|REJECTED|NOT_REQUIRED> |
<YYYY-MM-DD hoặc NOT_RECORDED> |
<review record ID hoặc NOT_RECORDED> |
<chỉ dùng khi test phụ thuộc quyết định kỹ thuật> |
Bộ bảng kiểm soát đầy đủ cho một Test Case Mapping
Dùng một bản sao khối này cho mỗi hồ sơ ánh xạ test case. Test case mapping là ánh xạ có kiểm soát giữa yêu cầu, quy tắc, dữ liệu, bước kiểm thử, bằng chứng và kết quả. Mọi giá trị Nova Foods chỉ dùng cho case mô phỏng, dữ liệu tổng hợp; không ghi nhận phê duyệt ngầm định.
| Trường | Giá trị điền | Quy tắc kiểm tra |
|---|---|---|
| Mapping ID | <TCM-ID duy nhất theo TRACEABILITY_ID_REGISTRY> |
Bắt buộc; không tự tạo biến thể ID. |
| Tên mapping | <tên nêu đối tượng, hành vi, kết quả mong đợi> |
Bắt buộc; không dùng tên mơ hồ như “Kiểm tra chức năng”. |
| Artifact ID | TMPL-TCM-001 |
Giữ nguyên. |
| Tên tệp | /03-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md |
Giữ nguyên. |
| Status | IN_REVIEW |
Chỉ dùng trạng thái hiện hành của corpus. |
| Version | v0.9.0 |
Không gọi là baseline hoặc approved. |
| Ngày cập nhật | 2026-08-07 |
Theo Asia/Ho_Chi_Minh. |
| Locale và tiền tệ | vi-VN; VND |
Dùng dữ liệu tổng hợp. |
| Phạm vi kiểm thử | <module, quy trình, màn hình, API hoặc báo cáo> |
Bắt buộc; một mapping không gộp phạm vi không liên quan. |
| Loại kiểm thử | <Functional|Integration|API|Data|Security|Accessibility|Regression|UAT-support> |
Chọn ít nhất một; ghi lý do nếu chọn nhiều loại. |
| Mức ưu tiên | <Critical|High|Medium|Low> |
Bắt buộc; dựa trên tác động nghiệp vụ và rủi ro, không dựa trên ý kiến không có bằng chứng. |
| Người lập | <vai trò hoặc định danh người lập> |
Không suy diễn quyền phê duyệt. |
| Môi trường | <DEV|SIT|UAT|môi trường mô phỏng khác> |
Bắt buộc; không ghi URL, mật khẩu hoặc token thật. |
| Decision ID | Câu hỏi quyết định | Giá trị được chọn | Bằng chứng và cầu nối suy luận | Điều kiện escalation |
|---|---|---|---|---|
<DEC-ID> |
<đây có phải luồng thành công không> |
<Yes|No> |
<requirement hoặc rule ID xác định kết quả> |
Requirement mâu thuẫn hoặc thiếu tiêu chí chấp nhận. |
<DEC-ID> |
<có xử lý dữ liệu cá nhân, tài chính hoặc an toàn thực phẩm không> |
<Yes|No> |
<data field hoặc source classification liên quan> |
Yes; chuyển Security, Legal, Accounting hoặc domain owner phù hợp. |
<DEC-ID> |
<có gọi API hoặc tích hợp ngoài hệ thống không> |
<Yes|No> |
<interface ID hoặc kiến trúc nguồn> |
Contract API, quyền truy cập hoặc dữ liệu lỗi chưa rõ. |
<DEC-ID> |
<có yêu cầu bằng chứng truy vết lô hàng không> |
<Yes|No> |
<rule ID hoặc yêu cầu domain> |
Quy tắc pháp lý hoặc an toàn thực phẩm chưa được domain/legal owner xác minh. |
| Test Case ID | Requirement ID | Rule ID | Acceptance Criteria ID | Kịch bản | Tiền điều kiện | Dữ liệu test tổng hợp | Bước kiểm thử | Kết quả mong đợi | Actual Result | Kết quả | Severity |
|---|---|---|---|---|---|---|---|---|---|---|---|
<TC-ID> |
<REQ-ID hoặc N/A có lý do> |
<BR-ID hoặc N/A có lý do> |
<AC-ID hoặc N/A có lý do> |
<một hành vi có thể kiểm chứng> |
<trạng thái hệ thống và quyền cần có> |
<Data Set ID; không chứa bí mật hoặc dữ liệu thật> |
<bước đánh số, có input và hành động> |
<kết quả quan sát được, đo được> |
<Pass: quan sát thực tế; Fail: lỗi thực tế; Not Run: lý do> |
<Pass|Fail|Blocked|Not Run> |
<Critical|High|Medium|Low|N/A> |
<TC-ID> |
<REQ-ID hoặc N/A có lý do> |
<BR-ID hoặc N/A có lý do> |
<AC-ID hoặc N/A có lý do> |
<ngoại lệ hoặc biên dữ liệu> |
<trạng thái hệ thống và quyền cần có> |
<Data Set ID; không chứa bí mật hoặc dữ liệu thật> |
<bước đánh số, có input và hành động> |
<thông báo lỗi, chặn xử lý hoặc hành vi thay thế> |
<Pass: quan sát thực tế; Fail: lỗi thực tế; Not Run: lý do> |
<Pass|Fail|Blocked|Not Run> |
<Critical|High|Medium|Low|N/A> |
<TC-ID> |
<REQ-ID hoặc N/A có lý do> |
<BR-ID hoặc N/A có lý do> |
<AC-ID hoặc N/A có lý do> |
<quyền truy cập, tích hợp hoặc truy vết> |
<trạng thái hệ thống và quyền cần có> |
<Data Set ID; không chứa bí mật hoặc dữ liệu thật> |
<bước đánh số, có input và hành động> |
<phản hồi, nhật ký hoặc trạng thái mong đợi> |
<Pass: quan sát thực tế; Fail: lỗi thực tế; Not Run: lý do> |
<Pass|Fail|Blocked|Not Run> |
<Critical|High|Medium|Low|N/A> |
Actual Result chỉ điền sau thực thi. Pass yêu cầu actual result khớp hoàn toàn kết quả mong đợi. Fail yêu cầu Defect ID. Blocked yêu cầu blocker, owner và hành động tiếp theo. Not Run yêu cầu lý do; không được dùng như kết quả đạt.
| Exception ID | Test Case ID | Điều kiện kích hoạt | Hành vi kỳ vọng | Phân loại | Owner xử lý | Escalation | Trạng thái |
|---|---|---|---|---|---|---|---|
<EXC-ID> |
<TC-ID> |
<input không hợp lệ, thiếu quyền, lỗi tích hợp hoặc điều kiện biên> |
<từ chối, cảnh báo, rollback, retry hoặc ghi nhận lỗi> |
<Business|Data|Integration|Security|Accessibility|Environment> |
<vai trò chịu trách nhiệm> |
<điều kiện và vai trò nhận escalation> |
<Open|Resolved|Accepted Risk|Not Applicable> |
<EXC-ID> |
<TC-ID> |
<điều kiện kích hoạt thứ hai> |
<hành vi kỳ vọng> |
<Business|Data|Integration|Security|Accessibility|Environment> |
<vai trò chịu trách nhiệm> |
<điều kiện và vai trò nhận escalation> |
<Open|Resolved|Accepted Risk|Not Applicable> |
| Evidence ID | Test Case ID | Loại bằng chứng | Vị trí tham chiếu an toàn | Thời điểm | Người ghi nhận | Kiểm tra tối thiểu |
|---|---|---|---|---|---|---|
<EVD-ID> |
<TC-ID> |
<screenshot|log|API response|report export|query result|video> |
<repository path, ticket link hoặc vault reference không chứa secret> |
<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh> |
<vai trò hoặc định danh> |
Bằng chứng hiển thị ID test, môi trường và kết quả. |
<EVD-ID> |
<TC-ID> |
<screenshot|log|API response|report export|query result|video> |
<repository path, ticket link hoặc vault reference không chứa secret> |
<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh> |
<vai trò hoặc định danh> |
Không đính kèm mật khẩu, API key, bearer token, cookie hoặc dữ liệu cá nhân thật. |
Khi cần tham chiếu bí mật, dùng mẫu <secret-manager://<vault>/<secret-name>#<version>>; chỉ ghi tên tham chiếu, không ghi giá trị bí mật. Nếu bằng chứng chứa dữ liệu nhạy cảm, ghi <restricted-evidence-reference> và xác định owner có quyền truy cập.
| Trace Link ID | Loại nguồn | ID nguồn canonical | Vị trí nguồn | Lý do liên kết | Trạng thái xác minh |
|---|---|---|---|---|---|
<TRL-ID> |
<Requirement|Business Rule|Data Dictionary|Interface|Defect|Risk|Source> |
<ID canonical> |
<đường dẫn tệp canonical và heading/bảng> |
<nguồn này tạo test basis hoặc giải thích quyết định> |
<Verified|Verification required|Conflicting> |
<TRL-ID> |
<Requirement|Business Rule|Data Dictionary|Interface|Defect|Risk|Source> |
<ID canonical> |
<đường dẫn tệp canonical và heading/bảng> |
<nguồn này tạo test basis hoặc giải thích quyết định> |
<Verified|Verification required|Conflicting> |
| Version | Ngày | Loại thay đổi | Mô tả thay đổi | Lý do và bằng chứng | Người ghi nhận | Review trạng thái |
|---|---|---|---|---|---|---|
v0.9.0 |
2026-08-07 |
<Created|Updated|Corrected|Retired> |
<mô tả thay đổi có thể truy vết> |
<Trace Link ID hoặc Exception ID> |
<vai trò hoặc định danh> |
IN_REVIEW |
<version kế tiếp theo kiểm soát corpus> |
<YYYY-MM-DD> |
<Created|Updated|Corrected|Retired> |
<mô tả thay đổi có thể truy vết> |
<Trace Link ID hoặc Exception ID> |
<vai trò hoặc định danh> |
<IN_REVIEW|Returned for Rework|Approved nếu có bằng chứng thẩm quyền> |
| Vai trò review hoặc sign-off | Người được chỉ định | Phạm vi xem xét | Quyết định | Ngày giờ | Bằng chứng quyết định | Điều kiện hợp lệ |
|---|---|---|---|---|---|---|
<BA Reviewer> |
<tên hoặc định danh> |
<đủ traceability, rõ test basis, đủ ngoại lệ> |
<Pending|Reviewed|Returned for Rework> |
<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh hoặc N/A> |
<review record ID hoặc N/A> |
Reviewed không đồng nghĩa approval. |
<QA Reviewer> |
<tên hoặc định danh> |
<testability, bước test, expected result, evidence> |
<Pending|Reviewed|Returned for Rework> |
<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh hoặc N/A> |
<review record ID hoặc N/A> |
Pass test không thay thế review. |
<Business Owner> |
<tên hoặc định danh> |
<quy tắc nghiệp vụ và kết quả mong đợi> |
<Pending|Approved|Rejected|Not Required> |
<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh hoặc N/A> |
<approval record ID hoặc N/A> |
Chỉ ghi Approved khi có bằng chứng quyền hạn. |
<Legal|Accounting|Security|Domain Owner nếu kích hoạt> |
<tên hoặc định danh> |
<phạm vi chuyên môn bị kích hoạt> |
<Pending|Approved|Rejected|Not Required> |
<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh hoặc N/A> |
<approval record ID hoặc N/A> |
Không dùng Not Required nếu Decision ID đã kích hoạt escalation. |
Hướng dẫn điền trường, giá trị hợp lệ và điều kiện áp dụng
Dùng mẫu này cho Nova Foods Trading & Manufacturing mô phỏng, chỉ dữ liệu tổng hợp. Mỗi placeholder dạng <mô tả giá trị cần điền> phải được thay bằng giá trị cụ thể trước khi chuyển sang Tier 3. Không giữ placeholder trong bản case hoàn chỉnh. IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh và VND là giá trị kiểm soát corpus hiện hành; không suy diễn thành baseline, phê duyệt, tuân thủ hay sẵn sàng production.
| Nhóm trường | Hướng dẫn điền | Giá trị hợp lệ | Quy tắc xác nhận |
|---|---|---|---|
| Test Case ID | Điền ID duy nhất, giữ nguyên ID đã cấp từ registry canonical. | <ID test case canonical> |
Không tự tạo biến thể, không tái sử dụng ID giữa hai test case. Nếu ID chưa có trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md, dừng và escalation. |
| Tiêu đề test case | Mô tả một hành vi kiểm thử quan sát được: điều kiện, hành động, kết quả mong đợi. | <động từ + đối tượng + điều kiện> |
Không dùng tiêu đề mơ hồ như “Kiểm tra đơn hàng”. Tiêu đề phải phân biệt được test case khác. |
| Mục tiêu kiểm thử | Nêu rủi ro hoặc rule cần chứng minh bằng kiểm thử. | <mục tiêu đo được> |
Phải liên kết ít nhất một requirement, acceptance criterion hoặc business rule đã được định danh. Không biến giả định thành rule bắt buộc. |
| Phân loại kiểm thử | Chọn loại kiểm thử theo mục tiêu. “Functional” kiểm tra chức năng; “Negative” kiểm tra đầu vào hay trạng thái không hợp lệ; “Integration” kiểm tra trao đổi giữa thành phần; “Security” kiểm tra kiểm soát bảo vệ; “Accessibility” kiểm tra khả năng tiếp cận. | Functional; Negative; Integration; Security; Accessibility; Regression; Data validation |
Chọn nhiều giá trị khi cần, phân cách bằng ;. Mỗi loại phải có bước và kết quả tương ứng. |
| Mức ưu tiên | Phản ánh tác động nghiệp vụ nếu lỗi xảy ra, không phản ánh sở thích người viết. | Critical; High; Medium; Low |
Critical cần nêu lý do tác động rõ: mất dữ liệu, sai giao dịch, lộ dữ liệu, hoặc chặn luồng cốt lõi. |
| Điều kiện tiên quyết | Nêu trạng thái dữ liệu, quyền, cấu hình mô phỏng cần có trước bước 1. | <trạng thái chuẩn bị cụ thể> hoặc Không có |
Mỗi điều kiện phải kiểm chứng được. Không ghi “hệ thống hoạt động bình thường”. |
| Vai trò thực hiện | Nêu vai trò, không dùng tên người thật. | <vai trò mô phỏng> |
Vai trò phải phù hợp quyền cần kiểm tra. Nếu kiểm thử phân quyền, thêm vai trò bị từ chối. |
| Dữ liệu kiểm thử | Dùng mã và giá trị tổng hợp. Ghi nguồn tạo dữ liệu hoặc reference dataset. | <mã dữ liệu synthetic>; <giá trị VND>; <ngày vi-VN> |
Không dùng dữ liệu cá nhân, khách hàng, token, mật khẩu, khóa API hay dữ liệu production. Số tiền dùng VND; ngày ghi YYYY-MM-DD; thời điểm ghi kèm Asia/Ho_Chi_Minh. |
| Bước kiểm thử | Một hàng là một thao tác có thể lặp lại. | <số bước>; <hành động người dùng hoặc API> |
Bước phải có chủ thể, thao tác, đối tượng. Không gộp nhiều thao tác độc lập vào một bước. |
| Kết quả mong đợi | Nêu kết quả quan sát được sau từng bước hoặc sau chuỗi bước. | <trạng thái>; <thông báo>; <dữ liệu được tạo/cập nhật> |
Phải kiểm chứng được bằng màn hình, API response, log được phép xem, hoặc dữ liệu lưu. Không viết “hệ thống xử lý đúng”. |
| Kết quả thực tế | Chỉ điền khi thực thi test. | <quan sát thực tế>; Chưa thực thi |
Chưa thực thi không phải Pass. Nếu khác kết quả mong đợi, trạng thái phải là Fail, Blocked hoặc Not Run theo tình huống. |
| Trạng thái thực thi | Phân biệt kết quả test với trạng thái quản trị tài liệu. | Not Run; Pass; Fail; Blocked; Not Applicable |
Pass chỉ khi mọi kết quả mong đợi đạt. Blocked phải nêu blocker và owner xử lý. Not Applicable phải nêu điều kiện làm test không áp dụng. |
| Ngoại lệ | Ghi trường hợp luồng chuẩn không áp dụng, lỗi mong đợi, hoặc giới hạn môi trường. | <điều kiện ngoại lệ> hoặc Không có |
Mỗi ngoại lệ phải nêu trigger, cách hệ thống phản hồi, và quyết định tiếp tục hay dừng test. |
| Evidence | “Evidence” là bằng chứng kiểm thử có thể kiểm tra lại. Ghi loại bằng chứng và vị trí kiểm soát. | Screenshot; API response; Audit log; Database query result; Video; Không có |
Evidence không chứa bí mật hoặc dữ liệu cá nhân. Mỗi evidence phải liên kết Test Case ID, ngày ghi nhận, người ghi nhận theo vai trò. |
| Traceability | “Traceability” là khả năng lần theo liên kết từ test case về nguồn yêu cầu và sang defect hoặc evidence. | <Requirement ID>; <Acceptance Criterion ID>; <Business Rule ID>; <Source Artifact ID> |
Giữ nguyên canonical ID. Không thay ID bằng tiêu đề tự do. Nếu nguồn là giả định, ghi Project assumption — Verification required. |
| Defect reference | Chỉ điền khi có lỗi được ghi nhận trong công cụ hoặc artifact kiểm soát. | <Defect ID canonical> hoặc Không có |
Không tự kết luận nguyên nhân kỹ thuật. Mô tả symptom, bước tái hiện, tác động và evidence. |
| Version và thay đổi | Ghi version test case, ngày thay đổi, thay đổi thực hiện, lý do và người ghi nhận theo vai trò. | <version>; <YYYY-MM-DD>; <vai trò> |
Không sửa im lặng. Version tài liệu hiện hành v0.9.0; thay đổi sau phải có dòng lịch sử riêng. |
| Review và sign-off | “Review” là xem xét; “sign-off” là xác nhận chính thức bởi vai trò có thẩm quyền. | Not requested; Pending review; Reviewed with findings; Rejected; Approved |
Không điền Approved hay sign-off nếu không có reference kiểm soát. Với corpus hiện hành, dùng Pending review hoặc Not requested khi phù hợp. |
Điều kiện nhánh. Nếu test case gọi API, ghi method, URL mẫu không chứa bí mật, request payload synthetic, expected HTTP status và schema reference. Nếu test case xử lý dữ liệu cá nhân, tài chính, kế toán, thuế, an toàn thực phẩm hoặc truy xuất nguồn gốc, gắn nhãn Verification required và chỉ rõ owner cần xác minh: Legal Owner, Accounting Owner, Food Safety Owner, Security Owner hoặc Business Owner. Lý do: nguồn seed chỉ cho phép dùng luật và chuẩn trong ranh giới đã xác minh; template không được tự tạo nghĩa vụ pháp lý hay vận hành.
Tham chiếu bí mật an toàn. Không ghi mật khẩu, access token, API key, connection string, khóa mã hóa, số tài khoản thật, cookie phiên hay payload có dữ liệu cá nhân. Dùng dạng <secret-reference: vault-path-or-secret-id> và <secret-owner-role>. Ví dụ cấu trúc: <secret-reference: NOVA-ERP-TEST-API-CREDENTIAL>; giá trị bí mật chỉ nằm trong kho bí mật được kiểm soát, không nằm trong Markdown, screenshot hay evidence đính kèm. Nếu không có kho bí mật được phê duyệt, đánh dấu test Blocked; không thay bằng bí mật tạm trong tài liệu.
3. Tier 3 ? Fully Completed Nova Foods Case: Core Record
Phạm vi case: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục. Toàn bộ người dùng, mã giao dịch, số tiền, ngày giờ và dữ liệu dưới đây là dữ liệu tổng hợp, không phải dữ liệu ERP thực tế.
| Trường | Giá trị hoàn chỉnh |
|---|---|
| Template ID | TMPL-TCM-001 |
| Mapping record ID | TCM-NF-SO-001 |
| Test case ID | TC-NF-SO-014 |
| Tên test case | Chặn xác nhận đơn bán khi công nợ khách hàng vượt hạn mức tín dụng |
| Status | IN_REVIEW |
| Version | v0.9.0 |
| Ngày thực hiện | 2026-08-07 |
| Múi giờ | Asia/Ho_Chi_Minh |
| Locale và tiền tệ | vi-VN; VND |
| Phân hệ ERP | Sales Order Management |
| Quy trình | Tạo và xác nhận đơn bán nội địa |
| Người thực hiện test | UAT-NF-001 — Nguyễn Minh An — Sales Operations Tester |
| Vai trò xử lý ngoại lệ | NF-ROLE-CREDIT-01 — Trần Hải Nam — Credit Controller |
| Khách hàng mô phỏng | CUS-NF-000184 — Công ty TNHH Phân phối Hương Việt |
| Đơn bán mô phỏng | SO-NF-20260807-0042 |
| Loại nguồn | Project assumption — simulated business rule |
| Phân loại dữ liệu | Internal simulated commercial data; không chứa dữ liệu cá nhân thật |
Bối cảnh nghiệp vụ. Nhân viên bán hàng tạo đơn SO-NF-20260807-0042 cho khách hàng CUS-NF-000184. Giá trị hàng trước thuế là 42.000.000 VND, VAT mô phỏng là 4.200.000 VND, tổng thanh toán là 46.200.000 VND. Công nợ mở hiện có của khách hàng là 78.000.000 VND. Hạn mức tín dụng mô phỏng là 100.000.000 VND. Sau khi cộng tổng đơn, mức phơi nhiễm tín dụng là 124.200.000 VND, lớn hơn hạn mức 24.200.000 VND.
| Thành phần tính | Giá trị |
|---|---|
Công nợ mở open_receivable_amount |
78.000.000 VND |
Tổng đơn gồm VAT sales_order_total_amount |
46.200.000 VND |
Mức phơi nhiễm credit_exposure_amount |
124.200.000 VND |
Hạn mức credit_limit_amount |
100.000.000 VND |
Số vượt hạn mức credit_excess_amount |
24.200.000 VND |
Sự thật hiện tại và nhu cầu. Quy trình mô phỏng đang cho phép Sales Operations bấm xác nhận đơn khi tổng đơn vượt hạn mức. Nhu cầu gốc là ngăn cam kết giao hàng vượt mức rủi ro tín dụng trước khi Credit Controller xem xét. Cầu nối suy luận: công nợ mở 78.000.000 VND cộng tổng đơn 46.200.000 VND bằng 124.200.000 VND; giá trị này vượt 100.000.000 VND; vì vậy trạng thái đơn phải chuyển sang chờ duyệt tín dụng thay vì xác nhận.
| ID yêu cầu mô phỏng | Nội dung | Phân loại nguồn |
|---|---|---|
REQ-NF-SO-021 |
ERP phải tính mức phơi nhiễm bằng công nợ mở cộng tổng đơn gồm VAT khi người dùng yêu cầu xác nhận đơn. | Project assumption — simulated requirement |
BR-NF-CREDIT-003 |
Nếu mức phơi nhiễm lớn hơn hạn mức tín dụng, ERP phải chặn xác nhận và đặt đơn ở trạng thái PENDING_CREDIT_REVIEW. |
Project assumption — simulated business rule |
AC-NF-SO-021-01 |
Với đơn SO-NF-20260807-0042, hệ thống phải trả trạng thái chặn và số vượt hạn mức 24.200.000 VND. |
Project assumption — simulated acceptance criterion |
Quy tắc quyết định. Điều kiện quyết định là credit_exposure_amount > credit_limit_amount. Dấu > giữ đúng nghĩa “vượt”; bằng đúng hạn mức không kích hoạt chặn theo giả định case này. Quy tắc không thay thế chính sách tín dụng, quyết định kế toán, quyết định thuế hoặc thẩm quyền vận hành thực tế.
| Phương án | Mô tả | Tiêu chí đánh giá | Kết quả mô phỏng |
|---|---|---|---|
OPT-01 |
Tự xác nhận mọi đơn, ghi cảnh báo sau. | Tốc độ xử lý cao nhưng không ngăn cam kết vượt rủi ro. | Không chọn |
OPT-02 |
Chặn xác nhận, chuyển đơn sang PENDING_CREDIT_REVIEW. |
Ngăn giao hàng trước kiểm soát; giữ quyền quyết định ngoại lệ cho Credit Controller. | Được dùng cho case |
OPT-03 |
Tự giảm số lượng hàng để tổng đơn bằng hạn mức. | Thay đổi cam kết bán hàng không có xác nhận từ khách hàng. | Không chọn |
Thẩm quyền và hậu quả. Business Owner và Credit Controller là vai trò phải xác minh chính sách hạn mức thực tế. Test case này không ghi nhận approval. Nếu chọn sai OPT-01, Nova Foods mô phỏng có thể giao hàng với mức phơi nhiễm vượt hạn mức 24.200.000 VND. Nếu chọn sai OPT-03, ERP có thể thay đổi số lượng bán mà không có quyết định nghiệp vụ hợp lệ.
Dữ liệu đầu vào
| Dòng | Mã hàng mô phỏng | Tên hàng mô phỏng | Số lượng | Đơn giá chưa VAT | Thành tiền chưa VAT |
|---|---|---|---|---|---|
| 1 | FG-NF-NUOCMAM-500 |
Nước mắm Nova 500 ml | 600 chai | 35.000 VND |
21.000.000 VND |
| 2 | FG-NF-GAOJASMINE-5KG |
Gạo Jasmine Nova 5 kg | 300 bao | 70.000 VND |
21.000.000 VND |
{
"sales_order_id": "SO-NF-20260807-0042",
"customer_id": "CUS-NF-000184",
"currency_code": "VND",
"order_date": "2026-08-07",
"requested_by_user_id": "UAT-NF-001",
"open_receivable_amount": 78000000,
"credit_limit_amount": 100000000,
"order_lines": [
{
"line_number": 1,
"item_id": "FG-NF-NUOCMAM-500",
"quantity": 600,
"unit_price_excluding_vat": 35000,
"vat_rate": 0.10
},
{
"line_number": 2,
"item_id": "FG-NF-GAOJASMINE-5KG",
"quantity": 300,
"unit_price_excluding_vat": 70000,
"vat_rate": 0.10
}
]
}
Bước test và kết quả mong đợi
| Bước | Hành động của tester | Kết quả mong đợi | Trạng thái |
|---|---|---|---|
| 1 | Đăng nhập bằng UAT-NF-001 với vai trò Sales Operations. |
Người dùng có thể tạo đơn bán nhưng không có quyền tự vượt kiểm soát tín dụng. | READY |
| 2 | Tạo đơn SO-NF-20260807-0042 với hai dòng hàng đã nêu. |
ERP tính tiền hàng 42.000.000 VND, VAT 4.200.000 VND, tổng 46.200.000 VND. |
DRAFT |
| 3 | Chọn hành động xác nhận đơn. | ERP tính 124.200.000 VND = 78.000.000 VND + 46.200.000 VND. |
CREDIT_CHECKING |
| 4 | Kiểm tra kết quả xác nhận. | ERP không tạo trạng thái CONFIRMED; đơn chuyển PENDING_CREDIT_REVIEW; hiển thị số vượt hạn mức 24.200.000 VND. |
PENDING_CREDIT_REVIEW |
| 5 | Kiểm tra khả năng giao hàng. | ERP không cho tạo phiếu xuất kho từ đơn đang PENDING_CREDIT_REVIEW. |
BLOCKED_FOR_FULFILLMENT |
Kết quả pass. Test case đạt khi cả ba điều kiện cùng đúng: tổng đơn là 46.200.000 VND; mức phơi nhiễm là 124.200.000 VND; đơn không ở CONFIRMED mà ở PENDING_CREDIT_REVIEW. Test case thất bại nếu hệ thống xác nhận đơn, cho tạo phiếu xuất kho, tính sai số vượt hạn mức, hoặc bỏ qua VAT trong tổng đơn.
Hồ sơ hoàn chỉnh: ánh xạ test case kiểm tra chặn xuất kho vượt tồn khả dụng
| Trường lõi | Giá trị hoàn chỉnh |
|---|---|
| Template ID | TMPL-TCM-001 |
| Bản ghi ánh xạ | TCM-NF-001 |
| Tên tình huống | Chặn xác nhận phiếu xuất bán khi số lượng yêu cầu vượt tồn khả dụng |
| Case study | Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp |
| Trạng thái | IN_REVIEW |
| Phiên bản | v0.9.0 |
| Ngày ghi nhận | 2026-08-07 |
| Múi giờ | Asia/Ho_Chi_Minh |
| Locale và tiền tệ | vi-VN, VND |
| Phân hệ | ERP Sales Order, Inventory và Warehouse |
| Người lập mô phỏng | Nguyễn Minh An — Business Analyst |
| Người thực thi test mô phỏng | Trần Gia Huy — QA Analyst |
| Vai trò quyết định nghiệp vụ | Lê Thu Hà — Sales Operations Manager |
| Vai trò quyết định kỹ thuật | Phạm Quốc Bảo — ERP Solution Architect |
| Phân loại nguồn | PROJECT_ASSUMPTION — quy tắc mô phỏng phục vụ học liệu, không phải quy tắc vận hành Nova Foods thực tế |
| Nhu cầu nền | Tránh bán hoặc xuất vượt số hàng hệ thống có thể phân bổ, vì đơn đã xác nhận sai có thể gây thiếu hàng, giao trễ và sai lệch cam kết với khách. |
| Hành vi hiện tại mô phỏng | Người dùng có thể nhập số lượng đặt bán lớn hơn tồn khả dụng; hệ thống chỉ báo thiếu hàng sau khi kho xử lý phiếu xuất. |
| Sự kiện khởi phát | Nhân viên bán hàng chọn Xác nhận đơn hàng cho đơn có số lượng yêu cầu lớn hơn tồn khả dụng tại kho giao đã chọn. |
| Quyết định cần kiểm tra | ERP phải từ chối xác nhận đơn hàng khi tồn khả dụng nhỏ hơn tổng số lượng cần phân bổ cho từng dòng hàng. |
| Hậu quả nếu quyết định sai | Đơn hàng có thể được xác nhận dù kho không đủ hàng; bộ phận kho nhận yêu cầu không thể xuất đủ; khách có thể nhận xác nhận giao hàng không thực hiện được. |
Thuật ngữ: Test case là ca kiểm thử: bộ điều kiện, dữ liệu, bước thực hiện và kết quả mong đợi để kiểm tra một hành vi. Mapping là ánh xạ: liên kết có kiểm soát giữa nhu cầu, quy tắc, điều kiện chấp nhận và test case để biết mỗi nội dung đã được kiểm tra bằng trường hợp nào.
| Loại đối tượng | ID | Nội dung hoàn chỉnh | Trạng thái |
|---|---|---|---|
| Business need | BN-NF-SO-001 |
Không cho xác nhận đơn bán khi kho giao không đủ tồn khả dụng cho từng mặt hàng. | IN_REVIEW |
| Business rule | BR-NF-INV-001 |
Khi xác nhận đơn bán, với mỗi dòng hàng, Số lượng yêu cầu phải nhỏ hơn hoặc bằng Tồn khả dụng của cùng mã hàng tại kho giao. Nếu một dòng không đạt, hệ thống không xác nhận toàn bộ đơn. |
IN_REVIEW |
| Acceptance criterion | AC-NF-SO-001 |
Với đơn SO-NF-260807-001, dòng FG-CHA-500 yêu cầu 120 thùng và tồn khả dụng tại WH-HCM-01 là 100 thùng, thao tác xác nhận bị từ chối và đơn giữ trạng thái DRAFT. |
IN_REVIEW |
| Test case | TC-NF-SO-001 |
Kiểm tra chặn xác nhận đơn vượt tồn khả dụng. | IN_REVIEW |
| Test execution | TEX-NF-SO-001 |
Chưa thực thi; bản ghi lập để review học liệu. | NOT_RUN |
| Dữ liệu test | Giá trị |
|---|---|
| Khách hàng | CUS-NF-00128 — Công ty TNHH Phân phối Bình Minh |
| Mã kho giao | WH-HCM-01 — Kho Thành phẩm Hồ Chí Minh |
| Mã hàng | FG-CHA-500 — Nova Chả Cá 500g |
| Đơn vị tính | Thùng |
| Tồn vật lý | 140 thùng |
| Số lượng đã giữ chỗ | 40 thùng |
| Tồn khả dụng | 100 thùng |
| Công thức tồn khả dụng | Tồn vật lý - Số lượng đã giữ chỗ = 140 - 40 = 100 thùng |
| Đơn bán | SO-NF-260807-001 |
| Ngày đơn | 2026-08-07 |
| Đơn giá mô phỏng | 680.000 VND/thùng |
| Số lượng yêu cầu | 120 thùng |
| Giá trị dòng đơn | 120 × 680.000 = 81.600.000 VND |
| Trạng thái đơn trước thao tác | DRAFT |
| Quyền người dùng | ROLE-SALES-EXECUTIVE |
| Người dùng mô phỏng | USR-NF-SALES-014 — Vũ Khánh Linh |
| Bước | Thao tác thực hiện | Kết quả mong đợi |
|---|---|---|
| 1 | Đăng nhập ERP bằng USR-NF-SALES-014 có quyền ROLE-SALES-EXECUTIVE. |
Người dùng truy cập được chức năng tạo đơn bán. |
| 2 | Tạo đơn SO-NF-260807-001 cho CUS-NF-00128, chọn kho WH-HCM-01. |
Đơn có trạng thái DRAFT; kho giao là WH-HCM-01. |
| 3 | Thêm dòng hàng FG-CHA-500, đơn vị Thùng, số lượng 120, đơn giá 680.000 VND. |
Hệ thống hiển thị giá trị dòng là 81.600.000 VND. |
| 4 | Chọn Xác nhận đơn hàng. |
Hệ thống so sánh 120 thùng yêu cầu với 100 thùng tồn khả dụng. |
| 5 | Quan sát phản hồi và trạng thái đơn. | Hệ thống từ chối xác nhận, hiển thị lỗi Không đủ tồn khả dụng tại kho WH-HCM-01 cho mã hàng FG-CHA-500: yêu cầu 120 Thùng, khả dụng 100 Thùng. Đơn giữ DRAFT. Không tạo phiếu xuất kho, không tạo giữ chỗ mới, không thay đổi tồn vật lý 140 thùng và số lượng đã giữ chỗ 40 thùng. |
| Quy tắc quyết định | Phương án | Tiêu chí | Kết luận |
|---|---|---|---|
| Xử lý khi vượt tồn khả dụng | Cho xác nhận và cảnh báo | Giữ tốc độ nhập đơn nhưng chuyển rủi ro thiếu hàng sang kho. | Không chọn. |
| Xử lý khi vượt tồn khả dụng | Tự tách đơn theo số lượng có sẵn | Có thể hỗ trợ giao một phần nhưng cần quy tắc giao hàng, giá, cam kết khách và thẩm quyền vận hành riêng. | Không chọn trong phạm vi case. |
| Xử lý khi vượt tồn khả dụng | Chặn xác nhận toàn bộ đơn | Ngăn cam kết sai ngay tại điểm kiểm soát; kết quả xác định, kiểm thử được và không tự tạo giao dịch kho. | Khuyến nghị mô phỏng. |
| Thẩm quyền quyết định | Lê Thu Hà — Sales Operations Manager quyết định chính sách chặn hay cho giao một phần; Phạm Quốc Bảo — ERP Solution Architect xác nhận khả năng cấu hình. |
Quyết định ảnh hưởng chính sách bán hàng và thiết kế ERP, vượt quyền người lập template. | Chưa có phê duyệt ghi nhận. |
| Kết quả test dự kiến | Giá trị |
|---|---|
| Verdict dự kiến | PASS khi toàn bộ kết quả mong đợi ở bước 5 xảy ra |
Verdict dự kiến nếu đơn chuyển CONFIRMED |
FAIL vì vi phạm BR-NF-INV-001 |
| Verdict dự kiến nếu tạo phiếu xuất | FAIL vì giao dịch kho không được phép phát sinh từ đơn bị từ chối |
| Phạm vi loại trừ | Không kiểm tra thuế, hóa đơn điện tử, giá vốn, giao một phần, thay kho giao, tích hợp API, hiệu năng hoặc phân quyền quản trị. |
| Giới hạn áp dụng | Quy tắc chỉ là giả định dự án cho Nova Foods mô phỏng. Chính sách tồn kho, giao một phần và hạch toán thực tế cần Business Owner, Accounting Owner và Architect xác minh trước production. |
Bối cảnh quyết định kiểm thử TCM-NF-001
Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi diễn viên, giao dịch, mã và giá trị dưới đây là dữ liệu tổng hợp. Test Case Mapping (bản đồ liên kết ca kiểm thử) nối nhu cầu nghiệp vụ, quy tắc, điều kiện chấp nhận và kiểm thử để người kiểm thử biết kiểm tra điều gì, vì sao kiểm tra, ai quyết định khi có xung đột.
| Trường | Nội dung đã điền |
|---|---|
| Mapping ID | TCM-NF-001 |
| Phạm vi nghiệp vụ | Tạo đơn bán hàng nội địa cho khách hàng đại lý, kiểm tra hạn mức tín dụng trước khi xác nhận đơn |
| Đơn vị mô phỏng | Nova Foods Trading & Manufacturing |
| Ngày ghi nhận | 2026-08-07 |
| Múi giờ | Asia/Ho_Chi_Minh |
| Tiền tệ | VND |
| Trạng thái mapping | IN_REVIEW |
| Phiên bản | v0.9.0 |
| Quy trình liên quan | Order-to-Cash, từ tạo Sales Order đến xác nhận Sales Order |
| Giao dịch mô phỏng | SO-NF-20260807-0042, khách hàng CUS-NF-000128, tổng giá trị đơn 185.400.000 VND |
| Diễn viên mô phỏng | Nguyễn Minh An, Sales Executive; Trần Thu Hà, Credit Controller; Lê Quốc Bảo, Sales Manager |
| Phân loại nguồn | PROJECT_ASSUMPTION cho quy tắc hạn mức; PRIMARY_STANDARD cho thuật ngữ kiểm thử theo ISTQB CTFL v4.0.1; CANONICAL_PLANNING_ARTIFACT cho ID và quản trị corpus |
| Nguồn truy vết | /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md; ISTQB_CTFL_Syllabus_v4.0.1.pdf |
Sự kiện và hiện trạng. Ngày 2026-08-07, Nguyễn Minh An tạo SO-NF-20260807-0042 cho CUS-NF-000128. Giá trị đơn là 185.400.000 VND; công nợ mở mô phỏng của khách hàng là 842.000.000 VND; hạn mức tín dụng được cấu hình mô phỏng là 1.000.000.000 VND. Tổng phơi nhiễm sau đơn là 1.027.400.000 VND. Hiện trạng giả định: ERP cho phép Sales Executive xác nhận đơn dù tổng phơi nhiễm vượt hạn mức. Bằng chứng là đơn được chuyển từ DRAFT sang CONFIRMED mà không tạo yêu cầu phê duyệt tín dụng. Đây là hành vi hiện tại cần kiểm thử, không phải xác nhận cấu hình ERP thực tế.
Nhu cầu nền tảng. Hạn mức tín dụng là ngưỡng kiểm soát số tiền doanh nghiệp cho khách hàng mua chịu. Khi tổng công nợ mở và giá trị đơn mới vượt ngưỡng, doanh nghiệp cần chặn xác nhận tự động hoặc yêu cầu vai trò tín dụng quyết định. Lý do: Sales Executive tối ưu doanh số, còn Credit Controller kiểm soát rủi ro thu tiền; một vai trò không nên tự bỏ qua kiểm soát của vai trò kia. Nhu cầu này là PROJECT_ASSUMPTION; cần Business Owner và Accounting Owner xác minh trước khi dùng cho vận hành.
| Mã lựa chọn | Lựa chọn | Ưu điểm | Hạn chế | Kết quả đánh giá |
|---|---|---|---|---|
OPT-NF-CR-01 |
Cho phép mọi đơn vượt hạn mức tự xác nhận | Không làm chậm bán hàng | Không có kiểm soát rủi ro tín dụng | Loại |
OPT-NF-CR-02 |
Chặn mọi đơn vượt hạn mức, không có ngoại lệ | Kiểm soát chặt | Có thể chặn đơn hợp lệ đã được cấp thẩm quyền | Không chọn |
OPT-NF-CR-03 |
Đơn vượt hạn mức chuyển PENDING_CREDIT_APPROVAL; chỉ Credit Controller được phê duyệt hoặc từ chối |
Tách nhiệm vụ, lưu vết quyết định, vẫn xử lý ngoại lệ có kiểm soát | Tăng một bước xử lý | Khuyến nghị mô phỏng |
| Tiêu chí quyết định | Ngưỡng áp dụng cho OPT-NF-CR-03 |
Lý do kiểm thử |
|---|---|---|
| Tính đúng phép tính | Công nợ mở + giá trị đơn > hạn mức tín dụng |
Sai dấu so sánh làm bỏ lọt hoặc chặn sai đơn |
| Phân quyền | Sales Executive không được đặt trạng thái CONFIRMED khi vượt hạn mức |
Ngăn tự phê duyệt |
| Trạng thái | Hệ thống đặt PENDING_CREDIT_APPROVAL |
Đảm bảo đơn chưa đi sang giao hàng |
| Dấu vết quyết định | Lưu ID người quyết định, thời điểm, kết quả và lý do | Hỗ trợ kiểm tra và xử lý tranh chấp |
| Không vượt thẩm quyền | Credit Controller quyết định tín dụng; Sales Manager không thay thế quyền này trong case | Phân tách trách nhiệm mô phỏng |
Quyết định mô phỏng. Khuyến nghị OPT-NF-CR-03. Quyền quyết định nghiệp vụ thuộc Business Owner; xác nhận ảnh hưởng công nợ thuộc Accounting Owner; xác nhận cấu hình và phân quyền thuộc Solution Architect/Security Owner. TCM-NF-001 chỉ ghi nhận khuyến nghị kiểm thử tại trạng thái IN_REVIEW, không ghi nhận phê duyệt.
| Hậu quả nếu sai | Tình huống cụ thể | Tác động |
|---|---|---|
| Bỏ lọt kiểm soát | Đơn 185.400.000 VND được xác nhận khi tổng phơi nhiễm là 1.027.400.000 VND |
Nova Foods mô phỏng giao hàng vượt hạn mức 27.400.000 VND |
| Chặn sai | Hệ thống chặn đơn khi tổng phơi nhiễm bằng đúng 1.000.000.000 VND dù quy tắc dùng dấu > |
Mất doanh thu hoặc phát sinh xử lý tay không cần thiết |
| Sai phân quyền | Sales Executive tự xác nhận đơn vượt hạn mức | Mất phân tách trách nhiệm và giảm khả năng truy vết |
| Sai trạng thái | Đơn vượt hạn mức vẫn ở CONFIRMED |
Kho có thể tiếp tục giao hàng trước quyết định tín dụng |
4. Tier 3 ? Fully Completed Nova Foods Case: Evidence and Traceability
4.1 Phạm vi bằng chứng cho TCM-NF-001
Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi mã khách hàng, đơn hàng, số tiền, tài khoản và kết quả dưới đây là dữ liệu tổng hợp. Bằng chứng kiểm thử (test evidence) là dữ liệu lưu lại cho thấy test case đã được chạy, với đầu vào, kết quả thực tế, thời điểm và người chạy. Bằng chứng không biến trạng thái IN_REVIEW thành baseline, phê duyệt, xác nhận tuân thủ pháp lý hoặc quyền dùng production.
| Trường | Giá trị hoàn chỉnh |
|---|---|
| Test case | TCM-NF-001 |
| Kịch bản | Đơn bán vượt hạn mức tín dụng phải chờ Credit Controller quyết định |
| Quy tắc mô phỏng đang kiểm | OPT-NF-CR-03 |
| Môi trường | SIT-NOVA-ERP-01 — môi trường kiểm thử mô phỏng |
| Ngày chạy dự kiến | 2026-08-07 |
| Múi giờ | Asia/Ho_Chi_Minh |
| Tiền tệ | VND |
| Người chạy mô phỏng | QA-NF-TRAIN-01 |
| Trạng thái bằng chứng | NOT_EXECUTED |
| Lý do trạng thái | Corpus chỉ cung cấp case học liệu; chưa có log chạy hệ thống mô phỏng được đính kèm. Không được bịa kết quả PASS hoặc FAIL. |
4.2 Ngoại lệ và đường đi âm
Đường đi âm (negative path) kiểm tra hệ thống từ chối, chặn hoặc chuyển luồng kiểm soát khi điều kiện không hợp lệ. Ngoại lệ không phải lỗi tự động; đây là kết quả dự kiến khi dữ liệu hoặc quyền không thỏa điều kiện.
| ID | Điều kiện đầu vào tổng hợp | Hành động kiểm thử | Kết quả dự kiến | Bằng chứng cần lưu | Phân loại |
|---|---|---|---|---|---|
TCM-NF-001-EX-01 |
Khách hàng CUS-NF-10021 có công nợ mở 842.000.000 VND; đơn SO-NF-260807-014 trị giá 185.400.000 VND; tổng phơi nhiễm 1.027.400.000 VND; hạn mức 1.000.000.000 VND |
Sales Executive gửi xác nhận đơn | Không cho đơn thành CONFIRMED; đặt PENDING_CREDIT_APPROVAL; tạo yêu cầu cho Credit Controller |
Ảnh chụp trạng thái đơn, nhật ký chuyển trạng thái, ID yêu cầu tín dụng | Ngoại lệ nghiệp vụ dự kiến |
TCM-NF-001-EX-02 |
Tổng phơi nhiễm đúng 1.000.000.000 VND |
Sales Executive gửi xác nhận đơn | Không kích hoạt chờ duyệt tín dụng vì quy tắc mô phỏng dùng >; xử lý trạng thái theo luồng đơn chuẩn đang được cấu hình |
Giá trị công nợ, giá trị đơn, hạn mức, trạng thái sau gửi | Biên so sánh |
TCM-NF-001-EX-03 |
Tổng phơi nhiễm 1.027.400.000 VND; người dùng USR-NF-SALES-07 có vai trò Sales Executive |
Người dùng gọi thao tác xác nhận trực tiếp lần hai sau khi đơn đã PENDING_CREDIT_APPROVAL |
Từ chối thao tác; trạng thái giữ PENDING_CREDIT_APPROVAL; không tạo giao hàng |
Thông báo từ chối, audit log, trạng thái đơn, danh sách giao hàng rỗng | Phân quyền âm |
TCM-NF-001-EX-04 |
Tổng phơi nhiễm 1.027.400.000 VND; người dùng USR-NF-SM-03 có vai trò Sales Manager |
Người dùng chọn phê duyệt tín dụng | Từ chối vì Sales Manager không là Credit Controller trong case mô phỏng | Thông báo từ chối, audit log chứa user ID và vai trò | Phân tách trách nhiệm |
TCM-NF-001-EX-05 |
Tổng phơi nhiễm 1.027.400.000 VND; người dùng USR-NF-CC-02 có vai trò Credit Controller |
Người dùng từ chối tín dụng với lý do CREDIT_LIMIT_EXCEEDED |
Đơn không thành CONFIRMED; lưu người quyết định, thời điểm, kết quả REJECTED, lý do; không tạo giao hàng |
Audit log quyết định, trạng thái đơn, dữ liệu lý do từ chối | Quyết định âm |
TCM-NF-001-EX-06 |
Đơn vượt hạn mức nhưng thiếu giá trị công nợ mở từ nguồn mô phỏng | Sales Executive gửi xác nhận đơn | Không tự xác nhận đơn bằng dữ liệu thiếu; hiển thị lỗi dữ liệu hoặc chuyển xử lý ngoại lệ theo cấu hình được xác minh | Thông báo lỗi, log truy vấn công nợ, trạng thái đơn | Lỗi dữ liệu cần kiểm soát |
4.3 Danh mục tham chiếu bằng chứng
| Reference | Loại | Nội dung phải đối chiếu | Phân loại nguồn | Trạng thái |
|---|---|---|---|---|
TCM-NF-001-EV-01 |
Dữ liệu test | CUS-NF-10021, hạn mức 1.000.000.000 VND, công nợ mở 842.000.000 VND, đơn 185.400.000 VND |
Synthetic test data | Chưa tạo bản chạy |
TCM-NF-001-EV-02 |
Ảnh chụp giao diện | SO-NF-260807-014 ở PENDING_CREDIT_APPROVAL sau thao tác Sales Executive |
Expected execution evidence | Chưa tạo bản chạy |
TCM-NF-001-EV-03 |
Audit log | User ID, vai trò, thời điểm Asia/Ho_Chi_Minh, trạng thái trước/sau, lý do quyết định |
Expected execution evidence | Chưa tạo bản chạy |
TCM-NF-001-EV-04 |
Kiểm tra không tạo giao hàng | Không có chứng từ giao hàng gắn với SO-NF-260807-014 khi chưa có quyết định tín dụng hợp lệ |
Expected execution evidence | Chưa tạo bản chạy |
CANONICAL_BUSINESS_RULES |
Nguồn rule catalog | Xác minh OPT-NF-CR-03 có nội dung, owner và trạng thái hợp lệ trước khi dùng làm test basis |
Controlled planning artifact | IN_REVIEW; chưa baseline |
CANONICAL_DATA_DICTIONARY |
Nguồn dữ liệu logic | Xác minh định nghĩa creditLimit, công nợ mở, trạng thái đơn và trường audit trước khi cấu hình test |
Controlled planning artifact | IN_REVIEW; chưa baseline |
TRACEABILITY_ID_REGISTRY |
Registry ID | Xác minh TCM-NF-001 và OPT-NF-CR-03 không xung đột định danh |
Controlled planning artifact | IN_REVIEW; chưa baseline |
4.4 Giả định và mục cần xác minh
Giả định (assumption) là điều tạm dùng để thiết kế kiểm thử khi chưa có nguồn canonical đủ thẩm quyền. Mục “Verification required” bắt buộc được xác minh bởi owner phù hợp; không được nâng giả định thành cấu hình ERP hoặc nghĩa vụ pháp lý.
| ID | Giả định hoặc mục xác minh | Cầu nối chứng cứ và suy luận | Owner xác minh | Trạng thái |
|---|---|---|---|---|
TCM-NF-001-ASM-01 |
Công nợ mở được lấy tại thời điểm gửi xác nhận đơn | Case dùng phép tính 842.000.000 + 185.400.000; nếu công nợ là dữ liệu cũ, kết quả kiểm soát có thể sai. Chưa có đặc tả thời điểm đồng bộ. |
Solution Architect và Accounting Owner | Verification required |
TCM-NF-001-ASM-02 |
Dấu so sánh của hạn mức là > |
Bảng kịch bản xác định tổng bằng đúng hạn mức không bị chặn. Chưa có rule catalog đã baseline xác nhận dấu so sánh. | Business Owner và Accounting Owner | Verification required |
TCM-NF-001-ASM-03 |
PENDING_CREDIT_APPROVAL chặn tạo giao hàng |
Mục tiêu kiểm soát là ngăn giao hàng trước quyết định tín dụng. Chưa có state model canonical hoặc cấu hình workflow được xác nhận. | Business Owner và Solution Architect | Verification required |
TCM-NF-001-ASM-04 |
Credit Controller có quyền quyết định, Sales Executive và Sales Manager không có quyền thay thế | Cần phân tách trách nhiệm để test đường đi âm EX-03 và EX-04. Ma trận quyền chưa được cung cấp. |
Security Owner và Business Owner | Verification required |
TCM-NF-001-ASM-05 |
Audit log lưu đủ user ID, thời điểm, kết quả và lý do | Đây là bằng chứng tối thiểu để phân tích quyết định mô phỏng. Thiết kế log, thời hạn lưu và quyền truy cập chưa được xác nhận. | Security Owner và Solution Architect | Verification required |
TCM-NF-001-ASM-06 |
Không suy diễn nghĩa vụ kế toán hoặc pháp lý từ case | Luật Kế toán là nguồn pháp lý chính thức, nhưng nội dung case không có diễn giải được Accounting Owner hoặc Legal Owner xác nhận. | Accounting Owner và Legal Owner | Verification required |
4.5 Bản ghi escalation
Escalation là chuyển vấn đề vượt thẩm quyền của người viết test case đến vai trò quyết định phù hợp. Bản ghi này không xác nhận quyết định đã được đưa ra.
| Escalation ID | Vấn đề | Tác động tới TCM-NF-001 |
Người nhận | Điều kiện đóng |
|---|---|---|---|---|
ESC-NF-TCM-001-01 |
Chưa có rule canonical đã baseline xác nhận công thức phơi nhiễm tín dụng, dấu > và hành vi bằng hạn mức |
Không thể kết luận expected result của EX-01 và EX-02 là cấu hình Nova Foods thực tế |
Business Owner, Accounting Owner | Có tham chiếu rule được kiểm soát, owner xác nhận và trạng thái quản trị rõ ràng |
ESC-NF-TCM-001-02 |
Chưa có ma trận quyền canonical cho Sales Executive, Sales Manager, Credit Controller | Không thể xác nhận quyền từ chối tại EX-03 và EX-04 trên hệ thống |
Security Owner, Solution Architect | Có ma trận quyền và bằng chứng cấu hình môi trường test |
ESC-NF-TCM-001-03 |
Chưa có state model và tích hợp giao hàng được xác nhận | Không thể chứng minh PENDING_CREDIT_APPROVAL luôn ngăn tạo giao hàng |
Solution Architect, QA Lead | Có đặc tả trạng thái, điểm tích hợp và kết quả chạy kiểm thử |
ESC-NF-TCM-001-04 |
Thiết kế audit log chưa xác định mức dữ liệu, quyền truy cập, thời hạn lưu | Bằng chứng EV-03 có thể không đủ cho điều tra hoặc có rủi ro lộ dữ liệu |
Security Owner, QA Lead | Có yêu cầu log được xác minh và kiểm tra quyền truy cập môi trường test |
Ma trận truy vết đầu-cuối cho kịch bản giữ tồn kho đơn bán mô phỏng
Truy vết đầu-cuối liên kết nhu cầu với kiểm thử để chứng minh mỗi kiểm tra có lý do nghiệp vụ. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi mã hàng, khách hàng, số lượng, tiền tệ VND dưới đây là dữ liệu tổng hợp. Các ID trong bảng là ID minh họa cấp Tier 3, chưa đăng ký thành ID canonical, chưa baseline, chưa được phê duyệt. Không diễn giải chúng là cấu hình ERP hoặc quy tắc vận hành thật.
| Loại liên kết | ID | Nội dung đầy đủ | Nguồn và phân loại | Cầu nối chứng cứ và suy luận |
|---|---|---|---|---|
| NEED — nhu cầu | NEED-NF-SO-001 |
Nhân viên kinh doanh cần biết đơn bán có thể giữ tồn kho trước khi xác nhận, tránh nhận đơn vượt lượng khả dụng. | Kịch bản Nova Foods mô phỏng; nguồn nội bộ giả lập, IN_REVIEW. |
Nhu cầu nói về quyết định nhận đơn. Hệ thống phải so sánh số lượng yêu cầu với lượng khả dụng trước khi tạo cam kết giữ hàng. |
| REQ — yêu cầu | REQ-NF-SO-001 |
ERP phải từ chối xác nhận đơn bán khi requestedQty lớn hơn availableQty của cùng mã hàng và kho, không tạo bản ghi giữ tồn kho. |
Dẫn xuất từ NEED-NF-SO-001; yêu cầu mô phỏng, chưa baseline. |
Từ chối là hành vi hệ thống đo được. Điều kiện cùng mã hàng và kho ngăn việc cộng nhầm tồn kho giữa vị trí khác nhau. |
| BR — business rule, quy tắc nghiệp vụ | BR-NF-INV-001 |
Chỉ được giữ tồn kho khi requestedQty <= availableQty; lượng giữ mới bằng requestedQty; lượng khả dụng sau giữ bằng availableQty - requestedQty. |
/01-curriculum/CANONICAL_BUSINESS_RULES.md; catalog kế hoạch IN_REVIEW, không phải quy tắc vận hành Nova Foods. |
REQ-NF-SO-001 cần tiêu chí quyết định số học. Quy tắc này tạo kết quả xác định cho cả biên bằng và trường hợp vượt tồn. |
| AC — acceptance criterion, tiêu chí chấp nhận | AC-NF-SO-001 |
Với availableQty = 120 và requestedQty = 120, khi xác nhận đơn SO-SIM-20260807-001, hệ thống tạo giữ tồn 120, trả trạng thái CONFIRMED, và lượng khả dụng còn 0. |
Dẫn xuất từ REQ-NF-SO-001 và BR-NF-INV-001; tiêu chí mô phỏng, chưa baseline. |
Trường hợp bằng đúng biên kiểm tra toán tử <=. Nếu hệ thống dùng <, kết quả sẽ sai dù tồn kho đủ. |
| AC — acceptance criterion | AC-NF-SO-002 |
Với availableQty = 120 và requestedQty = 121, khi xác nhận đơn SO-SIM-20260807-002, hệ thống trả INSUFFICIENT_AVAILABLE_QTY, không tạo giữ tồn, và lượng khả dụng vẫn 120. |
Dẫn xuất từ REQ-NF-SO-001 và BR-NF-INV-001; tiêu chí mô phỏng, chưa baseline. |
Trường hợp vượt một đơn vị chứng minh hệ thống không âm tồn khả dụng và không để lại cam kết một phần không được yêu cầu. |
| DATA — dữ liệu logic | DATA-NF-INV-001 |
InventoryBalance.availableQty: số nguyên không âm, đơn vị tính BOX, phạm vi theo itemCode và warehouseCode. |
/01-curriculum/CANONICAL_DATA_DICTIONARY.md; kế hoạch từ điển dữ liệu IN_REVIEW. |
BR-NF-INV-001 cần giá trị lượng khả dụng có ngữ cảnh kho và mã hàng. Không có hai khóa này, phép so sánh không xác định đúng phạm vi tồn kho. |
| DATA — dữ liệu logic | DATA-NF-SO-001 |
SalesOrderLine.requestedQty: số nguyên dương, đơn vị tính phải khớp InventoryBalance.availableQty. |
/01-curriculum/CANONICAL_DATA_DICTIONARY.md; kế hoạch từ điển dữ liệu IN_REVIEW. |
So sánh chỉ có nghĩa khi hai lượng dùng cùng đơn vị. Case mô phỏng dùng BOX; chưa suy diễn quy đổi đơn vị cho ERP thật. |
| API — hợp đồng giao tiếp | API-NF-SO-001 |
POST /api/v1/sales-orders/{salesOrderId}/confirm nhận salesOrderId; phản hồi thành công có status: "CONFIRMED"; phản hồi thiếu tồn có mã INSUFFICIENT_AVAILABLE_QTY. |
OpenAPI Specification OAS 3.1.1 là nguồn chuẩn cho mô tả HTTP API; endpoint và mã lỗi là thiết kế mô phỏng, chưa baseline. | AC-NF-SO-001 và AC-NF-SO-002 cần điểm quan sát cho kiểm thử. HTTP response cho phép test chứng minh kết quả xác nhận hoặc từ chối. |
| TC — test case, ca kiểm thử | TC-NF-SO-001 |
Xác nhận đơn SO-SIM-20260807-001 với NF-TEA-BOX-500G, kho WH-HCM-01, yêu cầu 120 BOX, khả dụng 120 BOX; mong đợi CONFIRMED, giữ 120 BOX, khả dụng 0 BOX. |
/03-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md; Tier 3 mô phỏng, IN_REVIEW. Thuật ngữ test case theo ISTQB CTFL v4.0.1. |
Ca này thực thi trực tiếp AC-NF-SO-001. Dữ liệu biên loại trừ lỗi toán tử nghiêm ngặt. |
| TC — test case | TC-NF-SO-002 |
Xác nhận đơn SO-SIM-20260807-002 với NF-TEA-BOX-500G, kho WH-HCM-01, yêu cầu 121 BOX, khả dụng 120 BOX; mong đợi INSUFFICIENT_AVAILABLE_QTY, không giữ tồn, khả dụng 120 BOX. |
/03-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md; Tier 3 mô phỏng, IN_REVIEW. Thuật ngữ test case theo ISTQB CTFL v4.0.1. |
Ca âm thực thi trực tiếp AC-NF-SO-002. Nó chứng minh hệ thống bảo toàn tồn khả dụng khi từ chối. |
| DEF — defect, lỗi | DEF-NF-SO-001 |
Không có lỗi được ghi nhận trong micro-batch này. Không tạo defect chỉ để đủ họ ID. | Không áp dụng; chưa có kết quả chạy test hoặc bằng chứng lỗi. | DEF chỉ tồn tại khi quan sát thực tế khác kết quả mong đợi. Dữ liệu hiện có là thiết kế kiểm thử, không phải kết quả thực thi. |
| CR — change request, yêu cầu thay đổi | CR-NF-SO-001 |
Không có yêu cầu thay đổi được ghi nhận trong micro-batch này. | Không áp dụng; chưa có baseline để thay đổi. | Change request cần đối tượng baseline hoặc quyết định đã kiểm soát. Corpus hiện IN_REVIEW, nên không được dựng CR giả. |
| Đường truy vết kiểm tra | Kết quả |
|---|---|
NEED-NF-SO-001 → REQ-NF-SO-001 → BR-NF-INV-001 → AC-NF-SO-001 → TC-NF-SO-001 |
Đầy đủ cho biên đủ tồn kho. |
NEED-NF-SO-001 → REQ-NF-SO-001 → BR-NF-INV-001 → AC-NF-SO-002 → TC-NF-SO-002 |
Đầy đủ cho đường âm vượt tồn kho. |
BR-NF-INV-001 → DATA-NF-INV-001, DATA-NF-SO-001 → API-NF-SO-001 |
Đầy đủ tại mức dữ liệu logic và điểm quan sát API mô phỏng. |
TC-NF-SO-001, TC-NF-SO-002 → DEF-NF-SO-001 hoặc CR-NF-SO-001 |
Chưa kích hoạt. Cần kết quả chạy test và kiểm soát baseline trước khi tạo DEF hoặc CR. |
Nguồn chuẩn chỉ giới hạn thuật ngữ: ISTQB CTFL v4.0.1 cho kiểm thử; OAS 3.1.1 cho mô tả API. Không có nguồn nào xác nhận quy tắc tồn kho này cho doanh nghiệp thật. Trước khi dùng ngoài học liệu, Business Owner, Architect và QA Owner phải xác minh quy tắc, mô hình tồn kho, endpoint, mã lỗi và trạng thái baseline.
Bảng quyết định và dữ liệu kiểm thử: ghi nhận nhập kho nguyên liệu mô phỏng
Bảng quyết định là kỹ thuật kiểm thử hộp đen: liệt kê điều kiện đầu vào và hành động mong đợi để không bỏ sót tổ hợp nghiệp vụ. Tình huống Nova Foods Trading & Manufacturing là mô phỏng giáo dục; toàn bộ mã lô, nhà cung cấp, số lượng và giá trị dưới đây là dữ liệu tổng hợp. Phạm vi chỉ kiểm tra quyết định ghi nhận phiếu nhập kho nguyên liệu, không xác nhận cấu hình ERP thật, quy định kế toán hay tuân thủ an toàn thực phẩm.
| Điều kiện hoặc hành động | Quy tắc 1 | Quy tắc 2 | Quy tắc 3 | Quy tắc 4 |
|---|---|---|---|---|
Mã nguyên liệu RM-SUGAR-001 tồn tại trong danh mục mô phỏng |
Có | Có | Có | Không |
Mã lô nhà cung cấp LOT-SUP-260807-A được nhập |
Có | Có | Không | Có |
Số lượng nhận 500.000 kg lớn hơn 0 |
Có | Không | Có | Có |
Hạn dùng 2027-08-06 sau ngày nhận 2026-08-07 |
Có | Có | Có | Có |
Tạo phiếu nhập kho trạng thái DRAFT |
Có | Không | Không | Không |
| Cập nhật tồn kho nguyên liệu | Không | Không | Không | Không |
| Hiển thị lỗi kiểm tra dữ liệu | Không | Có | Có | Có |
| Thông báo mong đợi | Phiếu nhập kho mô phỏng đã được lưu nháp. |
Số lượng nhận phải lớn hơn 0. |
Mã lô nhà cung cấp là bắt buộc. |
Mã nguyên liệu không tồn tại trong danh mục mô phỏng. |
Dữ liệu kiểm thử dùng số thập phân dấu chấm theo payload kỹ thuật; giao diện vi-VN có thể hiển thị 500,000 kg. Giá trị 12.500 VND/kg là giả định học liệu để kiểm tra phép tính 6.250.000 VND; không phải giá mua, chính sách định giá hay bút toán Nova Foods.
| Ca kiểm thử | Dữ liệu đầu vào tổng hợp | Kết quả quyết định |
|---|---|---|
TC-NF-INV-001 |
RM-SUGAR-001; LOT-SUP-260807-A; 500.000 kg; 2027-08-06; 12.500 VND/kg |
Lưu DRAFT; tổng dòng 6.250.000 VND; tồn kho chưa đổi. |
TC-NF-INV-002 |
RM-SUGAR-001; LOT-SUP-260807-A; 0.000 kg; 2027-08-06; 12.500 VND/kg |
Không lưu phiếu; báo lỗi số lượng. |
TC-NF-INV-003 |
RM-SUGAR-001; chuỗi rỗng; 500.000 kg; 2027-08-06; 12.500 VND/kg |
Không lưu phiếu; báo lỗi mã lô. |
TC-NF-INV-004 |
RM-UNKNOWN-999; LOT-SUP-260807-A; 500.000 kg; 2027-08-06; 12.500 VND/kg |
Không lưu phiếu; báo lỗi mã nguyên liệu. |
Payload dưới là dữ liệu trao đổi API mô phỏng, không phải đặc tả OpenAPI đã baseline. Kiểu number giữ phép tính máy; currency là VND; thời điểm dùng Asia/Ho_Chi_Minh.
{
"receiptNo": "GRN-SIM-20260807-001",
"receiptDate": "2026-08-07",
"timezone": "Asia/Ho_Chi_Minh",
"warehouseCode": "WH-RM-HCM-01",
"supplierCode": "SUP-SIM-014",
"currency": "VND",
"lines": [
{
"lineNo": 1,
"materialCode": "RM-SUGAR-001",
"supplierLotNo": "LOT-SUP-260807-A",
"expiryDate": "2027-08-06",
"receivedQuantity": 500.000,
"uom": "KG",
"unitPrice": 12500,
"lineAmount": 6250000
}
],
"status": "DRAFT"
}
lineAmount = receivedQuantity × unitPrice; bằng 500.000 × 12.500 = 6.250.000 VND. Quy tắc này là dữ liệu kiểm thử mô phỏng, cần đối chiếu Business Owner và Accounting Owner trước khi dùng làm quy tắc vận hành.
5. Tier 4 ? Senior BA Quality Gate
Quality Gate là cổng kiểm tra trước baseline: Senior BA xác nhận artifact đủ để chuyển sang bước xem xét thẩm quyền, không xác nhận nghiệp vụ đúng, không tạo baseline, không tạo phê duyệt. Phạm vi áp dụng: /03-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, bối cảnh Nova Foods Trading & Manufacturing mô phỏng giáo dục, chỉ dữ liệu tổng hợp.
| Mã kiểm tra | Điểm kiểm tra | PASS | FAIL | STOP | Escalation |
|---|---|---|---|---|---|
| QG-TCM-01 | Tính đầy đủ | Mỗi test case có ID, mục tiêu, tiền điều kiện, dữ liệu, bước, kết quả mong đợi, kết quả quyết định và liên kết truy vết. | Thiếu trường nhưng vẫn xác định được phần thiếu, không làm đổi ý nghĩa test. | Thiếu ID, kết quả mong đợi hoặc dữ liệu đầu vào; không thể thực thi hay đối chiếu test. | Không cần nếu Senior BA sửa được từ nguồn đã xác định. |
| QG-TCM-02 | Tính nhất quán | Mã nguyên liệu, lô, kho, đơn vị, tiền tệ, ngày, trạng thái và phép tính giống nhau giữa bảng test, payload và mô tả. | Sai định dạng trình bày nhưng không đổi dữ liệu hay kết quả. | Hai nguồn trong cùng artifact cho kết quả khác nhau, như lineAmount khác phép nhân đã nêu. |
Không cần nếu chỉ sửa lỗi sao chép có bằng chứng nguồn. |
| QG-TCM-03 | Tính kiểm thử được | Điều kiện bắt đầu, đầu vào, hành động và kết quả quan sát được; tester độc lập có thể kết luận đạt hoặc không đạt. | Câu chữ chưa rõ nhưng có thể làm rõ mà không đổi rule. | Kết quả dùng từ chủ quan như “hợp lệ”, “đúng”, “nhanh” mà không có tiêu chí đo hay quyết định hệ thống. | Không cần nếu Senior BA chuyển thành điều kiện quan sát được. |
| QG-TCM-04 | Traceability, nghĩa là truy vết hai chiều | Mỗi test liên kết được tới test basis, gồm requirement, business rule, acceptance criterion hoặc data definition; liên kết quay lại xác định được test bị ảnh hưởng. | Liên kết có mặt nhưng nhãn hiển thị chưa thống nhất. | Không có test basis, ID không tồn tại trong artifact canonical, hoặc một test mâu thuẫn nguồn canonical. | Dừng cập nhật baseline cho phần bị đứt truy vết. |
| QG-TCM-05 | Thẩm quyền nguồn | Nguồn được phân loại rõ: canonical, verified primary source, project assumption hoặc Verification required; không biến học liệu thành nghĩa vụ pháp lý. |
Nguồn đúng nhưng thiếu ngày truy cập hoặc nhãn phân loại. | Trích dẫn pháp luật, kế toán, thuế, riêng tư, hóa đơn hoặc an toàn thực phẩm như kết luận áp dụng mà chưa có chủ thể thẩm quyền xác minh. | Dừng dùng nội dung đó làm expected result bắt buộc. |
| QG-TCM-06 | Ownership, nghĩa là quyền chịu trách nhiệm | Mỗi quyết định có owner phù hợp; Senior BA chỉ ghi nhận và điều phối, không tự thay thế thẩm quyền. | Vai trò reviewer chưa ghi thời điểm nhưng phạm vi trách nhiệm rõ. | Senior BA, template owner hoặc QA tự xác nhận quyết định thuộc Business Owner, Legal Owner, Accounting Owner, Security Owner hay Architect. | Dừng ghi nhận quyết định như đã xác nhận. |
| QG-TCM-07 | Ranh giới bảo mật và riêng tư | Payload tổng hợp, không chứa dữ liệu cá nhân thật, bí mật xác thực, token, mật khẩu, địa chỉ thật hay dữ liệu production; quyền truy cập mô tả ở mức kiểm thử. | Có dữ liệu nhạy cảm tổng hợp nhưng chưa gắn nhãn phân loại. | Có dữ liệu cá nhân thật, secret, thông tin truy cập hoặc yêu cầu bảo mật không có Security Owner xác minh. | Dừng chia sẻ artifact ngoài nhóm kiểm soát; thay dữ liệu bằng dữ liệu tổng hợp. |
| QG-TCM-08 | Ranh giới pháp lý, kế toán và thuế | Test chỉ kiểm tra hành vi mô phỏng đã nêu; nội dung chưa xác minh được gắn project assumption hoặc Verification required. |
Có giả định hợp lệ nhưng chưa nêu đường chuyển xác minh. | Test suy diễn bút toán, thuế, hóa đơn, lưu trữ chứng từ hoặc nghĩa vụ pháp lý thành kết quả bắt buộc. | Dừng phát biểu đó như quy tắc ERP hay kết luận tuân thủ. |
| QG-TCM-09 | Ảnh hưởng thay đổi | Thay đổi mã dữ liệu, quy tắc, trạng thái, payload hoặc nguồn nêu rõ test case và artifact truy vết bị ảnh hưởng. | Danh sách ảnh hưởng chưa có thứ tự xử lý nhưng xác định được phạm vi. | Thay đổi làm mất liên kết, đổi expected result hoặc làm mâu thuẫn artifact canonical mà không có đánh giá ảnh hưởng. | Dừng merge hoặc baseline candidate cho thay đổi đó. |
Quy tắc quyết định: PASS chỉ khi mọi kiểm tra không có FAIL hoặc STOP. FAIL yêu cầu sửa và kiểm tra lại trước khi chuyển tiếp. Chỉ một STOP đủ chặn baseline candidate của phần liên quan. Escalation là chuyển gói bằng chứng gồm ID, dữ liệu tổng hợp, nguồn, mâu thuẫn, ảnh hưởng và câu hỏi quyết định đến đúng owner; không phải yêu cầu Senior BA tự kết luận thay owner.
Ma trận kiểm soát chất lượng Senior BA: phạm vi và bằng chứng
Quality gate là cổng kiểm soát trước baseline: Senior BA kiểm tra hồ sơ Tier 3 có đủ cơ sở để QA thiết kế và thực thi kiểm thử, nhưng không tự xác nhận phê duyệt, tuân thủ hay sẵn sàng production. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND.
| Mục kiểm soát | Câu hỏi kiểm tra từ nguyên lý | Bằng chứng phải có trong hồ sơ Tier 3 | Ranh giới thẩm quyền |
|---|---|---|---|
| Tính đầy đủ | Mỗi test case có mục tiêu, tiền điều kiện, dữ liệu, bước, kết quả mong đợi, ngoại lệ và kết quả liên kết không? Nếu thiếu một phần, người test phải tự đoán. | Test case mapping điền đủ từng trường; mỗi bước có kết quả mong đợi quan sát được; dữ liệu Nova Foods là tổng hợp. | Senior BA kiểm tra độ đủ của tài liệu, không thay QA xác nhận kết quả chạy test. |
| Tính nhất quán | Cùng một thuật ngữ, ID, trạng thái, dữ liệu và quy tắc có cùng nghĩa ở mọi liên kết không? Mâu thuẫn làm một yêu cầu sinh nhiều cách hiểu. | ID giữ nguyên dạng canonical; trạng thái artifact IN_REVIEW; version v0.9.0; ngày 2026-08-07; không gọi nội dung là baseline hoặc approved. |
Principal IT Business Analyst / Technical Curriculum Author quản trị artifact; Business Owner quyết định ý nghĩa nghiệp vụ thực. |
| Khả năng kiểm thử | Kết quả mong đợi có thể quan sát, so sánh và lặp lại không? Câu như “hệ thống xử lý đúng” không kiểm thử được vì không nêu điều kiện hay kết quả. | Điều kiện đầu vào, thao tác, đầu ra, thông báo lỗi hoặc trạng thái mong đợi; tiêu chí pass/fail không mơ hồ. Thuật ngữ black-box testing là kiểm thử theo đầu vào và đầu ra, không cần biết mã nguồn. | QA Owner chọn kỹ thuật test và xác nhận thực thi. ISTQB CTFL v4.0.1 chỉ là nguồn thuật ngữ kiểm thử. |
| Truy vết | Mỗi test case lần ngược được tới requirement, business rule, dữ liệu và nguồn không? Mỗi requirement đi xuôi được tới ít nhất một test case không? | Liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY khi các artifact này chứa ID tương ứng; giữ nguyên đường dẫn canonical trong liên kết. |
Senior BA duy trì liên kết; không tự tạo requirement, rule hoặc ID chưa đăng ký. |
| Thẩm quyền nguồn | Nguồn có đúng loại cho phát biểu đang dùng không? Nguồn thuật ngữ không đủ để kết luận nghĩa vụ pháp lý. | BABOK Guide v3 cho thuật ngữ BA; ISTQB CTFL v4.0.1 cho thuật ngữ test; nguồn pháp lý phải dùng URL chính thức trong 00_SOURCE_MAP. Không ghi số điều hoặc diễn giải chi tiết khi chưa kiểm tra văn bản được cấp phép hoặc nguồn chính thức hiện hành. |
Legal Owner xác nhận pháp luật; Accounting Owner xác nhận kế toán; không suy diễn từ học liệu. |
| Ownership | Mỗi quyết định, dữ liệu test, rule và ngoại lệ có vai trò chịu trách nhiệm rõ không? Không rõ owner thì lỗi không có nơi xử lý. | Ghi owner theo loại quyết định: Business Owner cho nghiệp vụ; QA Owner cho test execution; Security Owner cho kiểm soát bảo mật; Legal/Compliance Owner cho pháp lý và dữ liệu cá nhân; Accounting Owner cho hạch toán. | Một người giữ artifact không thay thế các owner chuyên môn. |
| Bảo mật và dữ liệu cá nhân | Test có dùng dữ liệu nhận diện cá nhân, bí mật đăng nhập, token, dữ liệu tài chính thật hoặc dữ liệu production không? Nếu có, dữ liệu tổng hợp không còn đủ an toàn nếu bị định danh lại. | Chỉ dùng khách hàng, nhân viên, nhà cung cấp và chứng từ giả lập; không ghi mật khẩu, secret, token, số định danh thật. Nếu có API, mô tả HTTP và payload phải che dữ liệu nhạy cảm. | OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 là chuẩn thực hành, không phải luật Việt Nam. Security Owner xác nhận kiểm soát. |
| Pháp lý, kế toán, an toàn thực phẩm | Test case có biến giả định thành nghĩa vụ pháp lý, thuế, hóa đơn, hạch toán, truy xuất hay thu hồi thực phẩm không? Đây là ranh giới chuyên môn cao. | Gắn nhãn Project assumption hoặc Verification required cho chi tiết chưa đối chiếu nguồn chính thức hiện hành. Tham chiếu Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP, Luật 55/2010/QH12 chỉ theo ranh giới nguồn trong 00_SOURCE_MAP. |
Legal Owner, Accounting Owner và domain owner xác nhận; Senior BA không diễn giải luật hay quyết định bút toán. |
| Ảnh hưởng thay đổi | Khi requirement, rule, dữ liệu hay API đổi, test case nào phải xem lại? Không có liên kết ảnh hưởng sẽ bỏ sót regression. | Mỗi thay đổi ghi artifact nguồn, ID bị ảnh hưởng, test case mapping bị ảnh hưởng, dữ liệu test và owner xem xét; giữ IN_REVIEW đến khi thay đổi được ghi nhận theo governance. |
Architect đánh giá thiết kế; QA Owner đánh giá regression; Business Owner quyết định ưu tiên nghiệp vụ. |
Áp dụng vào ví dụ Nova Foods hoàn chỉnh trong /03-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md: kiểm tra phải xác nhận mọi trường Tier 3 đã điền bằng dữ liệu tổng hợp, không còn placeholder mô tả; trạng thái, version, ngày, locale và tiền tệ khớp contract hiện hành. Liên kết rule, data dictionary và registry chỉ hợp lệ khi dùng đúng ID canonical đã tồn tại trong artifact nguồn; tên gần giống không đủ bằng chứng truy vết.
Ví dụ có liên quan dữ liệu khách hàng, hóa đơn, bút toán, lô thực phẩm hoặc truy xuất nguồn gốc phải được đọc là case mô phỏng. Nếu mô tả kết quả test chứa kết luận “tuân thủ pháp luật”, “hóa đơn hợp lệ”, “bút toán đúng” hoặc “đủ điều kiện truy xuất”, hồ sơ phải gắn Verification required; lý do: các kết luận này vượt thẩm quyền của test case mapping và cần owner chuyên môn đối chiếu nguồn chính thức hiện hành.
Áp dụng Quality Gate cho hồ sơ Nova Foods đã hoàn tất
Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Đối tượng review: hồ sơ Tier 3 trong /03-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.
| Hạng mục kiểm tra | Bằng chứng và cầu nối suy luận | Kết quả | Phát hiện | Hành động trước baseline |
|---|---|---|---|---|
| Đầy đủ mapping | Hồ sơ Tier 3 phải nối requirement, business rule, acceptance criterion, test case, dữ liệu kiểm thử, kết quả mong đợi và ngoại lệ. Chuỗi này cho phép QA chứng minh từng yêu cầu có kiểm thử. | PASS có điều kiện | Cấu trúc mapping có đủ loại liên kết cần thiết; phải đối chiếu từng ID với nguồn canonical khi baseline. | Giữ toàn bộ liên kết; không tự thay ID. |
| Nhất quán dữ liệu | Giá trị tiền phải dùng VND; ngày và giờ phải theo vi-VN và Asia/Ho_Chi_Minh. Đây là điều kiện để expected result không mâu thuẫn dữ liệu test. |
PASS | Không ghi nhận đơn vị tiền hoặc locale khác trong phạm vi hồ sơ được review. | Rerun review nếu test data thay đổi locale, tiền tệ hoặc định dạng ngày. |
| Khả năng kiểm thử | Test case phải có tiền điều kiện, bước thực hiện, test data, expected result và tiêu chí pass/fail quan sát được. “Kiểm thử được” nghĩa là hai người kiểm thử có thể chạy cùng case và so kết quả với cùng tiêu chí. | PASS có điều kiện | Expected result nghiệp vụ có thể kiểm tra; kết quả tích hợp, hiệu năng hoặc quyền production không được suy diễn từ hồ sơ mô phỏng. | QA xác nhận môi trường và dữ liệu test trước execution. |
| Traceability | Liên kết phải quay về artifact canonical: /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md. |
FAIL — STOP | Các artifact upstream đang IN_REVIEW; không có baseline reference hoặc approval reference. Vì vậy không thể xác nhận ID nguồn đã cố định. |
Dừng baseline của mapping. Chỉ tiếp tục khi registry, rule catalog và data dictionary có trạng thái tham chiếu hợp lệ. |
| Thẩm quyền nguồn | BABOK Guide dùng cho thuật ngữ BA; ISTQB CTFL dùng cho thuật ngữ kiểm thử. Luật và nghị định Việt Nam chỉ là nguồn pháp lý; diễn giải thành nghĩa vụ ERP cần owner có thẩm quyền. | PASS có điều kiện | Không coi nguồn học liệu là phê duyệt pháp lý, kế toán hoặc vận hành. | Legal, Accounting hoặc Compliance Owner xác minh mọi requirement phát sinh từ luật. |
| Ownership | Principal IT Business Analyst / Technical Curriculum Author quản trị artifact, không có quyền phê duyệt baseline, nghiệp vụ, pháp lý, kế toán, bảo mật hoặc production. | PASS | Ranh giới Owner rõ trong upstream governance. | Gán reviewer có thẩm quyền theo từng finding trước baseline. |
| Bảo mật và riêng tư | Nếu test data chứa dữ liệu cá nhân, phải xác định mục đích, quyền truy cập, hiển thị và lưu giữ. Case hiện dùng dữ liệu tổng hợp nên không chứng minh tuân thủ Luật 91/2025/QH15 hoặc Nghị định 356/2025/NĐ-CP. | PASS có điều kiện | Không có bằng chứng dữ liệu cá nhân thật; không được suy ra compliance. | Security/Privacy Owner review khi thêm dữ liệu định danh hoặc API thật. |
| Pháp lý, kế toán, hóa đơn | Luật Kế toán và Nghị định 123/2020/NĐ-CP là nguồn authority bên ngoài; mapping test không được tự xác nhận cách hạch toán, chứng từ hoặc hóa đơn hợp lệ. | STOP nếu có claim | Chưa có sign-off từ Accounting Owner hoặc Legal Owner; mọi diễn giải là Verification required. |
Escalate đến Accounting Owner và Legal Owner nếu expected result kết luận nghĩa vụ kế toán, thuế hoặc hóa đơn. |
| An toàn thực phẩm và truy xuất | Luật An toàn thực phẩm cung cấp bối cảnh; không tự tạo rule recall, lot traceability hoặc quyết định vận hành từ nguồn này. | PASS có điều kiện | Case mô phỏng không chứng minh quy trình thực phẩm thực tế. | Domain Owner và Legal Owner xác minh nếu mapping bao phủ lô hàng, thu hồi hoặc truy xuất. |
| Tác động thay đổi | Sửa requirement, rule, data definition, API contract hoặc expected result có thể làm test case liên kết không còn đúng. | FAIL — STOP | Chưa có baseline reference cho nguồn upstream; chưa thể đánh giá delta so với baseline. | Không baseline mapping. Lập change record sau khi nguồn canonical được baseline hợp lệ. |
Kết luận review: STOP — PRE-BASELINE REWORK REQUIRED. Lý do: traceability nguồn chưa có baseline reference; các ranh giới pháp lý, kế toán, riêng tư và domain vẫn cần xác minh bởi owner có thẩm quyền. Kết quả này ghi nhận finding review, không phải approval, không phải baseline, không xác nhận compliance và không cho phép dùng production.
6. Cross-File Checks, Open Issues, and Escalation
6.1 Kiểm tra chéo nguồn kiểm soát
Kiểm tra chéo nhằm phát hiện mâu thuẫn trước khi dùng mapping test case làm đầu vào cho kiểm thử, review hoặc handoff. “Canonical” nghĩa là nguồn chuẩn duy nhất được phép quyết định một loại thông tin. Mapping này chỉ liên kết requirement, rule, data, expected result và bằng chứng; không thay thế manifest, registry, catalog rule hay data dictionary.
| Đối tượng kiểm tra | Nguồn canonical phải đối chiếu | Tiêu chí không mâu thuẫn | Kết quả tại IN_REVIEW |
Quy tắc xử lý |
|---|---|---|---|---|
| Danh tính template | /01-curriculum/TEMPLATE_MANIFEST.md |
Artifact ID, filename, status và version của TMPL-TCM-001 phải trùng manifest. |
Chưa có trích đoạn manifest xác nhận entry TMPL-TCM-001 trong đầu vào micro-batch. |
Không tự tạo entry manifest, không đổi filename và không gọi template là baseline. |
| ID traceability | /01-curriculum/TRACEABILITY_ID_REGISTRY.md |
Mọi ID requirement, rule, data, test case, evidence được dùng phải có namespace và ý nghĩa đúng registry. | Registry là nguồn canonical đã xác định; nội dung entry cụ thể cho các ID mapping chưa được cung cấp. | Không suy diễn ID hợp lệ từ hình thức tên. Giữ nguyên ID đã đăng ký; dừng liên kết mới khi không xác minh được registry. |
| Quy tắc nghiệp vụ | /01-curriculum/CANONICAL_BUSINESS_RULES.md |
Expected result phải kiểm tra rule đã catalog; không biến giả định học liệu thành rule bắt buộc. | Catalog có status IN_REVIEW; không có rule Nova Foods cụ thể trong đầu vào này. |
Không kết luận PASS cho rule chưa có canonical reference. Gắn Verification required tại artifact nguồn khi rule liên quan pháp lý, kế toán, thuế, hóa đơn, riêng tư hoặc an toàn thực phẩm. |
| Dữ liệu kiểm thử | /01-curriculum/CANONICAL_DATA_DICTIONARY.md |
Field, kiểu dữ liệu, mã, trạng thái, đơn vị tiền tệ và quan hệ dữ liệu phải khớp dictionary. | Dictionary là nguồn canonical đã xác định; định nghĩa field cụ thể chưa được cung cấp. | Chỉ dùng dữ liệu tổng hợp Nova Foods. Không tự định nghĩa schema, mã trạng thái hay quy tắc làm tròn VND. |
| Cấu trúc học liệu | /01-curriculum/01_CURRICULUM_ARCHITECTURE.md và /01-curriculum/CHAPTER_MANIFEST.md |
Mapping phải nhận test basis từ chapter trước; không tự tạo requirement hoặc acceptance criterion. | Hai artifact cùng IN_REVIEW, v0.9.0, ngày 2026-08-07; chưa có baseline hoặc approval. |
Mapping chỉ là học liệu mô phỏng. Không diễn giải liên kết chapter là xác nhận nghiệp vụ Nova Foods. |
| Nguồn phương pháp test | /00-research/00_SOURCE_MAP.md |
Thuật ngữ test dùng đúng boundary nguồn; không gán điều khoản, trích dẫn hoặc nghĩa vụ không được xác minh. | ISTQB CTFL v4.0.1 là nguồn thuật ngữ kiểm thử; nguồn pháp lý và chuẩn giữ boundary riêng. | Không dùng mapping để xác nhận compliance, security certification, legal validity hoặc production readiness. |
| Consumer hạ nguồn | Test execution record, defect record, RTM, QA review, release decision và evidence repository khi các artifact này được tạo | Consumer phải giữ nguyên ID nguồn, version, status và phân loại synthetic. | Consumer cụ thể chưa được cung cấp trong micro-batch này. | Không phát hành mapping như test basis đã ổn định. Consumer phải đọc IN_REVIEW và không được nâng trạng thái ngầm định. |
6.2 Quy tắc quyết định khi phát hiện mâu thuẫn
Mâu thuẫn tồn tại khi cùng một ID có hai ý nghĩa, một field có hai định nghĩa, expected result trái canonical rule, filename khác manifest, hoặc consumer diễn giải IN_REVIEW thành APPROVED hay BASELINED. Bằng chứng là các artifact nguồn đều nêu rõ IN_REVIEW không phải approval, baseline, compliance hay quyền dùng production. Vì chưa có baseline reference trong dependency được cung cấp, mapping test case không có quyền chốt phiên bản requirement, rule hoặc data.
Nếu manifest và registry khác nhau, manifest quyết định sự tồn tại và đường dẫn artifact, còn registry quyết định ý nghĩa và phạm vi ID. Nếu canonical business rules và data dictionary khác mapping, catalog rule quyết định logic nghiệp vụ, dictionary quyết định cấu trúc và giá trị dữ liệu; mapping phải được sửa để phản ánh nguồn canonical, không sửa nguồn canonical bằng suy luận từ test case. Nếu nguồn pháp lý, kế toán, hóa đơn, riêng tư hoặc an toàn thực phẩm bị diễn đạt như rule ERP Nova Foods, dừng kết luận kiểm thử vì /00-research/00_SOURCE_MAP.md chỉ cho phép dùng các nguồn này trong boundary đã nêu.
6.3 Kết quả kiểm tra chéo của micro-batch
| Hạng mục | Kết quả | Lý do có bằng chứng |
|---|---|---|
| Status, version, date, locale và dữ liệu mô phỏng | Nhất quán ở cấp governance | Dependency đều ghi IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND và Nova Foods là mô phỏng giáo dục. |
| Baseline và approval | Không tồn tại để tham chiếu | Manifest, architecture, registry và canonical catalog đều ghi chưa có baseline reference hoặc approval reference. |
| Thẩm quyền nghiệp vụ, pháp lý, kế toán, bảo mật | Không được chuyển sang template mapping | Owner chỉ duy trì governance; các dependency giữ authority boundary cho Business Owner, Legal Owner, Accounting Owner, Security, Architect và QA. |
| ID, rule, data và consumer cụ thể | Chưa thể xác nhận hoàn toàn | Đầu vào không chứa entry registry, rule catalog, data definition hoặc consumer record cụ thể của TMPL-TCM-001. |
Trạng thái kiểm tra: STOP — PRE-BASELINE REWORK REQUIRED. Kết quả chỉ xác nhận giới hạn bằng chứng hiện có của học liệu Nova Foods mô phỏng, dữ liệu tổng hợp. Kết quả không phải approval, baseline, xác nhận requirement, xác nhận tuân thủ hoặc cho phép sử dụng production.
6.1 Sổ vấn đề mở, giả định và mục cần xác minh
Sổ này giữ handoff có kiểm soát cho TMPL-TCM-001_TEST_CASE_MAPPING. Vấn đề mở là điểm chưa thể kết luận từ nguồn hiện có. Giả định dự án là điều tạm dùng để soạn học liệu, không phải quy tắc vận hành. Cần xác minh là nội dung phải được vai trò có thẩm quyền kiểm tra trước khi dùng như yêu cầu. Bằng chứng: mọi artifact nguồn đều IN_REVIEW, v0.9.0, ngày 2026-08-07; không có baseline hay approval. Nova Foods là case mô phỏng, chỉ dùng dữ liệu tổng hợp.
| ID | Loại | Nội dung, bằng chứng và suy luận | ID bị ảnh hưởng | Owner xử lý | Tác động | Hành động kế tiếp |
|---|---|---|---|---|---|---|
OI-TCM-001 |
Vấn đề mở | Chưa có test case Nova Foods đã được baseline để xác nhận tập giá trị test data, expected result và verdict. TRACEABILITY_ID_REGISTRY mới là kế hoạch registry IN_REVIEW; suy ra không được gọi mapping hiện tại là coverage đã chấp nhận. |
TMPL-TCM-001, TRACEABILITY_ID_REGISTRY |
Principal IT Business Analyst / Technical Curriculum Author | Mapping chỉ là mẫu học liệu; không đủ căn cứ release hay sign-off QA. | Ghi nhận bộ test case tổng hợp vào artifact kiểm soát khi phạm vi chapter/template được soạn; QA Reviewer kiểm tra tính testable. |
OI-TCM-002 |
Vấn đề mở | Chưa có requirement, acceptance criterion, business rule hoặc data-field Nova Foods cụ thể được phê duyệt. CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều là plan IN_REVIEW; suy ra không được tự tạo liên kết rule-to-test mang nghĩa vận hành. |
TMPL-TCM-001, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY |
Business Owner cho nghiệp vụ; Principal IT Business Analyst / Technical Curriculum Author duy trì traceability | Test case có thể thiếu test basis, hoặc tạo rule giả thành rule chuẩn. | Chỉ dùng ID đã đăng ký khi catalog có nội dung; nếu thiếu, giữ nhãn vấn đề mở và escalation, không thay bằng quy tắc tự suy diễn. |
ASM-TCM-001 |
Giả định dự án | Mỗi dòng mapping dùng quan hệ tối thiểu Test Case ID–Test Basis ID–Test Data ID–Evidence ID–Verdict. Lý do: ISTQB CTFL dùng test basis và testware để liên kết kiểm thử; đây là cấu trúc học liệu, không phải định nghĩa bắt buộc từ nguồn. |
TMPL-TCM-001, TRACEABILITY_ID_REGISTRY |
Principal IT Business Analyst / Technical Curriculum Author | Tạo cấu trúc nhất quán để learner truy từ test về căn cứ. | Xác minh naming pattern và loại ID với registry trước khi phát hành bản template cập nhật. |
ASM-TCM-002 |
Giả định dự án | Dữ liệu tiền tệ trong test case dùng VND, locale vi-VN, thời gian Asia/Ho_Chi_Minh. Bằng chứng: metadata corpus thống nhất các giá trị này; suy ra chỉ áp dụng cho dữ liệu tổng hợp Nova Foods. |
TMPL-TCM-001, CHAPTER_MANIFEST, TEMPLATE_MANIFEST |
Principal IT Business Analyst / Technical Curriculum Author | Tránh trộn locale hoặc tiền tệ trong ví dụ; không xác nhận cấu hình ERP thực tế. | Kiểm tra mọi payload mẫu sau này không chứa dữ liệu cá nhân hay dữ liệu doanh nghiệp thật. |
VR-TCM-001 |
Cần xác minh | Các test case chạm dữ liệu cá nhân, phân quyền, API hoặc log cần Security Owner và Legal/Compliance Owner xác minh. Bằng chứng: Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, OWASP ASVS 5.0.0 và OWASP API Security Top 10 chỉ là nguồn hoặc chuẩn tham chiếu; corpus cấm tự diễn giải thành nghĩa vụ hệ thống. | TMPL-TCM-001, CANONICAL_DATA_DICTIONARY, 00_SOURCE_MAP |
Security Owner; Legal/Compliance Owner | Không được kết luận compliant, đủ an toàn, hoặc đủ điều kiện production. | Lập gói xác minh gồm data classification, luồng truy cập mô phỏng, expected security behavior và nguồn tham chiếu; chờ kết luận có ghi nhận. |
VR-TCM-002 |
Cần xác minh | Test case liên quan hóa đơn, thuế, hạch toán, truy xuất thực phẩm hoặc thu hồi hàng cần Accounting Owner, Legal Owner và Domain Owner xác minh. Bằng chứng: nguồn luật nêu phạm vi pháp lý, nhưng source seed yêu cầu xác minh văn bản hiện hành và vai trò được ủy quyền; suy ra template không được định nghĩa rule pháp lý. | TMPL-TCM-001, CANONICAL_BUSINESS_RULES, 00_SOURCE_MAP |
Accounting Owner; Legal Owner; Food-safety Domain Owner | Sai diễn giải có thể biến ví dụ học liệu thành hướng dẫn vận hành hoặc pháp lý sai. | Giữ test basis ở mức giả định mô phỏng; escalation khi cần ngưỡng, thời hạn, chứng từ hoặc quyết định nghiệp vụ cụ thể. |
VR-TCM-003 |
Cần xác minh | Mức coverage, điều kiện pass/fail và evidence retention chưa có quyết định QA. Bằng chứng: manifest và registry không tạo approval; ISTQB CTFL cung cấp thuật ngữ kiểm thử, không cấp tiêu chí release cho Nova Foods. | TMPL-TCM-001, CHAPTER_MANIFEST, TEMPLATE_MANIFEST |
QA Reviewer | Không được dùng verdict mẫu làm quyết định chất lượng hay release gate. | QA Reviewer xác định tiêu chí cho phạm vi học liệu; ghi riêng nguồn, version, ngày và thẩm quyền quyết định. |
Quy tắc xử lý: Owner của dòng phải cập nhật trạng thái, bằng chứng và quyết định trong artifact kiểm soát; Principal IT Business Analyst / Technical Curriculum Author chỉ bảo toàn ID, liên kết và lịch sử thay đổi. Không dòng nào trong bảng xác nhận approval, baseline, compliance, cấu hình ERP thực tế hoặc quyền dùng production.
6.3 Bàn giao cuối và quy tắc lan truyền thay đổi
Bàn giao có kiểm soát (controlled handoff) là chuyển gói tài liệu để vai trò nhận có thể rà soát liên kết mà không suy diễn quyết định mới. Gói bàn giao của TMPL-TCM-001 giữ Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND; Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Bàn giao không tạo baseline, approval, xác nhận requirement, xác nhận tuân thủ, hay quyền dùng production.
| Thành phần bàn giao | Định danh hoặc tệp canonical | Vai trò nhận | Mục đích nhận | Giới hạn thẩm quyền |
|---|---|---|---|---|
| Template mapping | /03-templates/TMPL-TCM-001_TEST_CASE_MAPPING.md |
QA Reviewer, Technical Curriculum Author | Rà soát liên kết test case với test basis và evidence | Không xác nhận chất lượng sản phẩm hay kết quả test thực tế |
| Danh mục template | /01-curriculum/TEMPLATE_MANIFEST.md |
Principal IT Business Analyst / Technical Curriculum Author | Xác nhận vị trí và phạm vi template trong corpus | Không baseline hoặc phê duyệt template |
| Registry định danh | /01-curriculum/TRACEABILITY_ID_REGISTRY.md |
Principal IT Business Analyst / Technical Curriculum Author | Bảo toàn chuỗi ID và quy tắc traceability | Không quyết định nghiệp vụ, pháp lý, kế toán, bảo mật |
| Quy tắc nghiệp vụ canonical | /01-curriculum/CANONICAL_BUSINESS_RULES.md |
Business Owner, Legal Owner, Accounting Owner khi cần | Đối chiếu test basis với quy tắc đã được ghi nhận | Không suy diễn quy tắc vận hành từ case mô phỏng |
| Từ điển dữ liệu canonical | /01-curriculum/CANONICAL_DATA_DICTIONARY.md |
Data Owner, Architect, QA Reviewer | Đối chiếu tên trường, kiểu dữ liệu và ý nghĩa logic | Không xác nhận schema triển khai hay dữ liệu production |
| Danh mục chapter | /01-curriculum/CHAPTER_MANIFEST.md |
Technical Curriculum Author | Bảo toàn dependency học liệu và consumer hạ nguồn | Không đổi cấu trúc curriculum ngoài quy trình thay đổi |
Quy tắc lan truyền thay đổi: nguồn canonical đổi trước, template nhận thay đổi sau. Nếu TRACEABILITY_ID_REGISTRY đổi ID, người duy trì phải cập nhật mọi liên kết ID trong TMPL-TCM-001 và ghi lịch sử thay đổi; không tái sử dụng ID cũ cho ý nghĩa mới. Nếu CANONICAL_BUSINESS_RULES đổi rule, mapping bị ảnh hưởng phải được rà soát lại test basis, điều kiện kiểm thử, expected result và evidence link. Nếu CANONICAL_DATA_DICTIONARY đổi tên, định nghĩa, miền giá trị hoặc phân loại dữ liệu, mapping liên quan phải rà soát data setup và kiểm tra bảo mật, riêng tư, accessibility khi phạm vi thay đổi kích hoạt các kiểm tra đó.
| Loại thay đổi | Người lập gói thay đổi | Vai trò phải quyết định | Hành động với TMPL-TCM-001 |
Trạng thái sau xử lý |
|---|---|---|---|---|
| Đổi ID, đường dẫn, version hoặc metadata | Principal IT Business Analyst / Technical Curriculum Author | Owner quản trị artifact | Cập nhật link, lịch sử thay đổi, consumer bị ảnh hưởng | Giữ IN_REVIEW |
| Đổi quy tắc nghiệp vụ Nova Foods mô phỏng | Principal IT Business Analyst / Technical Curriculum Author | Business Owner | Rà soát mapping test case với rule source | Giữ IN_REVIEW đến khi có tham chiếu quyết định được ghi nhận |
| Đổi nghĩa dữ liệu hoặc phân loại dữ liệu | Principal IT Business Analyst / Technical Curriculum Author | Data Owner; Security hoặc Legal Owner nếu có dữ liệu cá nhân | Rà soát data condition, evidence và giới hạn hiển thị | Giữ IN_REVIEW |
| Đổi kiến trúc, API, tích hợp hoặc hành vi hệ thống | Principal IT Business Analyst / Technical Curriculum Author | Architect; Security khi có rủi ro bảo mật | Rà soát test scope và traceability hạ nguồn | Giữ IN_REVIEW |
| Đổi diễn giải pháp lý, thuế, kế toán, hóa đơn hoặc an toàn thực phẩm | Principal IT Business Analyst / Technical Curriculum Author | Legal Owner, Accounting Owner hoặc Domain Owner | Gắn Verification required; không viết lại thành nghĩa vụ đã xác nhận |
Giữ IN_REVIEW |
Không sửa im lặng bản mapping đã được bàn giao. Mỗi thay đổi phải nêu nguồn thay đổi, ID hoặc tệp bị ảnh hưởng, lý do, vai trò quyết định, liên kết evidence và consumer cần nhận thông báo. Khi một thay đổi chạm nhiều thẩm quyền, Principal IT Business Analyst / Technical Curriculum Author chỉ điều phối gói escalation; Business Owner, Architect, QA Reviewer, Legal Owner, Accounting Owner, Security hoặc Domain Owner giữ quyền kết luận trong phạm vi chuyên môn của họ.