Tmpl Tst 001 Test Design

Trường kiểm soát	Giá trị
Artifact ID	TMPL-TST-001
Tên tệp được kiểm soát	/03-templates/TMPL-TST-001_TEST_DESIGN.md
Tiêu đề artifact	Tmpl Tst 001 Test Design
Status	IN_REVIEW
Version	v0.9.0
Owner	Principal IT Business Analyst / Technical Curriculum Author
Last updated date	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale	vi-VN; bối cảnh Việt Nam; tiền tệ mô phỏng VND
Phân loại artifact	Four-tier controlled template cho thiết kế kiểm thử ERP
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục
Trạng thái baseline	Chưa có baseline reference tại v0.9.0. IN_REVIEW không phải BASELINED.
Trạng thái phê duyệt	Chưa có approval reference. Metadata, trạng thái review, Owner hoặc nội dung ví dụ không tạo phê duyệt ngầm định.

Owner duy trì định danh, đường dẫn, phiên bản, trạng thái, lịch sử thay đổi và ranh giới sử dụng của template. Owner không có thẩm quyền tự xác nhận requirement Nova Foods, baseline, approval, tuân thủ pháp lý, diễn giải kế toán, quyết định bảo mật hoặc cho phép triển khai production.

Mọi tên tổ chức, người dùng, vai trò, đơn hàng, lô hàng, giá trị VND, dữ liệu kiểm thử, bằng chứng và kết quả trong TMPL-TST-001 là dữ liệu tổng hợp cho Nova Foods mô phỏng. Không dùng dữ liệu cá nhân, dữ liệu khách hàng thật, bí mật thương mại, cấu hình ERP thật, thông tin production hoặc bằng chứng tuân thủ thật. Ví dụ có kết quả “Pass” hoặc “Fail” chỉ minh họa cách ghi test; không chứng minh hệ thống thật đã được kiểm thử.

1. Tier 1 ? Metadata, Purpose, and Governance

Lịch sử thay đổi

Version	Ngày	Người ghi nhận	Thay đổi	Trạng thái
v0.9.0	2026-08-07	Principal IT Business Analyst / Technical Curriculum Author	Khởi tạo metadata quản trị cho TMPL-TST-001; thiết lập ranh giới dữ liệu mô phỏng và kiểm soát trạng thái review.	IN_REVIEW

Không sửa đè dòng lịch sử này khi thay đổi artifact. Thay đổi tiếp theo phải có version, ngày theo Asia/Ho_Chi_Minh, người ghi nhận và mô tả tác động. Khi chưa có tham chiếu baseline hoặc approval được ghi nhận rõ trong artifact kiểm soát, không gọi bất kỳ phiên bản, test design, test case hay kết quả Nova Foods nào là đã baseline, đã phê duyệt, production-ready hoặc compliant.

Mục đích, điều kiện sử dụng và thẩm quyền

Template này thiết kế Test Design (thiết kế kiểm thử): cấu trúc chuyển test basis, tức nguồn làm căn cứ kiểm thử như requirement, business rule, acceptance criteria và data definition, thành điều kiện kiểm thử, test case, dữ liệu kiểm thử, kết quả mong đợi và liên kết truy vết. Mục đích: giúp QA, BA và nhóm kỹ thuật kiểm tra cùng một hành vi Nova Foods ERP mô phỏng bằng bằng chứng nhất quán. Căn cứ: ISTQB_CTFL dùng thuật ngữ và kỹ thuật kiểm thử; TRACEABILITY_ID_REGISTRY giữ ID canonical; dữ liệu Nova Foods chỉ là dữ liệu tổng hợp giáo dục.

Nội dung	Quy định áp dụng
Dùng khi	Có test basis xác định được ID, phiên bản và nguồn; cần thiết kế kiểm thử chức năng, tích hợp, API, dữ liệu, phân quyền, khả dụng hoặc hồi quy cho Nova Foods ERP mô phỏng.
Không dùng khi	Chưa có requirement, rule, acceptance criteria hoặc quyết định nghiệp vụ làm căn cứ; cần phê duyệt release; cần ghi nhận kết quả chạy test; cần xác nhận tuân thủ pháp luật, kế toán, thuế, an toàn thực phẩm hoặc production. Test Design không thay Test Execution, defect log, approval record hay legal opinion.
Owner	Principal IT Business Analyst / Technical Curriculum Author duy trì cấu trúc template, metadata, version, liên kết artifact và ranh giới mô phỏng. Owner không xác nhận test passed, không phê duyệt baseline, không quyết định vận hành Nova Foods.
Consumers	Junior BA học chuyển yêu cầu thành kiểm thử; Senior BA kiểm tra truy vết; QA thiết kế và rà soát test; Developer hiểu hành vi cần xác minh; Product hoặc Business Owner rà soát ý nghĩa nghiệp vụ trong phạm vi thẩm quyền.
Điều kiện đầu vào	Requirement hoặc acceptance criteria có ID canonical; business rule cần kiểm thử có liên kết tới CANONICAL_BUSINESS_RULES; trường dữ liệu có liên kết tới CANONICAL_DATA_DICTIONARY; định danh dùng theo TRACEABILITY_ID_REGISTRY; phạm vi chức năng và ngoại lệ được mô tả đủ để nêu kết quả mong đợi.
Artifact đầu ra	Test case, test data, expected result, coverage view, traceability link, giả định, exception và điểm cần escalation. Các đầu ra là học liệu kiểm thử, không phải bằng chứng production.
Artifact hạ nguồn	Test execution record, defect record, test summary, release-readiness review hoặc change-impact analysis chỉ được tạo khi artifact riêng của chúng đã xác định phạm vi và thẩm quyền.

Không tạo test case từ suy đoán. Ví dụ, nếu yêu cầu chỉ nói “hệ thống kiểm tra hạn mức tín dụng”, người soạn chưa biết ngưỡng, nguồn số dư, trạng thái đơn hàng bị chặn và quyền override. Bằng chứng thiếu là acceptance criteria hoặc rule canonical; kết luận đúng là ghi dependency và escalation, không tự đặt ngưỡng VND hay trạng thái ERP.

Quyền hạn	Được làm	Không được làm	Escalation đến
BA/Template Owner	Chuẩn hóa cấu trúc test, liên kết ID, chỉ ra khoảng trống test basis	Tự xác nhận rule nghiệp vụ, phê duyệt test result, tạo baseline	Business Owner khi thiếu quyết định nghiệp vụ; QA Lead khi thiếu chiến lược hoặc mức coverage
QA Lead	Quyết định kỹ thuật kiểm thử, mức ưu tiên kiểm thử, tiêu chí bằng chứng kiểm thử trong phạm vi dự án mô phỏng	Diễn giải luật, quyết định kế toán hoặc cho phép production	Legal/Compliance Owner, Accounting Owner, Security Owner hoặc Release Authority theo loại vấn đề
Business Owner	Làm rõ kết quả nghiệp vụ mong đợi và ngoại lệ nghiệp vụ	Tự xác nhận bảo mật, pháp lý hoặc thiết kế kỹ thuật	Architect, Security Owner, Legal/Compliance Owner khi nội dung vượt nghiệp vụ
Architect/Security Owner	Làm rõ tích hợp, kiến trúc, quyền truy cập và rủi ro bảo mật	Xác nhận nghĩa vụ pháp lý hoặc quyết toán kế toán	Legal/Compliance Owner hoặc Accounting Owner

Escalation bắt buộc khi test basis mâu thuẫn nguồn canonical, ID chưa đăng ký, dữ liệu có thể là dữ liệu cá nhân thật, hoặc expected result ngụ ý nghĩa vụ pháp lý, thuế, kế toán, an toàn thực phẩm hay bảo mật. Gói escalation phải nêu ID liên quan, nguồn đang dùng, mâu thuẫn, tác động đến test và câu hỏi cần vai trò có thẩm quyền quyết định. IN_REVIEW tại v0.9.0 không phải approval, baseline, xác nhận tuân thủ hay quyền dùng production.

Liên kết Manifest, Định danh Canonical, Chương, Nguồn và Kiểm soát Thay đổi

Template này có danh tính manifest là TMPL-TST-001, tệp kiểm soát là /03-templates/TMPL-TST-001_TEST_DESIGN.md, và phải được đối chiếu với /01-curriculum/TEMPLATE_MANIFEST.md trước khi tạo, sửa hoặc dùng nội dung Tier 2 đến Tier 4. Manifest là danh mục nguồn chân lý về template dự kiến; vì vậy tên tệp, ID, trạng thái và phạm vi trong template không được tự đổi theo cách viết cục bộ. Bằng chứng: TEMPLATE_MANIFEST là controlled planning artifact quản lý metadata, version và liên kết corpus. Suy luận: thay đổi ID hoặc đường dẫn chỉ trong template sẽ làm đứt liên kết từ manifest đến bằng chứng kiểm tra.

Hạng mục liên kết	Giá trị bắt buộc	Cách dùng và ranh giới
Manifest nguồn	/01-curriculum/TEMPLATE_MANIFEST.md	Xác minh TMPL-TST-001, tên tệp, dependency và phạm vi template. Không dùng bản sao hoặc tên rút gọn thay manifest.
ID template	TMPL-TST-001	Giữ nguyên trong metadata, traceability link, change record và tham chiếu liên artifact.
Tệp template	/03-templates/TMPL-TST-001_TEST_DESIGN.md	Đường dẫn canonical của Test Design, tức thiết kế kiểm thử: cấu trúc chuyển test basis thành điều kiện, dữ liệu, bước và kết quả mong đợi có thể kiểm tra.
Manifest chương	/01-curriculum/CHAPTER_MANIFEST.md	Kiểm tra chapter nào cung cấp kiến thức và đầu vào cho thiết kế kiểm thử; không tự gán chapter ngoài manifest.
Registry ID	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra cú pháp, loại và quan hệ của ID traceability. Không tự tạo ID canonical nếu registry chưa đăng ký.
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Chỉ liên kết business rule đã có trong catalog; không biến ví dụ kiểm thử thành quy tắc Nova Foods có thẩm quyền.
Dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Dùng để đối chiếu tên dữ liệu, ý nghĩa và ràng buộc logic khi test case kiểm tra trường dữ liệu.

Liên kết chương phải phản ánh chuỗi học, không phản ánh giả định của người viết. Test Design cần test basis, tức tập đầu vào làm căn cứ thiết kế kiểm thử, như requirement, acceptance criterion, business rule, process flow, API contract hoặc data definition. CHAPTER_MANIFEST là bằng chứng về vị trí và dependency của các chapter. Khi một test case không truy được về test basis có ID canonical, test case đó chỉ là ý tưởng kiểm thử; không được ghi là bằng chứng xác nhận yêu cầu Nova Foods.

Loại liên kết trong Test Design	ID/nguồn phải giữ	Tiêu chí hợp lệ
Requirement hoặc acceptance criterion	ID đã đăng ký trong TRACEABILITY_ID_REGISTRY	ID tồn tại, nội dung nguồn truy cập được, test case nêu rõ điều kiện cần kiểm tra.
Business rule	ID từ CANONICAL_BUSINESS_RULES	Rule có phạm vi rõ; nếu liên quan pháp lý, kế toán, thuế, riêng tư hoặc an toàn thực phẩm thì giữ nhãn Verification required hoặc project assumption khi nguồn chưa xác minh đầy đủ.
Logical data field	ID hoặc tên canonical từ CANONICAL_DATA_DICTIONARY	Không đổi tên trường để tiện viết test; khác biệt tên phải được nêu là mapping cần xác minh.
API behavior	OpenAPI Specification OAS 3.1.1 hoặc API artifact đã đăng ký	Chỉ dùng OAS cho mô tả HTTP API; không suy diễn endpoint, payload hay status code chưa có artifact nguồn.
Accessibility behavior	WCAG 2.2	Chỉ nêu tiêu chí thành công khi đối chiếu được nguồn; không tự tuyên bố Nova Foods tuân thủ WCAG.
Security behavior	OWASP ASVS 5.0.0 hoặc OWASP API Security Top 10 2023	Dùng làm nguồn thực hành ngành; không diễn đạt như luật Việt Nam hoặc kết luận compliance.
Testing terminology và kỹ thuật hộp đen	ISTQB CTFL Syllabus v4.0.1	Dùng thuật ngữ và kỹ thuật như phân vùng tương đương, phân tích giá trị biên khi phù hợp với test basis.

Nguồn ngoài corpus phải được phân loại đúng. ISTQB CTFL Syllabus v4.0.1 là nguồn chính cho thuật ngữ kiểm thử và kỹ thuật black-box, tức kiểm thử theo đầu vào, đầu ra và hành vi quan sát được mà không dựa vào mã nguồn. ISO/IEC/IEEE 29148:2018 và BABOK Guide Version 3 hỗ trợ thuật ngữ requirements và business analysis; chỉ dùng thông tin công khai đã xác minh, không bịa số trang hoặc điều khoản. BPMN 2.0.2 chỉ là nguồn chuẩn cho ký pháp BPMN; sơ đồ PlantUML activity không được gọi là BPMN. Mọi URL nguồn dùng trong template phải ghi ngày truy cập 2026-08-07.

Thay đổi ảnh hưởng TMPL-TST-001 phải bắt đầu bằng kiểm tra manifest, registry và artifact nguồn bị ảnh hưởng. Ví dụ, đổi BR-... đang được test case tham chiếu cần kiểm tra CANONICAL_BUSINESS_RULES, các test case Tier 3, traceability link và bằng chứng kết quả; lý do là một rule đổi nghĩa có thể làm expected result, test data và quyết định pass/fail mất hiệu lực đồng thời. Không sửa im lặng ID, filename, source classification, trạng thái IN_REVIEW, version v0.9.0, hay liên kết traceability.

Tình huống thay đổi	Nghĩa vụ kiểm soát
ID chưa có trong registry	Dừng liên kết canonical; ghi vấn đề để Owner đối chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Nguồn pháp lý bị dùng để tạo expected result	Gắn Verification required; chuyển Legal Owner, Accounting Owner hoặc domain owner tùy lĩnh vực. Template không tự diễn giải luật.
Test basis mâu thuẫn business rule hoặc data dictionary	Không chọn một bên bằng suy đoán; giữ cả ID nguồn, mô tả mâu thuẫn và escalation theo thẩm quyền.
Đổi tên tệp hoặc ID template	Chỉ thực hiện khi TEMPLATE_MANIFEST và các artifact tham chiếu được cập nhật theo kiểm soát thay đổi; không tạo alias cục bộ.
Nội dung Nova Foods có vẻ là dữ liệu vận hành thật	Loại khỏi template hoặc thay bằng dữ liệu tổng hợp; Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục.

IN_REVIEW xác nhận nội dung đang được xem xét có kiểm soát, không xác nhận baseline, approval, production readiness hay compliance. Vì vậy, traceability trong template chứng minh đường liên kết học liệu và căn cứ kiểm tra mô phỏng; nó không chứng minh Nova Foods đã chấp thuận rule, đã chạy test, đã đạt tuân thủ, hoặc được phép triển khai ERP.

2. Tier 2 ? Blank Copy-Paste-Ready Template

Sao chép toàn bộ cấu trúc này cho mỗi thiết kế kiểm thử. Thay mọi giá trị trong dấu ngoặc nhọn bằng dữ liệu của phạm vi đang xét. Không dùng template này để suy diễn rule, nghĩa vụ pháp lý, cấu hình ERP, approval hay kết quả test chưa có căn cứ.

2.1 Kiểm soát tài liệu

Trường	Giá trị cần điền
Template ID	TMPL-TST-001
Tên tài liệu	<Tên thiết kế kiểm thử, nêu đối tượng và phạm vi>
Artifact ID	<ID artifact đã đăng ký trong TRACEABILITY_ID_REGISTRY>
Tên tệp kiểm soát	<Đường dẫn và filename canonical>
Status	<DRAFT hoặc IN_REVIEW hoặc APPROVED hoặc BASELINED; chỉ chọn trạng thái được kiểm soát>
Version	<Phiên bản theo quy ước, ví dụ v0.9.0>
Ngày cập nhật	<YYYY-MM-DD theo Asia/Ho_Chi_Minh>
Owner	<Vai trò chịu trách nhiệm duy trì tài liệu; không ghi người không có thẩm quyền>
Case study	<Tên case study; nêu mô phỏng giáo dục và dữ liệu tổng hợp nếu áp dụng>
Locale và tiền tệ	<Locale, quốc gia, múi giờ, tiền tệ áp dụng>
Baseline reference	<ID baseline đã ghi nhận hoặc Chưa có baseline reference>
Approval reference	<ID phê duyệt đã ghi nhận hoặc Chưa có approval reference>

2.2 Mục tiêu, phạm vi và căn cứ kiểm thử

Trường	Giá trị cần điền
Mục tiêu kiểm thử	<Hành vi cần xác minh và giá trị nghiệp vụ được bảo vệ>
Đối tượng kiểm thử	<Chức năng, màn hình, API, batch, báo cáo hoặc integration>
Trong phạm vi	<Liệt kê ranh giới chức năng được test>
Ngoài phạm vi	<Liệt kê rõ chức năng không được test>
Test basis	<ID và tên requirement, acceptance criterion, business rule, wireframe, API contract hoặc data dictionary>
Lý do đủ test basis	<Nêu liên kết: nguồn nào xác định hành vi nào; ghi Verification required nếu nguồn chưa xác minh>
Loại kiểm thử	<Functional, integration, regression, negative, accessibility, security hoặc loại khác>
Kỹ thuật thiết kế	<Equivalence Partitioning, Boundary Value Analysis, Decision Table, State Transition hoặc Exploratory Testing; giải thích tiếng Việt nếu dùng lần đầu>
Môi trường	<Tên môi trường mô phỏng, phiên bản build, URL không chứa secret>
Điều kiện vào	<Điều kiện phải đúng trước khi chạy test>
Điều kiện thoát	<Tiêu chí hoàn tất hoặc tiêu chí dừng test>

2.3 Dữ liệu kiểm thử và tiền điều kiện

Trường	Giá trị cần điền
Bộ dữ liệu	<ID bộ dữ liệu tổng hợp và mô tả mục đích>
Phân loại dữ liệu	<Synthetic hoặc Masked hoặc Production-like prohibited>
Tiền điều kiện nghiệp vụ	<Trạng thái dữ liệu, quyền, cấu hình hoặc giao dịch phải tồn tại>
Tài khoản kiểm thử	<Tên tham chiếu tài khoản giả lập; không ghi mật khẩu, token, API key hoặc cookie>
Tham chiếu secret an toàn	<Ví dụ: vault://<tên-kho-bí-mật>/<tên-secret>; không chép giá trị secret vào tài liệu>
Dữ liệu đầu vào hợp lệ	<Giá trị tổng hợp đại diện trường hợp hợp lệ>
Dữ liệu đầu vào không hợp lệ	<Giá trị tổng hợp đại diện lỗi, biên hoặc quyền bị từ chối>
Ràng buộc dữ liệu	<Format, độ dài, miền giá trị, uniqueness, trạng thái hoặc quan hệ dữ liệu>

2.4 Bản ghi test case lặp lại

<Test Case ID đã đăng ký> — <Tên test case mô tả kết quả cần xác minh>

Trường	Giá trị cần điền
Mục tiêu test case	<Một hành vi có thể kiểm chứng>
Ưu tiên	<Critical hoặc High hoặc Medium hoặc Low>
Mức rủi ro	<High hoặc Medium hoặc Low; nêu lý do>
Requirement link	<ID requirement hoặc acceptance criterion>
Business rule link	<ID rule hoặc Không áp dụng; không tự tạo rule>
Data dictionary link	<ID thực thể/trường dữ liệu hoặc Không áp dụng>
Precondition	<Điều kiện trước khi thực hiện bước 1>
Test data	<ID dữ liệu tổng hợp và giá trị cần dùng>
Bước thực hiện	<Bước số 1: hành động người dùng hoặc hệ thống>
Kết quả mong đợi	<Kết quả quan sát được, đo được, không mơ hồ>
Quy tắc pass/fail	<Pass khi kết quả thực tế khớp toàn bộ kết quả mong đợi; Fail khi có một sai lệch>
Actual result	<Chỉ điền sau khi chạy; ghi Chưa thực thi nếu chưa chạy>
Execution status	<NOT_RUN hoặc PASS hoặc FAIL hoặc BLOCKED hoặc NOT_APPLICABLE>
Defect reference	<ID defect đã đăng ký hoặc Không có hoặc Chưa xác định>
Người thực thi	<Vai trò hoặc định danh người thực thi>
Thời điểm thực thi	<YYYY-MM-DD HH:MM Asia/Ho_Chi_Minh hoặc Chưa thực thi>

2.5 Quyết định, ngoại lệ và bằng chứng

Trường	Giá trị cần điền
Quyết định test	<PASS hoặc FAIL hoặc BLOCKED hoặc NOT_APPLICABLE>
Căn cứ quyết định	<So sánh actual result với expected result và test basis>
Ngoại lệ	<Không có hoặc mô tả ngoại lệ, tác động, owner xử lý và điều kiện đóng>
Bằng chứng	<URL, đường dẫn tệp, ảnh chụp, log hoặc báo cáo; không chứa secret hay dữ liệu cá nhân thật>
Hash bằng chứng	<SHA-256 nếu dự án yêu cầu kiểm tra toàn vẹn; nếu không áp dụng ghi Không áp dụng>
Giới hạn bằng chứng	<Điều bằng chứng chứng minh và điều bằng chứng không chứng minh>

2.6 Traceability, thay đổi, review và sign-off

Trường	Giá trị cần điền
Upstream traceability	<ID nguồn đầu vào canonical>
Downstream traceability	<ID test execution, defect, release decision hoặc artifact nhận đầu ra>
Tác động thay đổi	<Requirement, rule, data, API, UI hoặc môi trường bị ảnh hưởng>
Change reference	<ID change request hoặc Không có>
Reviewer	<Vai trò reviewer có thẩm quyền>
Review result	<ACCEPT hoặc REWORK_REQUIRED hoặc ESCALATED>
Review date	<YYYY-MM-DD theo Asia/Ho_Chi_Minh hoặc Chưa review>
Sign-off role	<Vai trò có thẩm quyền hoặc Không áp dụng>
Sign-off reference	<ID sign-off đã ghi nhận hoặc Chưa có sign-off reference>
Ghi chú thẩm quyền	<Nêu rõ review hoặc sign-off không thay thế legal, accounting, security hay production approval khi các thẩm quyền này chưa được ghi nhận>

Sổ bảng kiểm soát, quyết định, ngoại lệ, bằng chứng và truy vết

Dùng các bảng dưới đây cho từng thiết kế kiểm thử. “Traceability” là truy vết hai chiều giữa yêu cầu, quy tắc, dữ liệu, kiểm thử và bằng chứng; mục tiêu là chứng minh phạm vi đã kiểm tra, không suy diễn yêu cầu mới. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; chỉ ghi dữ liệu tổng hợp.

Trường kiểm soát	Giá trị điền
Test Design ID	<mã thiết kế kiểm thử duy nhất theo TRACEABILITY_ID_REGISTRY>
Tên thiết kế	<tên ngắn, nêu rõ chức năng hoặc luồng cần kiểm thử>
Artifact ID	TMPL-TST-001
Tệp kiểm soát	/03-templates/TMPL-TST-001_TEST_DESIGN.md
Status	DRAFT / IN_REVIEW / APPROVED / REJECTED / SUPERSEDED; không tự ghi APPROVED khi chưa có bản ghi phê duyệt
Version	<phiên bản theo quy tắc versioning, ví dụ v0.9.0>
Ngày cập nhật	<YYYY-MM-DD>
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN / VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp
Người soạn	<họ tên hoặc vai trò người soạn>
Owner	<vai trò chịu trách nhiệm duy trì artifact>
Phạm vi kiểm thử	<chức năng, quy trình, API, báo cáo hoặc tích hợp nằm trong phạm vi>
Ngoài phạm vi	<nội dung không kiểm thử và lý do>
Test basis	<ID và tên yêu cầu, user story, business rule, acceptance criteria, data dictionary hoặc đặc tả được dùng làm căn cứ>
Phân loại nguồn	Primary source / Secondary source / Project assumption / Verification required
Giới hạn nguồn	<nêu rõ nguồn chỉ cung cấp thuật ngữ, bối cảnh, yêu cầu dự án, hoặc cần xác minh thẩm quyền>

Decision ID	Câu hỏi quyết định	Phương án được xét	Quyết định hiện tại	Bằng chứng và lập luận	Owner quyết định	Trạng thái
<mã quyết định duy nhất>	<câu hỏi có thể trả lời rõ>	<phương án A; phương án B; phương án C nếu có>	<phương án được chọn hoặc CHỜ QUYẾT ĐỊNH>	<tham chiếu Test basis ID; giải thích vì sao bằng chứng hỗ trợ quyết định>	<Business Owner / QA Owner / Architect / Security Owner / Legal Owner / Accounting Owner>	OPEN / DECIDED / ESCALATED / REJECTED

Không biến giả định dự án thành quyết định đã xác nhận. Nếu quyết định ảnh hưởng pháp lý, kế toán, bảo mật, kiến trúc hoặc vận hành thực, ghi ESCALATED và chỉ rõ owner có thẩm quyền.

Exception ID	Điều kiện ngoại lệ	Hành vi mong đợi	Cách phát hiện	Xử lý hoặc escalation	Nguồn căn cứ	Trạng thái
<mã ngoại lệ duy nhất>	<đầu vào, trạng thái, lỗi tích hợp hoặc tình huống biên>	<thông báo, chặn, ghi log, hoàn tác hoặc luồng thay thế>	<assertion UI, HTTP status, DB query chỉ đọc, log reference hoặc báo cáo>	<vai trò nhận xử lý; điều kiện escalation>	<Test basis ID hoặc Project assumption/Verification required>	OPEN / COVERED / BLOCKED / ESCALATED

Evidence ID	Test Case ID	Loại bằng chứng	Vị trí lưu hoặc tham chiếu	Dữ liệu tổng hợp dùng	Kết quả quan sát	Người ghi nhận	Thời điểm
<mã bằng chứng duy nhất>	<mã test case>	Screenshot / API response / Query result / System log / Export file / Recording / Manual observation	<URL nội bộ giả lập, đường dẫn repository, tên tệp hoặc mã attachment; không chứa secret>	<ID dữ liệu tổng hợp; không ghi dữ liệu cá nhân thật>	PASS / FAIL / BLOCKED / NOT_RUN	<họ tên hoặc vai trò>	<YYYY-MM-DDTHH:MM:SS+07:00>

Không ghi mật khẩu, API key, access token, cookie, chuỗi kết nối DB, số định danh cá nhân hoặc dữ liệu khách hàng thật vào bằng chứng. Khi cần chứng minh quyền truy cập, dùng <secret-reference: vault-path-or-secret-id>; chỉ tham chiếu, không sao chép bí mật.

Trace ID	Upstream artifact hoặc nguồn	Upstream ID	Thành phần kiểm thử	Downstream Test Case ID	Evidence ID	Trạng thái liên kết
<mã truy vết duy nhất>	<đường dẫn artifact canonical hoặc URL nguồn>	<Requirement ID / Rule ID / Data field ID / AC ID>	<điều kiện, dữ liệu, bước, expected result hoặc ngoại lệ được kiểm tra>	<mã test case>	<mã bằng chứng>	PLANNED / EXECUTED / PASS / FAIL / BLOCKED / NOT_APPLICABLE

Mỗi liên kết phải có upstream ID và downstream Test Case ID. NOT_APPLICABLE chỉ hợp lệ khi ghi lý do kiểm chứng; không dùng để che khoảng trống test basis.

Version	Ngày	Loại thay đổi	Mô tả thay đổi	Lý do và bằng chứng	Người thay đổi	Review impact
<vX.Y.Z>	<YYYY-MM-DD>	CREATE / UPDATE / CORRECTION / SUPERSEDE	<thay đổi cụ thể theo trường, test case, dữ liệu hoặc truy vết>	<Decision ID, Trace ID, defect ID hoặc nguồn thay đổi>	<họ tên hoặc vai trò>	NONE / QA_REVIEW_REQUIRED / BUSINESS_REVIEW_REQUIRED / SECURITY_REVIEW_REQUIRED / LEGAL_REVIEW_REQUIRED

Review hoặc sign-off ID	Loại kiểm soát	Vai trò bắt buộc	Người thực hiện	Kết quả	Phạm vi đã xem xét	Bằng chứng	Ngày
<mã review duy nhất>	AUTHOR_CHECK / PEER_REVIEW / QA_REVIEW / BUSINESS_REVIEW / SECURITY_REVIEW / LEGAL_REVIEW / SIGN_OFF	<vai trò có thẩm quyền>	<họ tên hoặc để trống nếu chưa phân công>	PENDING / APPROVED / REJECTED / CHANGES_REQUESTED / NOT_REQUIRED	<ID test case, decision, exception, trace hoặc version được xem xét>	<Evidence ID hoặc tham chiếu biên bản>	<YYYY-MM-DD hoặc để trống nếu PENDING>

SIGN_OFF chỉ ghi APPROVED khi có bằng chứng và người có thẩm quyền. IN_REVIEW tại v0.9.0, ngày 2026-08-07, không chứng minh baseline, phê duyệt người dùng, tuân thủ pháp lý hay sẵn sàng production.

Hướng dẫn điền trường, giá trị cho phép, kiểm tra hợp lệ và điều kiện áp dụng

Tier 2 là mẫu trống tái sử dụng. Người lập thay mọi chuỗi <...> bằng dữ liệu kiểm chứng của test design; không suy đoán quy tắc, kết quả, phê duyệt hoặc bằng chứng. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp.

Trường mẫu	Cách điền	Giá trị cho phép hoặc mẫu	Quy tắc kiểm tra
<test-design-id>	Điền ID đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md.	<canonical-test-design-id>	Không tự tạo biến thể ID, không đổi tiền tố, không tái dùng ID cho test design khác.
<document-status>	Ghi trạng thái quản trị hiện tại.	DRAFT, IN_REVIEW, BASELINED, RETIRED	Chỉ ghi BASELINED khi có baseline reference được ghi nhận. Bản corpus hiện hành dùng IN_REVIEW.
<document-version>	Ghi version kiểm soát.	<major.minor.patch>, ví dụ v0.9.0	Version phải khớp lịch sử thay đổi. Không sửa nội dung mà giữ nguyên version.
<test-level>	Xác định cấp kiểm thử, tức phạm vi kỹ thuật hoặc nghiệp vụ được kiểm tra.	UNIT, INTEGRATION, SYSTEM, UAT, REGRESSION	Chọn ít nhất một. UAT không đồng nghĩa người dùng đã phê duyệt.
<test-type>	Xác định loại kiểm thử.	FUNCTIONAL, NEGATIVE, BOUNDARY, SECURITY, ACCESSIBILITY, PERFORMANCE, DATA-MIGRATION	Mỗi loại phải có mục tiêu, điều kiện pass/fail và bằng chứng tương ứng.
<priority>	Phản ánh mức ưu tiên thực thi.	P1, P2, P3, P4	Phải có tiêu chí ưu tiên hoặc liên kết rủi ro; không dùng nhãn cảm tính như “gấp”.
<severity-if-failed>	Phản ánh tác động khi test fail.	CRITICAL, HIGH, MEDIUM, LOW	Không suy ra severity từ priority. Hai trường có chức năng khác nhau.
<source-classification>	Ghi loại nguồn của test basis, tức đầu vào làm căn cứ thiết kế test.	CANONICAL, PROJECT_ASSUMPTION, VERIFICATION_REQUIRED, EXTERNAL_STANDARD	PROJECT_ASSUMPTION và VERIFICATION_REQUIRED không được viết thành quy tắc bắt buộc.
<requirement-id>	Liên kết requirement hoặc rule canonical.	<canonical-requirement-id> hoặc <canonical-business-rule-id>	ID phải tồn tại tại nguồn canonical; mô tả test không thay thế requirement.
<test-data-classification>	Phân loại dữ liệu test.	SYNTHETIC, MASKED, PROHIBITED	Case Nova Foods dùng SYNTHETIC. PROHIBITED chặn thực thi đến khi dữ liệu được thay bằng dữ liệu hợp lệ.
<currency>	Ghi đơn vị tiền tệ của payload hoặc expected result.	VND	Giá trị tiền phải có số, đơn vị và quy tắc làm tròn từ test basis.
<locale> / <timezone>	Ghi ngữ cảnh hiển thị và thời gian.	vi-VN / Asia/Ho_Chi_Minh	Ngày giờ phải có múi giờ; không dùng ngày mơ hồ dạng 07/08/2026 nếu không nêu quy ước.
<expected-result>	Ghi kết quả quan sát được khi pass.	<observable-system-response>	Phải kiểm chứng được qua UI, API, DB được phép xem, log hoặc evidence reference; không ghi “hệ thống hoạt động đúng”.
<actual-result>	Ghi kết quả thực tế sau chạy test.	<observed-result> hoặc NOT_EXECUTED	Không điền trước khi thực thi. Nếu NOT_EXECUTED, trạng thái thực thi không được là PASS.
<execution-status>	Ghi trạng thái lần chạy.	NOT_EXECUTED, PASS, FAIL, BLOCKED, NOT_APPLICABLE	PASS cần evidence; FAIL cần defect ID hoặc lý do không tạo defect; BLOCKED cần blocker và owner xử lý.
<evidence-reference>	Tham chiếu bằng chứng, không nhúng bí mật.	<controlled-path-or-evidence-id>	Phải trỏ tới ảnh, log, response đã che dữ liệu nhạy cảm, hoặc báo cáo chạy test. Không dùng đường dẫn máy cá nhân.

Điều kiện	Phần mẫu bắt buộc điền	Quy tắc quyết định
<test-type> chứa NEGATIVE hoặc BOUNDARY	<invalid-input>, <boundary-value>, <validation-message>, <data-integrity-check>	Nêu giá trị không hợp lệ hoặc biên, phản hồi mong đợi, và xác nhận không tạo hay sửa dữ liệu ngoài ý muốn.
<test-type> chứa SECURITY	<security-risk>, <authorized-role>, <unauthorized-role>, <safe-secret-reference>, <security-evidence-reference>	Không ghi mật khẩu, token, API key, cookie, mã OTP, private key hoặc dữ liệu cá nhân thật. Áp dụng OWASP ASVS hoặc OWASP API Security Top 10 chỉ như nguồn good practice khi có liên kết cụ thể.
<test-type> chứa ACCESSIBILITY	<wcag-reference>, <assistive-technology-or-keyboard-method>, <observable-criterion>	Chỉ nêu WCAG 2.2 khi tiêu chí và bằng chứng khớp nguồn W3C. Không tuyên bố tuân thủ tổng thể từ một test.
<test-level> chứa INTEGRATION	<source-system>, <target-system>, <interface-id>, <request-payload-reference>, <response-payload-reference>, <failure-handling>	Payload chỉ chứa dữ liệu tổng hợp. HTTP method, status code và schema phải khớp test basis được kiểm soát.
<test-level> chứa UAT	<business-scenario>, <business-role>, <acceptance-criterion-id>, <execution-witness>	Người thực hiện hoặc witness chỉ xác nhận quan sát chạy test; không ghi là approval nếu chưa có approval reference.
Có dữ liệu pháp lý, kế toán, thuế, thực phẩm hoặc dữ liệu cá nhân	<applicable-source>, <source-classification>, <verification-owner>, <verification-status>	Ghi VERIFICATION_REQUIRED khi chưa có xác minh từ Legal Owner, Accounting Owner, Compliance Owner hoặc domain owner có thẩm quyền.

Loại bí mật	Mẫu tham chiếu an toàn	Không được điền	Kiểm tra trước lưu
API credential	<secret-ref: vault://<approved-vault>/<synthetic-test-secret-name>>	Giá trị token, API key, client secret	Tham chiếu không tiết lộ giá trị; quyền đọc tách khỏi tài liệu.
Mật khẩu tài khoản test	<secret-ref: <approved-secret-store>/<synthetic-test-account-id>>	Mật khẩu, câu trả lời bảo mật, mã OTP	Tài khoản phải là synthetic test account; không dùng tài khoản nhân sự thật.
Chuỗi kết nối DB	<secret-ref: <approved-secret-store>/<non-production-connection-name>>	Host nội bộ, username, password, certificate private key	Chỉ tham chiếu môi trường non-production được phép; evidence phải che thông tin kết nối.
Dữ liệu cá nhân hoặc tài chính	<synthetic-data-set-id>	CCCD, số điện thoại, địa chỉ, số tài khoản thật	Dùng dữ liệu tổng hợp; nếu cần dữ liệu thật, dừng và chuyển owner có thẩm quyền xác minh.

Cầu nối suy luận: test design chỉ đáng tin khi người khác tái tạo được điều kiện, dữ liệu, thao tác, kết quả và bằng chứng. Vì vậy trường có giá trị tự do phải kèm mẫu điền; trường quyết định phải có tập giá trị; trường nhạy cảm phải dùng tham chiếu an toàn; trường chưa được xác minh phải giữ nhãn VERIFICATION_REQUIRED, không biến thành kết luận Nova Foods.

3. Tier 3 ? Fully Completed Nova Foods Case: Core Record

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục. Toàn bộ người dùng, giao dịch, số tiền, mã định danh và dữ liệu dưới đây là dữ liệu tổng hợp.

Trường	Giá trị đã điền
Artifact ID	TMPL-TST-001
Tên artifact	Tmpl Tst 001 Test Design
Tệp kiểm soát	/03-templates/TMPL-TST-001_TEST_DESIGN.md
Status	IN_REVIEW
Version	v0.9.0
Ngày lập	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale và tiền tệ	vi-VN, VND
Phạm vi kiểm thử	Quy tắc chặn xác nhận đơn bán hàng khi vượt hạn mức công nợ mô phỏng
Hệ thống mô phỏng	Nova Foods ERP, phân hệ Sales Order và Accounts Receivable
Người lập test design	ACT-BA-001 — Lê Minh An, IT Business Analyst mô phỏng
Người thực thi dự kiến	ACT-QA-001 — Trần Gia Hân, QA Analyst mô phỏng
Môi trường	ENV-UAT-NF-01 — UAT mô phỏng, không kết nối production
Kỹ thuật kiểm thử	Kiểm thử hộp đen (black-box testing): kiểm tra đầu vào và kết quả quan sát được, không dựa vào mã nguồn; dùng phân vùng tương đương và giá trị biên theo thuật ngữ ISTQB CTFL.
Phân loại nguồn nghiệp vụ	PROJECT_ASSUMPTION
Nguồn phương pháp kiểm thử	PRIMARY_STANDARD — ISTQB CTFL Syllabus v4.0.1
Nguồn quản trị artifact	CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY — IN_REVIEW
Điều kiện sử dụng	Chỉ dùng để học và review. Không xác nhận cấu hình ERP thực, chính sách tín dụng, quyết định kế toán hoặc phê duyệt vận hành.

3.1 Bối cảnh, sự kiện và nhu cầu nền

Nhân viên bán hàng mô phỏng tạo đơn SO-NF-260807-001 cho khách hàng CUS-NF-000184 — Công ty TNHH Phân phối Hương Việt. Khách mua 600 thùng SKU-NF-DRK-330-CTN — Nước yến Nova 330 ml, đơn giá chưa thuế 185.000 VND/thùng. Tổng tiền hàng là 111.000.000 VND; VAT mô phỏng 8% là 8.880.000 VND; tổng thanh toán là 119.880.000 VND.

Số dư công nợ mở mô phỏng của khách tại thời điểm tạo đơn là 395.000.000 VND. Hạn mức công nợ mô phỏng là 500.000.000 VND. Giá trị kiểm tra hạn mức dùng tiền hàng chưa thuế, nên tổng phơi nhiễm công nợ sau đơn là 506.000.000 VND. Số này vượt hạn mức 6.000.000 VND.

Hiện trạng mô phỏng: hệ thống cho phép nhân viên bán hàng chuyển đơn sang CONFIRMED mà không tính số dư công nợ mở cộng tiền hàng chưa thuế của đơn mới. Hệ quả có thể sai: kho nhận lệnh xuất cho khách vượt hạn mức nội bộ mô phỏng; bộ phận công nợ mất điểm kiểm soát trước khi giao hàng.

Nhu cầu nền: hệ thống phải tính tổng phơi nhiễm trước thao tác xác nhận đơn. Nếu tổng này vượt hạn mức, hệ thống phải chặn xác nhận, giữ đơn ở trạng thái CREDIT_HOLD, và hiển thị lý do để người dùng xử lý đúng tuyến.

3.2 Dữ liệu chủ mô phỏng

Loại dữ liệu	ID	Giá trị	Phân loại nguồn
Khách hàng	CUS-NF-000184	Công ty TNHH Phân phối Hương Việt	SYNTHETIC_TEST_DATA
Hạn mức công nợ	CRL-NF-000184	500.000.000 VND	PROJECT_ASSUMPTION
Công nợ mở	AR-NF-260807-0184	395.000.000 VND	SYNTHETIC_TEST_DATA
Sản phẩm	SKU-NF-DRK-330-CTN	Nước yến Nova 330 ml, 24 chai/thùng	SYNTHETIC_TEST_DATA
Giá bán chưa thuế	PRC-NF-2608-0330	185.000 VND/thùng	SYNTHETIC_TEST_DATA
Thuế suất hiển thị	TAX-NF-SIM-08	8%	PROJECT_ASSUMPTION; không là kết luận thuế
Kho xuất mô phỏng	WH-NF-HCM-01	Kho thành phẩm Hồ Chí Minh	SYNTHETIC_TEST_DATA
Nhân viên bán hàng	ACT-SALES-014	Nguyễn Khánh Vy	SYNTHETIC_TEST_DATA
Quản lý tín dụng	ACT-CREDIT-003	Phạm Quốc Bảo	SYNTHETIC_TEST_DATA

3.3 Quy tắc và trạng thái cần kiểm thử

ID quy tắc	Quy tắc đã điền	Cầu nối suy luận
BR-NF-CR-001	Khi người dùng chọn Confirm Order, ERP tính openAR + orderNetAmount.	Công nợ mở và đơn mới cùng làm tăng rủi ro chưa thu tiền; kiểm tra từng giá trị riêng lẻ không phản ánh tổng phơi nhiễm.
BR-NF-CR-002	Nếu openAR + orderNetAmount <= creditLimit, đơn chuyển từ DRAFT sang CONFIRMED.	Giá trị bằng hạn mức vẫn không vượt hạn mức, nên thuộc nhánh cho phép.
BR-NF-CR-003	Nếu openAR + orderNetAmount > creditLimit, đơn chuyển từ DRAFT sang CREDIT_HOLD; không tạo yêu cầu xuất kho.	Đơn vượt hạn mức cần bị chặn trước bước kho để tránh giao hàng ngoài chính sách mô phỏng.
BR-NF-CR-004	Thông báo chặn phải nêu công nợ mở, tiền hàng chưa thuế, hạn mức và số tiền vượt.	Người dùng cần dữ kiện đủ để đối chiếu; thông báo chỉ nói “lỗi hạn mức” không hỗ trợ xử lý.
BR-NF-CR-005	Chỉ ACT-CREDIT-003 có quyền chuyển đơn CREDIT_HOLD sang CONFIRMED sau khi ghi lý do mô phỏng.	Quyền xác nhận ngoại lệ tách khỏi người tạo đơn để giảm tự phê duyệt trong case học liệu.

Trạng thái	Sự kiện vào	Điều kiện	Trạng thái ra
DRAFT	Lưu đơn mới	Chưa chọn xác nhận	DRAFT
DRAFT	Confirm Order	Tổng phơi nhiễm không vượt hạn mức	CONFIRMED
DRAFT	Confirm Order	Tổng phơi nhiễm vượt hạn mức	CREDIT_HOLD
CREDIT_HOLD	Credit Release bởi ACT-CREDIT-003	Có lý do phát hành tín dụng mô phỏng	CONFIRMED
CONFIRMED	Gửi yêu cầu kho	Có đơn đã xác nhận	PICKING_REQUESTED

3.4 Payload đầu vào mô phỏng

{
  "salesOrderId": "SO-NF-260807-001",
  "customerId": "CUS-NF-000184",
  "warehouseId": "WH-NF-HCM-01",
  "currency": "VND",
  "createdAt": "2026-08-07T09:15:00+07:00",
  "createdBy": "ACT-SALES-014",
  "lines": [
    {
      "lineNo": 1,
      "sku": "SKU-NF-DRK-330-CTN",
      "quantity": 600,
      "unitNetPrice": 185000,
      "lineNetAmount": 111000000,
      "vatRate": 0.08,
      "vatAmount": 8880000,
      "lineGrossAmount": 119880000
    }
  ],
  "orderNetAmount": 111000000,
  "orderVatAmount": 8880000,
  "orderGrossAmount": 119880000,
  "openArAmount": 395000000,
  "creditLimitAmount": 500000000
}

3.5 Thiết kế test case đã điền

Test case ID	Mục tiêu	Dữ liệu tính	Thao tác	Kết quả mong đợi	Mức ưu tiên
TC-NF-CR-001	Xác nhận đơn dưới hạn mức	395.000.000 + 104.999.000 = 499.999.000 VND	Sửa số lượng thành 567 thùng, chọn Confirm Order	Đơn SO-NF-260807-002 chuyển CONFIRMED; không hiện thông báo chặn; tạo một yêu cầu kho mô phỏng PICK-NF-260807-002.	HIGH
TC-NF-CR-002	Xác nhận đơn đúng bằng hạn mức	395.000.000 + 105.000.000 = 500.000.000 VND	Sửa số lượng thành 568 thùng và đơn giá thành 184.859 VND, chọn Confirm Order	Đơn SO-NF-260807-003 chuyển CONFIRMED; không bị giữ tín dụng; tạo một yêu cầu kho mô phỏng PICK-NF-260807-003.	HIGH
TC-NF-CR-003	Chặn đơn vượt hạn mức	395.000.000 + 111.000.000 = 506.000.000 VND	Dùng payload SO-NF-260807-001, chọn Confirm Order	Đơn chuyển CREDIT_HOLD; không tạo PICKING_REQUESTED; hiển thị: Công nợ mở 395.000.000 VND + tiền hàng 111.000.000 VND = 506.000.000 VND, vượt hạn mức 500.000.000 VND: 6.000.000 VND.	CRITICAL
TC-NF-CR-004	Chặn người tạo đơn tự phát hành tín dụng	Đơn SO-NF-260807-001 đang CREDIT_HOLD	Đăng nhập ACT-SALES-014, chọn Credit Release	Thao tác bị từ chối; đơn giữ CREDIT_HOLD; thông báo: Bạn không có quyền phát hành tín dụng cho đơn này.	HIGH
TC-NF-CR-005	Cho phép quản lý tín dụng phát hành đơn bị giữ	Đơn SO-NF-260807-001; lý do CRR-NF-260807-001 = Khách đã nộp tiền mô phỏng 10.000.000 VND, chờ đối soát.	Đăng nhập ACT-CREDIT-003, nhập lý do, chọn Credit Release	Đơn chuyển CONFIRMED; lưu releasedBy = ACT-CREDIT-003, releaseReasonId = CRR-NF-260807-001; tạo một yêu cầu kho mô phỏng PICK-NF-260807-001.	HIGH

3.6 Quyết định thiết kế

Vấn đề	Các lựa chọn	Tiêu chí	Khuyến nghị mô phỏng	Thẩm quyền quyết định	Hậu quả nếu sai
Giá trị dùng kiểm tra hạn mức	Tổng gồm VAT; tiền hàng chưa thuế; tổng đã thanh toán	Nhất quán với dữ liệu công nợ và chính sách tín dụng được xác định cho case	Dùng orderNetAmount chưa thuế theo BR-NF-CR-001	Business Owner và Accounting Owner mô phỏng cần xác minh nếu chuyển thành yêu cầu thật	Chặn nhầm hoặc cho giao hàng vượt mức rủi ro dự kiến
Điểm chặn	Khi lưu nháp; khi xác nhận đơn; sau khi tạo yêu cầu kho	Chặn đủ sớm nhưng không cản nhập liệu hợp lệ	Chặn tại Confirm Order	Business Owner mô phỏng	Kho có thể nhận lệnh từ đơn chưa qua kiểm soát
Quyền phát hành tín dụng	Nhân viên bán hàng; quản lý tín dụng; xử lý tự động	Tách nhiệm vụ và khả năng giải trình	Chỉ ACT-CREDIT-003 trong case mô phỏng	Business Owner và Security Owner mô phỏng cần xác minh nếu áp dụng thật	Người tạo đơn có thể tự bỏ qua kiểm soát hạn mức

3.1 Hồ sơ kiểm thử hoàn chỉnh — tạo đơn bán hàng vượt hạn mức tín dụng

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi người dùng, giao dịch, số tiền và dữ liệu dưới đây là dữ liệu tổng hợp. Test design là thiết kế kiểm thử: xác định điều kiện, dữ liệu, bước chạy và kết quả cần kiểm tra trước khi thực thi.

Trường lõi	Giá trị đã điền
Artifact ID	TMPL-TST-001
Hồ sơ kiểm thử	TST-NF-SO-001
Tên kiểm thử	Chặn xác nhận đơn bán hàng khi khách hàng vượt hạn mức tín dụng
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày thiết kế	2026-08-07
Múi giờ, locale, tiền tệ	Asia/Ho_Chi_Minh, vi-VN, VND
Phân hệ	Sales Order Management
Loại kiểm thử	Functional black-box; kiểm thử hộp đen kiểm tra đầu vào và đầu ra, không dựa vào mã nguồn
Mức ưu tiên	High
Mức rủi ro	High
Người thiết kế mô phỏng	Nguyễn Minh An — Senior BA
Người thực thi mô phỏng	Trần Gia Huy — QA Analyst
Môi trường	SIT-NF-01
Quyết định cần kiểm tra	Đơn vượt hạn mức không được chuyển sang CONFIRMED
Hậu quả nếu sai	Nova Foods mô phỏng có thể ghi nhận đơn vượt ngưỡng kiểm soát, làm sai số dư tín dụng khả dụng và tạo rủi ro giao hàng khi chưa có quyết định ngoại lệ.

Thành phần test basis	ID	Nội dung dùng làm cơ sở	Phân loại nguồn
Business rule	BR-NF-SO-001	Hệ thống chỉ cho phép xác nhận đơn khi tổng dư nợ mở và tổng giá trị đơn chưa xác nhận không vượt hạn mức tín dụng khách hàng.	Quy tắc nghiệp vụ mô phỏng; cần Business Owner xác nhận trước production
Data definition	DD-NF-CUST-CREDIT-001	creditLimitVnd là hạn mức tín dụng khách hàng bằng VND; openReceivableVnd là dư nợ phải thu mở bằng VND.	Định nghĩa dữ liệu mô phỏng
Data definition	DD-NF-SO-TOTAL-001	orderTotalVnd là tổng tiền đơn, gồm hàng hóa và VAT mô phỏng.	Định nghĩa dữ liệu mô phỏng
Security boundary	SEC-NF-SO-001	Chỉ vai trò CreditController được gửi quyết định ngoại lệ tín dụng.	Kiểm soát phân quyền mô phỏng; tham chiếu nhận thức OWASP ASVS 5.0.0, không phải xác nhận tuân thủ
Test terminology	SRC-ISTQB-CTFL-4.0.1	Dùng thuật ngữ điều kiện kiểm thử, dữ liệu kiểm thử, kết quả mong đợi và kiểm thử hộp đen.	Nguồn chuẩn thuật ngữ: ISTQB CTFL Syllabus v4.0.1

Sự kiện hiện tại mô phỏng: khách hàng CUS-NF-000184 có hạn mức 50.000.000 VND, dư nợ mở 42.000.000 VND. Nhân viên bán hàng tạo đơn SO-NF-20260807-0041 trị giá 11.000.000 VND. Tổng phơi nhiễm tín dụng là 53.000.000 VND, lớn hơn hạn mức 3.000.000 VND. Bằng chứng tính toán: 42.000.000 + 11.000.000 = 53.000.000; 53.000.000 - 50.000.000 = 3.000.000. Nhu cầu gốc là ngăn trạng thái xác nhận khi kiểm soát tín dụng chưa đạt.

Phương án	Tiêu chí xét	Kết quả
Cho phép xác nhận và ghi cảnh báo	Không ngăn rủi ro đơn vượt hạn mức	Loại
Chặn xác nhận, cho phép lưu PENDING_CREDIT_REVIEW	Giữ dữ liệu đơn, ngăn giao dịch vượt kiểm soát, tạo điểm xử lý ngoại lệ	Khuyến nghị mô phỏng
Tự động tăng hạn mức khách hàng	Thay đổi chính sách tín dụng và dữ liệu chủ khách hàng	Loại; vượt thẩm quyền hệ thống bán hàng

Quyết định mô phỏng: chọn phương án chặn xác nhận và đặt đơn ở PENDING_CREDIT_REVIEW. CreditController là vai trò có thẩm quyền quyết định ngoại lệ trong case này; template không ghi nhận quyết định ngoại lệ đã được phê duyệt.

Dữ liệu đầu vào	Giá trị
Người dùng	USR-NF-SALES-014 — Lê Thu Hà — vai trò SalesRepresentative
Khách hàng	CUS-NF-000184 — Công ty TNHH Thực phẩm Ánh Dương
Hạn mức tín dụng	50.000.000 VND
Dư nợ mở	42.000.000 VND
Mã hàng	FG-NF-TRA-500-001 — Trà đào đóng chai 500 ml
Số lượng	1.000 chai
Đơn giá chưa VAT	10.000 VND/chai
VAT mô phỏng	1.000.000 VND
Tổng đơn	11.000.000 VND
Ngày yêu cầu giao	2026-08-10
Trạng thái đầu vào đơn	DRAFT

{
  "salesOrderId": "SO-NF-20260807-0041",
  "customerId": "CUS-NF-000184",
  "createdByUserId": "USR-NF-SALES-014",
  "orderDate": "2026-08-07",
  "requestedDeliveryDate": "2026-08-10",
  "currencyCode": "VND",
  "lines": [
    {
      "lineNo": 1,
      "itemId": "FG-NF-TRA-500-001",
      "quantity": 1000,
      "unitPriceVnd": 10000,
      "lineNetAmountVnd": 10000000
    }
  ],
  "vatAmountVnd": 1000000,
  "orderTotalVnd": 11000000,
  "customerCreditLimitVnd": 50000000,
  "customerOpenReceivableVnd": 42000000
}

Bước	Thao tác	Kết quả mong đợi
1	Đăng nhập SIT-NF-01 bằng USR-NF-SALES-014.	Đăng nhập thành công; vai trò hiển thị SalesRepresentative.
2	Tạo đơn bằng payload đã nêu.	Đơn SO-NF-20260807-0041 được lưu ở DRAFT; tổng đơn là 11.000.000 VND.
3	Chọn hành động Confirm Order.	Hệ thống tính phơi nhiễm 53.000.000 VND.
4	Hệ thống so sánh phơi nhiễm với hạn mức.	Điều kiện 53.000.000 > 50.000.000 đúng; xác nhận bị chặn.
5	Kiểm tra trạng thái đơn và thông báo.	Trạng thái là PENDING_CREDIT_REVIEW; thông báo Vượt hạn mức tín dụng 3.000.000 VND. Đơn đã chuyển chờ kiểm soát tín dụng.
6	Kiểm tra hành động giao hàng.	Không có yêu cầu xuất kho hoặc giao hàng được tạo từ đơn này.

Quy tắc trạng thái	Trạng thái nguồn	Điều kiện	Trạng thái đích
ST-NF-SO-001	DRAFT	Người dùng lưu đơn hợp lệ	DRAFT
ST-NF-SO-002	DRAFT	Tổng phơi nhiễm nhỏ hơn hoặc bằng hạn mức	CONFIRMED
ST-NF-SO-003	DRAFT	Tổng phơi nhiễm lớn hơn hạn mức	PENDING_CREDIT_REVIEW
ST-NF-SO-004	PENDING_CREDIT_REVIEW	CreditController từ chối ngoại lệ	CANCELLED
ST-NF-SO-005	PENDING_CREDIT_REVIEW	CreditController chấp nhận ngoại lệ mô phỏng	CONFIRMED

Ngoại lệ hoàn chỉnh: nếu customerCreditLimitVnd không tồn tại, hệ thống không tính tín dụng, giữ đơn ở DRAFT, trả thông báo Không tìm thấy hạn mức tín dụng khách hàng; không thể xác nhận đơn., và không tạo yêu cầu giao hàng. Đây là kiểm soát dữ liệu đầu vào; không suy diễn hạn mức bằng 0 VND vì có thể che giấu lỗi dữ liệu chủ.

Phân tích quyết định kiểm thử: chặn xuất kho vượt tồn khả dụng

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu, actor, giao dịch và giá trị dưới đây là tổng hợp. Bản ghi kiểm thử TMPL-TST-001 dùng tình huống đơn bán SO-NF-260807-014 của khách hàng mô phỏng KH-NF-018, yêu cầu xuất 120 thùng SP-NF-CHA-500, đơn giá 185.000 VND/thùng, tổng trước thuế 22.200.000 VND. Kho KHO-HCM-01 có tồn thực tế 100 thùng, đã giữ chỗ 15 thùng cho đơn SO-NF-260807-009, nên tồn khả dụng là 85 thùng.

Mục	Nội dung đã điền
Sự kiện kiểm thử	Nhân viên kho mô phỏng NV-NF-047 tạo phiếu xuất PX-NF-260807-031 lúc 10:15 ngày 2026-08-07, Asia/Ho_Chi_Minh, cho 120 thùng SP-NF-CHA-500.
Thực trạng	ERP mô phỏng chỉ so sánh số lượng yêu cầu 120 với tồn thực tế 100. Hệ thống trả lỗi thiếu 20 thùng nhưng không trừ 15 thùng đã giữ chỗ.
Nhu cầu gốc	Bảo vệ cam kết hàng đã giữ cho đơn trước; ngăn hai giao dịch cùng dùng một lượng hàng; cho nhân viên biết lượng còn có thể cấp ngay.
Quy tắc cần kiểm thử	Tồn khả dụng = tồn thực tế - số lượng đã giữ chỗ. Chỉ cho phép xác nhận xuất khi số lượng yêu cầu không lớn hơn tồn khả dụng. Với dữ liệu này, 120 lớn hơn 85 nên phiếu phải bị chặn.
Trạng thái mong đợi	PX-NF-260807-031 giữ trạng thái DRAFT; không tạo bút toán tồn kho mô phỏng; không giảm tồn thực tế; hiển thị “Số lượng yêu cầu 120 thùng vượt tồn khả dụng 85 thùng.”
Phân loại nguồn	Quy tắc tính và trạng thái là Project assumption cho case học liệu, chưa phải quy tắc vận hành Nova Foods thực. Thuật ngữ kiểm thử hộp đen dựa trên nguồn chính ISTQB CTFL Syllabus v4.0.1; không suy diễn điều khoản pháp lý hay kế toán.
Liên kết nguồn	SRC-ISTQB-CTFL-001 — nguồn chính; /01-curriculum/CANONICAL_BUSINESS_RULES.md — catalog quy tắc canonical ở trạng thái IN_REVIEW; /01-curriculum/CANONICAL_DATA_DICTIONARY.md — nguồn kiểm soát nghĩa dữ liệu logic.

Các lựa chọn đã xét

Lựa chọn	Cách xử lý	Tiêu chí đánh giá	Kết quả
OPT-01	So sánh với tồn thực tế	Dễ làm nhưng bỏ qua hàng đã giữ chỗ	Loại
OPT-02	Cho xuất vượt, tạo cảnh báo	Giảm chặn thao tác nhưng tạo nguy cơ cấp trùng hàng	Loại
OPT-03	So sánh với tồn khả dụng, chặn xác nhận xuất	Bảo toàn lượng đã giữ, kết quả xác định, kiểm thử được bằng dữ liệu biên	Khuyến nghị

Khuyến nghị và thẩm quyền quyết định: Khuyến nghị OPT-03. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận logic kiểm thử và bằng chứng suy luận: tồn thực tế 100 trừ giữ chỗ 15 bằng tồn khả dụng 85, nhỏ hơn yêu cầu 120. Business Owner mô phỏng quyết định ưu tiên phân bổ hàng; Solution Architect mô phỏng xác nhận điểm kiểm tra giao dịch; QA Reviewer mô phỏng xác nhận ca kiểm thử. Không có phê duyệt, baseline hoặc xác nhận production tại IN_REVIEW, v0.9.0.

Hậu quả nếu quyết định sai: Chọn OPT-01 hoặc OPT-02 có thể cho phép xuất 120 thùng khi chỉ 85 thùng chưa được cam kết, làm đơn SO-NF-260807-009 mất 15 thùng đã giữ chỗ. Chọn OPT-03 nhưng tính sai tồn khả dụng có thể chặn nhầm đơn hợp lệ, giảm khả năng giao hàng.

4. Tier 3 ? Fully Completed Nova Foods Case: Evidence and Traceability

Phạm vi bằng chứng: Case Nova Foods Trading & Manufacturing là mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Kịch bản kiểm thử xác nhận xuất kho cho đơn SO-NF-260807-009: mặt hàng FG-NF-CHA-01, yêu cầu 120 thùng; tồn thực tế 100 thùng; lượng đã giữ chỗ 15 thùng; tồn khả dụng tính được là 85 thùng. Vì 120 > 85, hệ thống phải chặn xác nhận xuất kho. Đây là kiểm thử hộp đen: người kiểm thử đánh giá đầu vào và kết quả thấy được, không suy đoán mã nguồn.

Loại bằng chứng	Tham chiếu	Nội dung cần đối chiếu	Kết quả mong đợi
Bản ghi đơn hàng mô phỏng	SO-NF-260807-009	Số lượng yêu cầu 120 thùng cho FG-NF-CHA-01	Đơn còn trạng thái chờ xuất; không tạo xác nhận xuất
Bản ghi tồn kho mô phỏng	INV-NF-260807-001	Tồn thực tế 100, giữ chỗ 15, tồn khả dụng 85 thùng	Số liệu đủ để tái tính 100 - 15 = 85
Kết quả kiểm thử âm	TC-NF-INV-NEG-001	Người dùng xác nhận xuất 120 thùng khi tồn khả dụng 85	Hệ thống từ chối thao tác; không giảm tồn thực tế; không giải phóng lượng giữ chỗ
Nhật ký giao dịch mô phỏng	EV-NF-INV-001	Thời điểm chạy, người kiểm thử mô phỏng, đơn hàng, số lượng yêu cầu, kết quả chặn	Có dấu vết kiểm tra để QA Reviewer mô phỏng đối chiếu
Quy tắc nghiệp vụ đang xem xét	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Cơ sở so sánh lượng xuất với tồn khả dụng	Chỉ là liên kết nguồn kiểm soát IN_REVIEW; không phải baseline
Nghĩa dữ liệu logic đang xem xét	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Phân biệt tồn thực tế, giữ chỗ, tồn khả dụng	Không dùng nhầm tồn thực tế làm lượng được phép xuất

Ngoại lệ và đường đi âm

ID	Điều kiện kích hoạt	Xử lý hệ thống mong đợi	Bằng chứng cần lưu	Lý do kiểm soát
EXC-NF-INV-001	Số lượng xuất 120 lớn hơn tồn khả dụng 85	Chặn xác nhận xuất; hiển thị lỗi nghiệp vụ nêu số lượng khả dụng 85 thùng	TC-NF-INV-NEG-001, EV-NF-INV-001	Ngăn cấp trùng 15 thùng đã giữ chỗ
EXC-NF-INV-002	Không tìm thấy bản ghi tồn cho FG-NF-CHA-01 tại kho mô phỏng	Chặn xác nhận; không tự gán tồn bằng 0 mà không ghi lỗi	Nhật ký lỗi mô phỏng EV-NF-INV-002	Thiếu dữ liệu không chứng minh được hàng hết; cần phân biệt lỗi dữ liệu với thiếu hàng
EXC-NF-INV-003	Lượng xuất bằng 0 hoặc âm	Chặn trước khi kiểm tra tồn kho	Kết quả chạy TC-NF-INV-NEG-002	Số lượng xuất phải là số dương; tránh giao dịch vô nghĩa hoặc đảo chiều không có quy trình riêng
EXC-NF-INV-004	Bản ghi giữ chỗ lớn hơn tồn thực tế, ví dụ 110 > 100	Chặn xác nhận; gắn cờ sai lệch dữ liệu	Nhật ký sai lệch EV-NF-INV-003	Tồn khả dụng âm là tín hiệu dữ liệu hoặc quy trình giữ chỗ cần điều tra, không được tự sửa
EXC-NF-INV-005	Hai người dùng mô phỏng cùng xác nhận xuất từ cùng tồn khả dụng	Không được cả hai giao dịch cùng dùng một lượng khả dụng; cần kiểm tra tại điểm ghi giao dịch	Kết quả kiểm tra đồng thời VR-NF-INV-001	Kiểm tra chỉ tại màn hình có thể không ngăn được cấp trùng khi giao dịch chạy đồng thời

Thông điệp lỗi mô phỏng cho EXC-NF-INV-001: Không thể xác nhận xuất kho cho SO-NF-260807-009. Mặt hàng FG-NF-CHA-01 yêu cầu 120 thùng, tồn khả dụng 85 thùng. Thông điệp nêu đơn, mặt hàng, yêu cầu và lượng khả dụng để người dùng hiểu nguyên nhân. Thông điệp không nêu cấu trúc DB, tên dịch vụ nội bộ, dữ liệu cá nhân hay thông tin bảo mật.

Giả định và mục cần xác minh

ID	Nội dung	Cầu nối suy luận/bằng chứng	Trạng thái
ASM-NF-INV-001	tồn khả dụng = tồn thực tế - lượng giữ chỗ	Dữ liệu case có 100 - 15 = 85; lựa chọn OPT-03 đã khuyến nghị so sánh với tồn khả dụng	Giả định dự án mô phỏng
ASM-NF-INV-002	Đơn vị thùng của yêu cầu xuất khớp đơn vị tồn kho	Cả đơn SO-NF-260807-009 và tồn INV-NF-260807-001 dùng thùng; không có dữ liệu quy đổi đơn vị	Giả định dự án mô phỏng
VR-NF-INV-001	Điểm kiểm tra tồn khả dụng khi xác nhận đồng thời	EXC-NF-INV-005 cho thấy kiểm tra trước khi lưu chưa đủ bằng chứng chống cấp trùng	Verification required từ Solution Architect mô phỏng
VR-NF-INV-002	Quy tắc xử lý giữ chỗ khi đơn bị chặn	Case chỉ chứng minh phải không giải phóng giữ chỗ khi chặn; chưa có quy tắc vòng đời giữ chỗ đầy đủ	Verification required từ Business Owner mô phỏng
VR-NF-INV-003	Chính sách cho phép xuất vượt hoặc phân bổ một phần	OPT-02 đã bị loại trong case học liệu; chưa có baseline nghiệp vụ để áp dụng rộng hơn	Verification required từ Business Owner mô phỏng
VR-NF-INV-004	Yêu cầu lưu vết và thời hạn lưu nhật ký xuất kho	Nguồn pháp lý và kế toán chỉ là nguồn tham khảo; case không diễn giải nghĩa vụ pháp lý	Verification required từ Legal Owner và Accounting Owner mô phỏng

Escalation records

ID	Sự kiện phải escalte	Người nhận mô phỏng	Gói bằng chứng tối thiểu	Trạng thái
ESC-NF-INV-001	Tồn thực tế nhỏ hơn lượng giữ chỗ	Business Owner, Solution Architect, QA Reviewer	INV-NF-260807-001, EV-NF-INV-003, thời điểm phát hiện theo Asia/Ho_Chi_Minh	Mở để xem xét; không tự điều chỉnh tồn
ESC-NF-INV-002	Có đề xuất cho xuất vượt tồn khả dụng	Business Owner, Accounting Owner, Solution Architect	SO-NF-260807-009, số lượng yêu cầu 120, tồn khả dụng 85, mô tả tác động phân bổ	Mở để quyết định nghiệp vụ; không suy diễn thành quy tắc
ESC-NF-INV-003	Có yêu cầu coi traceability thực phẩm hoặc lưu chứng từ là nghĩa vụ pháp lý	Legal Owner, Food-safety Domain Owner, Accounting Owner	Tham chiếu nguồn chính thức trong /00-research/00_SOURCE_MAP.md, phạm vi yêu cầu, dữ liệu bị ảnh hưởng	Mở để xác minh; học liệu không thay thế kết luận pháp lý

Các ID trên là liên kết kiểm soát trong artifact IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không tạo baseline, approval, cấu hình ERP thực hay xác nhận tuân thủ.

Ma trận truy vết đầu-cuối — nhận hàng thành phẩm theo lô

Nova Foods Trading & Manufacturing là case mô phỏng; mọi mã lô, người dùng, ngày giờ và dữ liệu dưới đây là dữ liệu tổng hợp. Traceability là khả năng lần ngược từ nhu cầu đến kiểm thử và lần xuôi từ lỗi hoặc thay đổi về nguồn gây ra. Chuỗi này đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, chưa có baseline hoặc approval.

Thứ tự	ID	Loại	Nội dung đã điền	Bằng chứng hoặc cầu nối suy luận	Liên kết kế tiếp
1	NEED-NF-001	NEED — nhu cầu	Kho Nova Foods cần biết lô thành phẩm nào đã được nhận để hỗ trợ truy xuất mô phỏng khi có sự cố chất lượng.	Luật An toàn thực phẩm là nguồn pháp lý cho bối cảnh truy xuất/thu hồi; không suy ra nghĩa vụ cấu hình ERP cụ thể.	REQ-NF-001
2	REQ-NF-001	REQ — yêu cầu	ERP phải từ chối ghi nhận phiếu nhận thành phẩm nếu thiếu batchCode; phiếu hợp lệ phải lưu mã lô cùng mã hàng, số lượng và thời điểm nhận.	NEED-NF-001 chỉ đạt khi từng lần nhận có khóa nhận diện lô. batchCode là dữ liệu tối thiểu để phân biệt các lần nhận cùng mã hàng.	BR-NF-001, AC-NF-001, DATA-NF-001
3	BR-NF-001	BR — quy tắc nghiệp vụ	Một dòng nhận thành phẩm chỉ được ghi sổ kho mô phỏng khi batchCode không rỗng sau khi bỏ khoảng trắng đầu-cuối và dài từ 6 đến 20 ký tự.	Đây là project assumption để tạo ca học và ca kiểm thử; chưa phải quy tắc Nova Foods thực tế. Cần Business Owner và QA Owner xác minh trước baseline.	AC-NF-001, TC-NF-002, TC-NF-003
4	AC-NF-001	AC — tiêu chí chấp nhận	Với người dùng kho có quyền tạo nhận hàng, khi nhập itemCode=FG-NF-CHILI-500G, quantity=240, uom=PACK, batchCode=NF260807A, hệ thống tạo receipt trạng thái POSTED và lưu đủ bốn trường.	Ví dụ chứng minh đường hợp lệ của REQ-NF-001; batchCode có 9 ký tự nên thỏa BR-NF-001.	TC-NF-001
5	AC-NF-002	AC — tiêu chí chấp nhận	Khi batchCode rỗng hoặc chỉ có khoảng trắng, hệ thống không tạo receipt POSTED, trả lỗi BATCH_CODE_REQUIRED, giữ nguyên dữ liệu người dùng đã nhập.	Nếu vẫn ghi nhận kho khi thiếu lô, NEED-NF-001 mất khả năng phân biệt lần nhận.	TC-NF-002
6	AC-NF-003	AC — tiêu chí chấp nhận	Khi batchCode=NF26, hệ thống không tạo receipt POSTED, trả lỗi BATCH_CODE_LENGTH_INVALID.	NF26 dài 4 ký tự, thấp hơn ngưỡng 6 của BR-NF-001.	TC-NF-003
7	DATA-NF-001	DATA — dữ liệu logic	Thực thể FinishedGoodsReceiptLine: receiptId, itemCode, quantity, uom, batchCode, receivedAt. batchCode là chuỗi bắt buộc 6–20 ký tự sau chuẩn hóa khoảng trắng.	REQ-NF-001 yêu cầu lưu mã lô cùng dữ liệu nhận. Đây là mô hình logic học liệu, không phải schema production.	API-NF-001, TC-NF-001 đến TC-NF-003
8	API-NF-001	API — giao diện lập trình	POST /api/v1/finished-goods-receipts nhận dòng thành phẩm có batchCode; phản hồi 201 cho dữ liệu hợp lệ, 422 cho lỗi xác thực nghiệp vụ đầu vào.	OpenAPI Specification 3.1.1 là nguồn chuẩn mô tả HTTP API; mã trạng thái và payload dưới đây là thiết kế mô phỏng, chưa được Architect phê duyệt.	TC-NF-001 đến TC-NF-003
9	TC-NF-001	TC — ca kiểm thử	Gửi dữ liệu hợp lệ theo AC-NF-001; mong đợi 201, status=POSTED, batchCode=NF260807A.	Kiểm tra đồng thời yêu cầu lưu dữ liệu và đường hợp lệ của quy tắc.	Không có DEF
10	TC-NF-002	TC — ca kiểm thử	Gửi batchCode=" "; mong đợi 422, lỗi BATCH_CODE_REQUIRED, không có receipt POSTED.	Kiểm tra chuẩn hóa khoảng trắng và đường từ chối của AC-NF-002.	Không có DEF
11	TC-NF-003	TC — ca kiểm thử	Gửi batchCode="NF26"; mong đợi 422, lỗi BATCH_CODE_LENGTH_INVALID, không có receipt POSTED.	Kiểm tra cận dưới 6 ký tự của BR-NF-001 và AC-NF-003.	Không có DEF
12	DEF-NF-001	DEF — lỗi	Chưa có lỗi được ghi nhận trong case mô phỏng này. Không tạo defect giả để lấp ma trận.	DEF chỉ tồn tại sau kết quả thực thi khác mong đợi; hiện không có bằng chứng chạy test.	Nếu phát hiện lỗi: liên kết về TC-NF-001 hoặc TC-NF-002 hoặc TC-NF-003
13	CR-NF-001	CR — yêu cầu thay đổi	Chưa có yêu cầu thay đổi được ghi nhận trong case mô phỏng này.	CR chỉ mở khi thay đổi phạm vi, quy tắc hoặc thiết kế có nguồn và owner hợp lệ; không suy diễn từ trạng thái IN_REVIEW.	Nếu có CR: đánh giá ảnh hưởng từ NEED-NF-001 đến các TC liên quan

NEED-NF-001
  └─ REQ-NF-001
      ├─ BR-NF-001
      │   ├─ AC-NF-001 ─ API-NF-001 ─ TC-NF-001
      │   ├─ AC-NF-002 ─ API-NF-001 ─ TC-NF-002
      │   └─ AC-NF-003 ─ API-NF-001 ─ TC-NF-003
      └─ DATA-NF-001 ─ API-NF-001

Kiểm tra truy vết	Kết quả tại IN_REVIEW	Ranh giới nguồn
NEED có ít nhất một REQ	Đạt: NEED-NF-001 liên kết REQ-NF-001.	Nhu cầu là case mô phỏng, không phải xác nhận vận hành Nova Foods.
REQ có BR hoặc AC kiểm chứng được	Đạt: một BR, ba AC, ba TC.	BR-NF-001 là project assumption.
DATA và API không tự thành nguồn nghiệp vụ	Đạt: DATA-NF-001 và API-NF-001 chỉ hiện thực hóa REQ-NF-001.	OAS 3.1.1 chỉ hỗ trợ cách mô tả API, không phê duyệt thiết kế này.
DEF hoặc CR không bị bịa	Đạt: không có bản ghi DEF/CR giả.	Khi có kết quả test hoặc thay đổi thật trong corpus, tạo ID theo registry và nối lại chuỗi.
Cơ sở pháp lý không bị diễn giải quá mức	Đạt: bối cảnh truy xuất từ Luật An toàn thực phẩm, nhưng quy tắc ERP còn cần xác minh.	Legal Owner và Business Owner phải xác minh trước khi gọi là nghĩa vụ hoặc baseline.

4.3 Bảng quyết định, dữ liệu kiểm thử và payload mô phỏng cho kiểm tra hạn mức tín dụng đơn bán

Bảng quyết định (decision table) là bảng ghép mọi tổ hợp điều kiện với kết quả mong đợi. Dùng bảng này vì kiểm thử luồng phê duyệt tín dụng không được suy đoán từ một ví dụ đơn lẻ. Nova Foods Trading & Manufacturing là case mô phỏng; mọi mã, tên khách hàng, số tiền và payload dưới đây là dữ liệu tổng hợp, đơn vị tiền tệ VND.

Điều kiện / Hành động	R1	R2	R3	R4
Khách hàng có trạng thái tín dụng ACTIVE	Có	Có	Có	Không
Tổng dư nợ sau đơn hàng không vượt hạn mức	Có	Không	Không	Có
Đơn hàng có yêu cầu giao hàng gấp	Không	Không	Có	Không
Lưu đơn với trạng thái CONFIRMED	Có	Không	Không	Không
Lưu đơn với trạng thái PENDING_CREDIT_REVIEW	Không	Có	Có	Không
Chặn xác nhận đơn	Không	Có	Có	Có
Thông báo kết quả	Đơn hàng được xác nhận.	Vượt hạn mức tín dụng; chờ kiểm tra tín dụng.	Vượt hạn mức tín dụng; giao hàng gấp không bỏ qua kiểm tra tín dụng.	Khách hàng không ở trạng thái tín dụng hoạt động.

Quy tắc tính dùng dữ liệu kiểm thử: Tổng dư nợ sau đơn = Dư nợ hiện tại + Giá trị đơn hàng. Ví dụ 180.000.000 VND + 30.000.000 VND = 210.000.000 VND; kết quả vượt hạn mức 200.000.000 VND nên áp dụng R2. Đây là suy luận từ phép cộng số học và điều kiện “không vượt”, không phải quy tắc pháp lý, kế toán hoặc cấu hình ERP thực tế.

Bộ dữ liệu	Khách hàng	Trạng thái tín dụng	Hạn mức	Dư nợ hiện tại	Mã đơn	Giá trị đơn	Giao gấp	Quy tắc	Kết quả mong đợi
TD-CREDIT-001	CUS-NF-001 — Siêu thị An Phú Mô Phỏng	ACTIVE	200.000.000	150.000.000	SO-NF-260807-001	30.000.000	Không	R1	CONFIRMED; tổng dư nợ sau đơn 180.000.000
TD-CREDIT-002	CUS-NF-002 — Đại lý Bình Minh Mô Phỏng	ACTIVE	200.000.000	180.000.000	SO-NF-260807-002	30.000.000	Không	R2	PENDING_CREDIT_REVIEW; không xác nhận
TD-CREDIT-003	CUS-NF-003 — Cửa hàng Hương Việt Mô Phỏng	ACTIVE	200.000.000	195.000.000	SO-NF-260807-003	10.000.000	Có	R3	PENDING_CREDIT_REVIEW; giao gấp không bỏ qua kiểm tra
TD-CREDIT-004	CUS-NF-004 — Nhà phân phối Nam Sơn Mô Phỏng	SUSPENDED	200.000.000	50.000.000	SO-NF-260807-004	20.000.000	Không	R4	Bị chặn; không tạo đơn xác nhận

Payload JSON dưới đây là dữ liệu đầu vào mô phỏng cho TD-CREDIT-002. Payload chỉ minh họa kiểm thử API (Application Programming Interface, giao diện cho hệ thống trao đổi dữ liệu); không xác nhận endpoint, schema, xác thực hay hợp đồng tích hợp thật.

{
  "salesOrderId": "SO-NF-260807-002",
  "customerId": "CUS-NF-002",
  "orderDate": "2026-08-07",
  "currency": "VND",
  "requestedDeliveryType": "STANDARD",
  "orderTotal": 30000000,
  "creditSnapshot": {
    "status": "ACTIVE",
    "creditLimit": 200000000,
    "currentOutstanding": 180000000
  },
  "lines": [
    {
      "lineNo": 1,
      "itemCode": "NF-SNACK-001",
      "itemName": "Bánh gạo Nova Mô Phỏng 180g",
      "quantity": 100,
      "unitPrice": 300000,
      "lineTotal": 30000000
    }
  ]
}

Kết quả xử lý mong đợi cho payload này là PENDING_CREDIT_REVIEW, vì 180000000 + 30000000 = 210000000, lớn hơn creditLimit là 200000000. Giá trị status, số tiền và mã hàng trong payload là giả lập học liệu. Cách tính hạn mức, quyền phê duyệt, bút toán, giữ hàng và giao hàng cần xác minh bởi Business Owner, Accounting Owner và Architect trước mọi dùng ngoài corpus IN_REVIEW v0.9.0.

5. Tier 4 ? Senior BA Quality Gate

Senior BA Quality Gate là cổng rà soát trước baseline: kiểm tra test design có đủ điều kiện để chuyển sang bước xác nhận chính thức hay phải sửa, dừng hoặc chuyển vấn đề cho đúng chủ thể có thẩm quyền. Cổng này không tạo approval, không xác nhận tuân thủ, không thay thế quyết định của Business Owner, QA, Architect, Security, Legal Owner hoặc Accounting Owner. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Hạng mục kiểm tra	PASS — được qua	FAIL — phải sửa	STOP — dừng xử lý test design	Escalation — chuyển đúng vai trò
Tính đầy đủ	Mỗi test case có ID, mục tiêu, tiền điều kiện, dữ liệu, bước thực hiện, kết quả mong đợi, mức ưu tiên và trạng thái rõ.	Thiếu một trường làm người kiểm thử không thể thực hiện hoặc không thể kết luận kết quả.	Thiếu test basis, tức đầu vào làm căn cứ kiểm thử, cho luồng nghiệp vụ cốt lõi.	Principal IT Business Analyst / Technical Curriculum Author tập hợp thiếu sót; Business Owner làm rõ phạm vi.
Tính nhất quán	Mã, trạng thái, số liệu, quy tắc và thuật ngữ giống artifact canonical được liên kết. Ví dụ cùng dùng PENDING_CREDIT_REVIEW, không đổi thành trạng thái khác.	Hai test case cùng dữ liệu nhưng nêu kết quả mong đợi khác nhau.	Canonical source mâu thuẫn hoặc không xác định nguồn nào là nguồn quyết định.	Chủ sở hữu artifact canonical quyết định; BA ghi nhận liên kết và tác động.
Tính kiểm thử được	Kết quả mong đợi quan sát được, so sánh được và có điều kiện đạt hoặc không đạt cụ thể.	Dùng kết quả mơ hồ như “hệ thống xử lý đúng” mà không nêu trạng thái, thông báo, dữ liệu hay hành vi kiểm tra.	Quy tắc không có điều kiện đầu vào, cách tính hoặc kết quả xác định nên không thể thiết kế oracle kiểm thử. Oracle là cơ chế xác định kết quả thực tế có đúng kỳ vọng không.	Business Owner xác nhận quy tắc; QA Lead xác nhận cách kiểm tra.
Truy vết	Mỗi test case liên kết được tới requirement, business rule, acceptance criterion, dữ liệu và nguồn bằng ID canonical.	Link thiếu, sai ID, trỏ tới tệp không kiểm soát hoặc chỉ ghi tên mô tả.	Không thể truy ngược từ lỗi nghiêm trọng tới requirement hoặc quy tắc nguồn.	Principal IT Business Analyst / Technical Curriculum Author sửa ma trận truy vết; Owner nguồn xử lý ID sai.
Thẩm quyền nguồn	Nguồn được phân loại đúng: primary source, canonical corpus source, project assumption hoặc Verification required.	Suy luận được viết thành fact; nguồn tham khảo bị trình bày như luật hoặc quyết định nghiệp vụ.	Yêu cầu pháp lý, kế toán, thuế, bảo mật hoặc an toàn thực phẩm không có nguồn chính thức hay chủ thể xác minh phù hợp.	Legal Owner, Accounting Owner, Security Owner hoặc domain owner theo loại nội dung.
Ownership	Mỗi quyết định, dữ liệu, ngoại lệ và tiêu chí ký xác nhận có owner chịu trách nhiệm rõ.	Gán “BA xác nhận” cho quyết định thuộc Business Owner, Accounting Owner hoặc Legal Owner.	Không xác định được ai có quyền quyết định ngoại lệ tác động đơn hàng, công nợ, hóa đơn hoặc dữ liệu cá nhân.	Chuyển Business Owner; đồng thời chuyển Accounting Owner, Legal Owner hoặc Security Owner khi có ranh giới chồng lấn.
Bảo mật và riêng tư	Test data tổng hợp; không chứa dữ liệu cá nhân thật, bí mật xác thực, khóa API, mật khẩu hoặc thông tin production. Quyền truy cập mô tả theo vai trò.	Payload, ảnh chụp hoặc bước test lộ dữ liệu nhạy cảm hoặc giả định quyền truy cập không kiểm soát.	Test design yêu cầu dùng dữ liệu thật, bypass xác thực hoặc xuất dữ liệu không có căn cứ bảo vệ.	Security Owner và Legal Owner. Tham chiếu OWASP ASVS 5.0.0, OWASP API Security Top 10 2023 chỉ là good practice, không phải luật Việt Nam.
Ranh giới pháp lý, kế toán và hóa đơn	Nội dung ngoài nguồn chính thức được gắn project assumption hoặc Verification required; không biến giả định thành nghĩa vụ.	Khẳng định cách hạch toán, thuế, hóa đơn, lưu trữ hoặc xử lý dữ liệu cá nhân mà không có xác minh có thẩm quyền.	Test case buộc hành vi có hệ quả pháp lý hoặc kế toán nhưng chưa được Legal Owner và Accounting Owner xác minh.	Legal Owner, Accounting Owner; kiểm tra nguồn chính thức liên quan Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13 và Nghị định 123/2020/NĐ-CP.
Tác động thay đổi	Mọi thay đổi rule, data field, trạng thái, tích hợp hoặc quyền có danh sách test case bị ảnh hưởng và traceability cập nhật.	Sửa expectation nhưng không rà test case, dữ liệu hoặc rule liên quan.	Thay đổi làm đổi quyết định nghiệp vụ, kiểm soát tín dụng, dữ liệu cá nhân, hạch toán, hóa đơn hoặc kiến trúc tích hợp mà chưa đánh giá tác động.	Business Owner, Architect, Security Owner, Accounting Owner hoặc Legal Owner theo phạm vi tác động.
Quản trị phiên bản	Giữ IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND; không gọi tài liệu là baseline hay approved.	Metadata khác corpus hoặc dùng thuật ngữ approval không có tham chiếu kiểm soát.	Có yêu cầu sửa im lặng, đổi ID canonical, hoặc đưa nội dung sang production-ready.	Owner artifact xử lý quản trị; Principal IT Business Analyst / Technical Curriculum Author bảo toàn lịch sử và traceability.

Quy tắc quyết định: PASS chỉ khi mọi hạng mục đều đạt hoặc mọi FAIL đã được sửa và kiểm tra lại. Một STOP đủ chặn chuyển baseline. Escalation không phải phê duyệt: BA chỉ ghi vấn đề, bằng chứng, artifact bị ảnh hưởng, owner cần quyết định và trạng thái IN_REVIEW.

Ma trận rà soát chất lượng: đầy đủ, nhất quán và ranh giới thẩm quyền

Senior BA kiểm tra test design từ nguyên lý: test chỉ đáng tin khi có test basis, dữ liệu, kết quả mong đợi, người chịu trách nhiệm và nguồn truy vết. 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.

Khía cạnh	Câu hỏi kiểm tra	Bằng chứng bắt buộc	Kết quả ghi nhận cho Nova Foods mô phỏng
Đầy đủ	Mỗi test case có ID, mục tiêu, điều kiện đầu vào, bước thực hiện, dữ liệu, kết quả mong đợi và liên kết requirement/rule không?	Core Record Tier 3; Evidence and Traceability Tier 3	Cần đối chiếu từng trường của test case với bản ghi hoàn chỉnh; trường trống làm kết quả test không tái lập được.
Nhất quán	Tên nghiệp vụ, mã dữ liệu, đơn vị VND, định dạng ngày và trạng thái có giống giữa test case, rule, data dictionary không?	CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY; TRACEABILITY_ID_REGISTRY	Phải giữ nguyên canonical ID và filename. Không đổi tên rule trong test design vì đổi tên làm đứt liên kết kiểm soát.
Khả năng kiểm thử	Kết quả mong đợi có quan sát, đo hoặc xác nhận được không? Có phân biệt kết quả hợp lệ và lỗi không?	Bước test, expected result, dữ liệu tổng hợp	Câu “hệ thống xử lý đúng” không đủ kiểm thử. Cần nêu giá trị hiển thị, trạng thái, thông báo lỗi, bản ghi tạo hoặc không tạo.
Truy vết	Mỗi test case truy ngược được về requirement, business rule, dữ liệu và nguồn không?	ID liên kết trong Tier 3; TRACEABILITY_ID_REGISTRY	Liên kết chỉ hợp lệ khi ID tồn tại đúng dạng trong registry. URL nguồn không thay thế canonical ID nội bộ.
Thẩm quyền nguồn	Rule hoặc yêu cầu có được gắn đúng nguồn: nội bộ mô phỏng, chuẩn, pháp luật, hay giả định dự án không?	00_SOURCE_MAP; URL chính thức; nhãn Verification required	BABOK Guide, ISTQB CTFL, ISO/IEC/IEEE 29148 chỉ hỗ trợ thuật ngữ và cách làm. Chúng không tự tạo rule vận hành Nova Foods.
Ownership	Có Owner cho requirement, test evidence và quyết định ngoại lệ không?	Metadata artifact; vai trò ghi trong test case	Principal IT Business Analyst / Technical Curriculum Author chỉ quản trị artifact. Không thay Business Owner, QA, Architect, Legal Owner, Accounting Owner hoặc Security Owner xác nhận nội dung.
Bảo mật và riêng tư	Test data có chứa dữ liệu cá nhân thật, bí mật thật, token thật hoặc thông tin truy cập thật không?	Payload, dữ liệu test, phân loại dữ liệu	Chỉ dùng dữ liệu tổng hợp. Yêu cầu suy ra từ Luật 91/2025/QH15 hoặc Nghị định 356/2025/NĐ-CP phải gắn Verification required bởi Legal Owner. OWASP ASVS và OWASP API Security Top 10 là good practice, không phải luật Việt Nam.
Pháp lý, kế toán, hóa đơn	Expected result có khẳng định nghĩa vụ pháp lý, bút toán, thuế hoặc hóa đơn không?	Liên kết nguồn và nhãn thẩm quyền	Luật Kế toán, Nghị định 123/2020/NĐ-CP và nguồn pháp lý chỉ xác định bối cảnh cần kiểm tra. Diễn giải nghiệp vụ cần Accounting Owner và Legal Owner xác minh.
An toàn thực phẩm và truy xuất	Test case có biến ví dụ mô phỏng thành cam kết tuân thủ truy xuất hoặc thu hồi không?	Liên kết Luật An toàn thực phẩm; mô tả phạm vi	Luật 55/2010/QH12 chỉ là nguồn bối cảnh. Quy tắc traceability thực tế cần Domain Owner và Legal Owner xác minh.
Tác động thay đổi	Thay đổi rule, field, trạng thái hay API có chỉ ra test case, dữ liệu, evidence và artifact bị ảnh hưởng không?	Change record; liên kết ID; CANONICAL_DATA_DICTIONARY	Mọi thay đổi phải giữ lịch sử, version và traceability. IN_REVIEW tại v0.9.0 không phải baseline hoặc approval.

Áp dụng cho Nova Foods mô phỏng: Test design phải dùng dữ liệu tổng hợp và không được suy diễn cấu hình ERP production. Các liên kết tới TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY là bằng chứng kiểm soát dự kiến; cần xác minh rằng ID được tham chiếu tồn tại trong artifact canonical tương ứng. Nội dung liên quan dữ liệu cá nhân, kế toán, hóa đơn, pháp lý và an toàn thực phẩm giữ nhãn Verification required cho đến khi vai trò có thẩm quyền xác minh. Ghi nhận này là review trước baseline, không xác nhận phê duyệt.

Áp dụng Quality Gate cho Nova Foods mô phỏng

Quality Gate là điểm kiểm soát trước baseline: Senior BA đối chiếu hồ sơ kiểm thử đã hoàn thành với nguồn canonical, rồi ghi nhận PASS, FAIL hoặc STOP. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, không chứng minh cấu hình ERP, tuân thủ pháp lý hay sẵn sàng production.

Mục kiểm tra	Bằng chứng đã đối chiếu	Kết quả	Cầu nối suy luận và phát hiện	Hành động / escalation
Tính đầy đủ	/03-templates/TMPL-TST-001_TEST_DESIGN.md được kiểm soát bởi TEMPLATE_MANIFEST; trạng thái corpus IN_REVIEW, version v0.9.0, ngày 2026-08-07	PASS có điều kiện	Metadata quản trị phù hợp corpus. Nhưng IN_REVIEW không phải baseline. Hồ sơ chỉ đủ để review học liệu, không đủ để phát hành baseline.	Giữ trạng thái IN_REVIEW. Không gắn nhãn BASELINED hoặc APPROVED.
Tính nhất quán	TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY là nguồn canonical riêng	STOP	Mỗi nguồn quản lý một loại sự thật: ID, quy tắc, dữ liệu. Test Design không được tự thay thế hoặc sửa nghĩa các nguồn này. Nội dung Tier 3 phải liên kết đúng ID đã đăng ký; dữ liệu dependency hiện không cung cấp bản ghi Tier 3 để kiểm chứng từng liên kết.	Escalate Principal IT Business Analyst / Technical Curriculum Author để đối chiếu từng link Tier 3 với artifact canonical.
Khả năng kiểm thử	ISTQB CTFL Syllabus v4.0.1 là nguồn thuật ngữ kiểm thử	STOP	Test case chỉ kiểm được khi có điều kiện đầu vào, bước thực hiện, dữ liệu tổng hợp, kết quả mong đợi và tiêu chí pass/fail xác định. Không có nội dung Tier 3 cụ thể trong gói bằng chứng hiện tại để xác minh các trường này đã được điền.	Không tuyên bố test case executable. Yêu cầu cung cấp bản Tier 3 hoàn chỉnh để review.
Truy vết	TRACEABILITY_ID_REGISTRY quy định canonical identifier và escalation khi nguồn mâu thuẫn	STOP	Không được suy diễn ID requirement, rule, data hoặc test từ tên Nova Foods. Không có danh sách ID Tier 3 trong đầu vào hiện tại, nên không thể chứng minh chuỗi requirement–rule–data–test.	Lập gói đối chiếu traceability; escalation khi thiếu ID, ID không đăng ký, hoặc một test liên kết nhiều nguồn mâu thuẫn.
Thẩm quyền nguồn	CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều IN_REVIEW; nguồn pháp lý có safe-use boundary	PASS có điều kiện	Các artifact này là nguồn quản trị hợp lệ, nhưng chưa xác nhận quy tắc vận hành thực tế. Luật và chuẩn chỉ dùng trong ranh giới nguồn đã nêu.	Gắn Verification required cho mọi diễn giải pháp lý, kế toán, thuế, an toàn thực phẩm hoặc dữ liệu cá nhân.
Ownership	Owner được ghi nhận là Principal IT Business Analyst / Technical Curriculum Author	PASS có điều kiện	Owner duy trì artifact, version và traceability; Owner không có quyền legal, accounting, security, business approval hoặc production release.	Escalate đúng owner chuyên môn nếu test yêu cầu kết luận ngoài thẩm quyền Owner.
Bảo mật, riêng tư, pháp lý, kế toán	OWASP ASVS 5.0.0, OWASP API Security Top 10 2023, Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật Kế toán 88/2015/QH13	STOP	Các nguồn xác định ranh giới tham chiếu, không tự tạo yêu cầu Nova Foods. Không có payload, phân loại dữ liệu, quyền truy cập, dữ liệu kế toán hoặc xác nhận Legal/Accounting/Security trong bằng chứng hiện tại.	Escalate Security Owner cho quyền truy cập và API; Legal Owner cho dữ liệu cá nhân; Accounting Owner cho hạch toán, hóa đơn, chứng từ.
Tác động thay đổi	CHAPTER_MANIFEST và TEMPLATE_MANIFEST yêu cầu kiểm soát thay đổi, không sửa im lặng	PASS có điều kiện	Thay đổi test design có thể ảnh hưởng rule, data dictionary, traceability và học liệu. Không có baseline reference tại v0.9.0, nên không được mô tả đây là thay đổi sau baseline.	Ghi nhận thay đổi theo versioned history khi có nội dung thay đổi; đánh giá lại traceability trước lần review kế tiếp.

Kết luận review: STOP — EVIDENCE REQUIRED. Lý do: gói nguồn hiện tại xác nhận governance và ranh giới thẩm quyền, nhưng không chứa bản ghi Tier 3 hoàn chỉnh để xác minh từng test case, dữ liệu tổng hợp, expected result và traceability link. Kết luận này là phát hiện review, không phải phê duyệt, baseline, xác nhận compliance hoặc cho phép dùng production.

6. Cross-File Checks, Open Issues, and Escalation

Kiểm tra liên tệp nhằm xác nhận cùng một khái niệm chỉ có một nguồn canonical, tức nguồn chuẩn được ưu tiên khi có khác biệt. Phạm vi kiểm tra dưới đây chỉ đối chiếu tính nhất quán quản trị và traceability, tức khả năng lần từ test về rule, dữ liệu, ID và nguồn đầu vào. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Điểm đối chiếu	Artifact hoặc consumer	Kết quả	Bằng chứng và cầu nối suy luận	Quy tắc áp dụng cho /03-templates/TMPL-TST-001_TEST_DESIGN.md
Trạng thái, version, ngày, locale	/01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY	PASS	Các artifact được cung cấp cùng ghi IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, bối cảnh Việt Nam và VND. Vì metadata khớp, test design không có mâu thuẫn quản trị tại thời điểm kiểm tra.	Giữ nguyên IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND. Không dùng APPROVED, BASELINED, compliant hoặc production-ready.
Danh tính template	TEMPLATE_MANIFEST; /03-templates/TMPL-TST-001_TEST_DESIGN.md	CẦN XÁC MINH LIÊN KẾT MANIFEST	Tên tệp và ID TMPL-TST-001 được xác định bởi contract micro-batch. Phần trích TEMPLATE_MANIFEST không chứa dòng đăng ký template này, nên không có bằng chứng trực tiếp để xác nhận manifest đã đăng ký đúng ID, filename và consumer. Không được suy diễn đăng ký từ việc tệp được soạn.	Chỉ dùng TMPL-TST-001 và /03-templates/TMPL-TST-001_TEST_DESIGN.md đúng nguyên dạng. Không tạo biến thể như TST-001, TMPL_TEST_001 hoặc filename khác.
ID truy vết	TRACEABILITY_ID_REGISTRY	PASS có điều kiện	Registry là nguồn canonical cho identifier. Contract yêu cầu bảo toàn ID; dữ liệu nguồn hiện có không cung cấp ID Tier 3 test case, requirement, rule hoặc data element cụ thể để đối chiếu từng liên kết.	Mỗi liên kết đã tồn tại phải giữ nguyên ID canonical. Không tự tạo requirement ID, rule ID, data ID, API ID hoặc defect ID để lấp khoảng trống chứng cứ.
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	PASS có điều kiện	Catalog quy tắc xác định chính nó là nguồn canonical nhưng không cho phép Owner tự xác nhận quy tắc Nova Foods vận hành thực tế. Vì test case kiểm tra hành vi từ business rule, expected result không được thay thế hoặc mở rộng rule nguồn.	Test basis chỉ tham chiếu rule đã có ID canonical. Khi rule chưa có nội dung được xác minh, ghi trạng thái cần xác minh; không diễn đạt giả định thành expected result bắt buộc.
Dữ liệu kiểm thử	CANONICAL_DATA_DICTIONARY	PASS có điều kiện	Data dictionary là nguồn canonical cho tên, nghĩa và kiểm soát dữ liệu logic. Seed xác nhận ranh giới artifact nhưng không cung cấp field-level schema hoặc tập dữ liệu Tier 3. Do đó chưa thể xác nhận kiểu dữ liệu, bắt buộc, format hoặc phân loại dữ liệu cho từng test.	Chỉ dùng dữ liệu tổng hợp Nova Foods. Không suy diễn field, payload, phân loại dữ liệu cá nhân, retention, quyền truy cập hoặc cấu trúc ERP từ tên business object.
Chapter nguồn và consumer hạ nguồn	/01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/01_CURRICULUM_ARCHITECTURE.md	PASS có điều kiện	Architecture yêu cầu chuỗi requirement, acceptance criteria, traceability và test basis rõ ràng; manifest là nguồn kiểm soát chapter. Seed không cung cấp chapter entry hoặc consumer cụ thể của TMPL-TST-001. Vì vậy chỉ xác nhận được nguyên tắc chuỗi học, chưa xác nhận được từng dependency.	Không tự nhận test design đã nhận đủ requirement, acceptance criteria hoặc đã được consumer sử dụng. Giữ traceability link theo nguồn đã đăng ký khi nguồn đó được cung cấp.
Nguồn chuẩn testing	ISTQB CTFL Syllabus v4.0.1	PASS	ISTQB CTFL là nguồn chính cho thuật ngữ testing và kỹ thuật hộp đen. Nguồn hỗ trợ cách gọi test basis, test case và expected result; không cấp rule nghiệp vụ Nova Foods.	Dùng thuật ngữ testing theo ISTQB. Không gán ISTQB làm nguồn phê duyệt test, rule hoặc cấu hình ERP Nova Foods.
Pháp lý, kế toán, riêng tư, bảo mật	Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP, OWASP ASVS 5.0.0, OWASP API Security Top 10 2023	KHÔNG SUY DIỄN	Seed quy định các chi tiết chưa xác minh trực tiếp phải gắn nhãn project assumption hoặc Verification required. Các nguồn này không trao thẩm quyền cho curriculum Owner xác nhận tuân thủ.	Không ghi test result như xác nhận tuân thủ pháp lý, kế toán, hóa đơn, dữ liệu cá nhân, security hoặc production. Chỉ Legal Owner, Accounting Owner, Security Owner và vai trò có thẩm quyền mới xác nhận các kết luận đó.

Quy tắc chống mâu thuẫn: manifest kiểm soát danh mục và dependency; registry kiểm soát ID; CANONICAL_BUSINESS_RULES kiểm soát nghĩa quy tắc; CANONICAL_DATA_DICTIONARY kiểm soát nghĩa dữ liệu. Template này chỉ tổ chức test design. Khi cùng một nội dung khác nhau giữa template và nguồn canonical, nguồn canonical được ưu tiên; template phải được sửa theo lịch sử thay đổi có version, không sửa im lặng.

Kết quả kiểm tra: chưa phát hiện mâu thuẫn metadata trong tập bằng chứng được cung cấp. Có giới hạn chứng cứ cho đăng ký manifest của TMPL-TST-001, liên kết ID cấp bản ghi, rule cấp bản ghi, data field và consumer cụ thể. Giới hạn này không được chuyển thành nội dung giả định, approval, baseline hoặc kết luận vận hành.

Danh sách vấn đề mở, giả định dự án và mục cần xác minh

Bảng này là sổ theo dõi handoff có kiểm soát cho TMPL-TST-001. “Vấn đề mở” là điểm mâu thuẫn hoặc thiếu đầu vào ngăn kết luận test. “Giả định dự án” là điều tạm dùng để minh họa case mô phỏng, không phải quy tắc vận hành. “Cần xác minh” là nội dung có thể ảnh hưởng pháp lý, kế toán, an toàn thực phẩm, bảo mật hoặc cấu hình ERP; không được chuyển thành expected result bắt buộc trước khi vai trò có thẩm quyền xác nhận. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là dữ liệu tổng hợp.

ID theo dõi	Phân loại	Nội dung và cầu nối bằng chứng	ID/tệp bị ảnh hưởng	Owner xử lý	Tác động test	Hành động tiếp theo
OI-TST-001	Vấn đề mở	TMPL-TST-001 cần liên kết test case với requirement, business rule và acceptance criterion. TRACEABILITY_ID_REGISTRY là nguồn quản trị ID, nhưng đầu vào chưa cung cấp ID requirement, rule hoặc acceptance criterion Nova Foods đã được cấp. Không thể tự tạo ID rồi coi là canonical.	TMPL-TST-001; TRACEABILITY_ID_REGISTRY; /03-templates/TMPL-TST-001_TEST_DESIGN.md	Principal IT Business Analyst / Technical Curriculum Author	Test case chỉ được ghi test basis ở mức artifact; chưa chứng minh coverage mức requirement hoặc rule.	Đăng ký ID canonical trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; cập nhật traceability sau khi ID tồn tại.
OI-TST-002	Vấn đề mở	CANONICAL_BUSINESS_RULES đang là catalog kế hoạch IN_REVIEW; không có quy tắc Nova Foods đã được Business Owner xác nhận. Expected result không được diễn đạt như quyết định nghiệp vụ thật.	TMPL-TST-001; CANONICAL_BUSINESS_RULES; /01-curriculum/CANONICAL_BUSINESS_RULES.md	Business Owner; Principal IT Business Analyst / Technical Curriculum Author điều phối	Không thể kết luận pass/fail cho logic nghiệp vụ thực tế.	Business Owner xác định rule mô phỏng dùng cho bài học; BA ghi nguồn, trạng thái và liên kết registry.
PA-TST-001	Giả định dự án	Test design dùng locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Bằng chứng là metadata nhất quán của CHAPTER_MANIFEST, TEMPLATE_MANIFEST và TRACEABILITY_ID_REGISTRY. Đây chỉ là ngữ cảnh case, không xác nhận cấu hình ERP thật.	TMPL-TST-001; CHAPTER_MANIFEST; TEMPLATE_MANIFEST; TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	Dữ liệu test ngày giờ, số tiền và định dạng hiển thị phải theo ngữ cảnh này.	Giữ nhãn giả định trong test data; Architect xác nhận riêng nếu dùng cho thiết kế hệ thống thật.
VR-TST-001	Cần xác minh	Test liên quan dữ liệu cá nhân phải được Legal Owner và Security xác minh. Nguồn pháp lý có Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP, nhưng seed cấm tự suy diễn requirement hệ thống từ luật.	TMPL-TST-001; 00_SOURCE_MAP; CANONICAL_DATA_DICTIONARY	Legal Owner; Security Owner	Không được gắn nhãn compliant, không được tạo expected result pháp lý, không dùng dữ liệu cá nhân thật.	Legal Owner xác minh nghĩa vụ áp dụng; Security Owner xác định test control; chỉ dùng dữ liệu tổng hợp sau khi cập nhật artifact canonical.
VR-TST-002	Cần xác minh	Test hóa đơn, kế toán, thuế hoặc chứng từ không được suy ra từ Luật 88/2015/QH13 hay Nghị định 123/2020/NĐ-CP. Seed nêu rõ diễn giải cần Accounting Owner hoặc Legal Owner và cần kiểm tra sửa đổi trước production.	TMPL-TST-001; 00_SOURCE_MAP; CANONICAL_BUSINESS_RULES	Accounting Owner; Legal Owner	Không được dùng kết quả test để xác nhận tuân thủ kế toán, thuế hoặc hóa đơn.	Accounting Owner xác định rule mô phỏng; Legal Owner xác minh nguồn hiện hành; BA cập nhật liên kết test basis.
VR-TST-003	Cần xác minh	Test truy xuất nguồn gốc, thu hồi hoặc an toàn thực phẩm cần xác minh chuyên môn. Luật 55/2010/QH12 chỉ là ngữ cảnh nguồn; seed yêu cầu domain-owner và legal verification.	TMPL-TST-001; 00_SOURCE_MAP; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Food Safety Domain Owner; Legal Owner	Không được khẳng định luồng test đáp ứng yêu cầu an toàn thực phẩm thật.	Domain Owner xác định dữ liệu, trạng thái và tiêu chí mô phỏng; Legal Owner xác minh ranh giới pháp lý.
PA-TST-002	Giả định dự án	IN_REVIEW, v0.9.0, ngày 2026-08-07 là trạng thái quản trị chung. Bằng chứng: metadata upstream nhất quán. IN_REVIEW không phải APPROVED, BASELINED, production-ready hoặc user-approved.	TMPL-TST-001; CHAPTER_MANIFEST; TEMPLATE_MANIFEST; TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	Handoff chỉ chuyển bản đang review; không mở quyền release, triển khai hoặc kết luận chất lượng cuối.	Giữ nguyên status và version; mọi sửa đổi phải có lịch sử thay đổi trong artifact kiểm soát.

Bàn giao cuối và quy tắc lan truyền thay đổi

Bàn giao có kiểm soát nghĩa là chuyển bản ghi để vai trò kế tiếp xem xét, không chuyển quyền quyết định. TMPL-TST-001 tại /03-templates/TMPL-TST-001_TEST_DESIGN.md giữ IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là dữ liệu tổng hợp. Bàn giao không tạo BASELINED, APPROVED, xác nhận tuân thủ, xác nhận yêu cầu nghiệp vụ, hay quyền dùng production.

Bên nhận bàn giao	Nhận gì	Được làm	Không được làm
QA Reviewer	Test design, liên kết test basis, bằng chứng review	Kiểm tra tính kiểm thử được và truy vết	Tự phê duyệt rule, baseline hoặc thay Business Owner
Business Owner	Câu hỏi về mục tiêu, tiêu chí chấp nhận, ngoại lệ nghiệp vụ	Xác nhận ý nghĩa nghiệp vụ khi có thẩm quyền	Diễn giải pháp lý, bảo mật, kế toán
Technical Architect	Nội dung ảnh hưởng tích hợp, API, dữ liệu, kiến trúc	Đánh giá khả thi kỹ thuật	Tự đổi business rule hoặc cấp approval nghiệp vụ
Legal, Accounting, Compliance Owner	Nội dung có thể mang nghĩa vụ pháp lý, kế toán, riêng tư, hóa đơn, an toàn thực phẩm	Xác minh theo nguồn chính thức và thẩm quyền chuyên môn	Gọi dữ liệu mô phỏng là cấu hình hay tuân thủ thực tế
Principal IT Business Analyst / Technical Curriculum Author	Gói thay đổi và liên kết traceability	Cập nhật artifact, lịch sử thay đổi, liên kết	Tự cấp baseline, approval, legal sign-off, production approval

Khi thay đổi một test case, test data, expected result, test basis hoặc liên kết truy vết trong TMPL-TST-001, người đề xuất phải lập gói thay đổi chứa: nội dung trước và sau, lý do, ID bị ảnh hưởng, artifact nguồn, artifact nhận ảnh hưởng, owner xem xét, và ngày theo Asia/Ho_Chi_Minh. Không sửa im lặng. Nếu thay đổi làm khác định danh, quy tắc hoặc dữ liệu canonical, nguồn sự thật vẫn là /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md hoặc /01-curriculum/CANONICAL_DATA_DICTIONARY.md; template chỉ phản ánh thay đổi sau khi nguồn canonical được cập nhật đúng thẩm quyền.

Loại thay đổi	Phải lan truyền đến	Điều kiện bàn giao tiếp
Đổi ID hoặc quan hệ traceability	TRACEABILITY_ID_REGISTRY, các liên kết trong TMPL-TST-001	Registry giữ ID canonical, không trùng, không đổi nghĩa im lặng
Đổi business rule hoặc acceptance criterion	CANONICAL_BUSINESS_RULES, test design liên quan	Business Owner xem xét ý nghĩa; Legal, Accounting, Compliance Owner tham gia nếu thuộc phạm vi họ
Đổi tên trường, kiểu dữ liệu, giá trị hợp lệ, dữ liệu test	CANONICAL_DATA_DICTIONARY, test data và expected result liên quan	Data owner hoặc Architect xác minh tác động logic
Đổi cấu trúc, phạm vi hoặc filename template	/01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/CHAPTER_MANIFEST.md khi có liên kết chapter	Manifest giữ nguyên phân loại và đường dẫn canonical
Đổi yêu cầu API, bảo mật hoặc khả năng truy cập	Artifact kỹ thuật và test liên quan	Architect, Security hoặc accessibility reviewer xác minh trong ranh giới chuyên môn

Quy tắc dừng: không bàn giao như nội dung sẵn sàng dùng nếu thay đổi cần quyết định từ hai thẩm quyền trở lên, nếu nguồn canonical mâu thuẫn, hoặc nếu thay đổi bị diễn đạt thành nghĩa vụ pháp lý, kế toán, bảo mật hay vận hành thực tế. Khi dừng, giữ nguyên IN_REVIEW, ghi liên kết tới nguồn và chuyển gói thay đổi cho owner có thẩm quyền. TMPL-TST-001 chỉ được gọi là baseline hoặc approved khi artifact kiểm soát có tham chiếu baseline hoặc approval minh bạch; tại v0.9.0 chưa có tham chiếu đó.