Tmpl Tst 003 Defect Log

1. Tier 1 ? Metadata, Purpose, and Governance

Metadata quản trị artifact

Trường kiểm soát	Giá trị kiểm soát
Artifact ID	TMPL-TST-003
Tên tệp được kiểm soát	/03-templates/TMPL-TST-003_DEFECT_LOG.md
Tiêu đề artifact	Tmpl Tst 003 Defect Log
Phân loại artifact	Controlled four-tier template; mẫu kiểm soát bốn tầng cho Defect Log, tức nhật ký lỗi dùng ghi nhận, theo dõi và truy vết lỗi kiểm thử
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 quốc gia	Việt Nam
Đơn vị tiền tệ case study	VND; chỉ dùng cho dữ liệu mô phỏng khi trường dữ liệu lỗi cần thể hiện giá trị tiền tệ
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục
Phân loại dữ liệu Nova Foods	Chỉ dữ liệu tổng hợp. Tên người, mã giao dịch, số tiền, ngày giờ, lỗi, bằng chứng và quyết định trong artifact này không đại diện dữ liệu, cấu hình, sự cố hoặc vận hành của doanh nghiệp thật.
Trạng thái baseline	Chưa có baseline reference tại v0.9.0. IN_REVIEW không đồng nghĩa BASELINED.
Trạng thái phê duyệt	Chưa có approval reference tại v0.9.0. Metadata, việc gán Owner, nội dung mẫu hoặc dữ liệu case không tạo phê duyệt ngầm định.
Giới hạn sử dụng	Artifact là học liệu kiểm soát. Không phải nhật ký lỗi production, hồ sơ pháp lý, bằng chứng tuân thủ, cam kết xử lý sự cố, xác nhận chất lượng, hoặc chỉ dẫn triển khai ERP thực tế.

Owner duy trì đúng TMPL-TST-003, đường dẫn /03-templates/TMPL-TST-003_DEFECT_LOG.md, trạng thái, phiên bản, ngày cập nhật và lịch sử thay đổi. Owner không có thẩm quyền tự xác lập baseline, ghi nhận approval, xác nhận lỗi Nova Foods là lỗi thật, quyết định phát hành production, hoặc thay thế kết luận của Business Owner, QA Owner, Architect, Security Owner, Legal Owner hay Accounting Owner.

Lịch sử thay đổi

Version	Ngày	Người ghi nhận	Thay đổi kiểm soát	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-003; xác lập artifact là controlled four-tier template, trạng thái IN_REVIEW, bối cảnh vi-VN, Asia/Ho_Chi_Minh, VND, và ranh giới dữ liệu tổng hợp Nova Foods.	IN_REVIEW

Ranh giới dữ liệu mô phỏng

Nova Foods Trading & Manufacturing trong corpus này là case study mô phỏng giáo dục. Mọi record lỗi về sau phải dùng dữ liệu tổng hợp và phải được đọc như ví dụ học tập. Suy luận này dựa trên phân loại case study và dữ liệu trong metadata: không có nguồn nào xác nhận Nova Foods là doanh nghiệp thật, có ERP thật, có lỗi thật, hoặc đã áp dụng quy trình trong template này.

Không được đưa vào artifact này dữ liệu cá nhân thật, thông tin khách hàng thật, bí mật thương mại, log production, ảnh chụp màn hình hệ thống thật, hóa đơn thật, token, mật khẩu, khóa truy cập hoặc bằng chứng có thể nhận diện tổ chức thật. Nếu cần minh họa dữ liệu nhạy cảm, phải tạo dữ liệu tổng hợp mới và giữ rõ nhãn mô phỏng; không được biến dữ liệu mô phỏng thành tuyên bố tuân thủ pháp lý, kế toán, an toàn thực phẩm, bảo mật hoặc vận hành.

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

Mục đích. TMPL-TST-003_DEFECT_LOG là mẫu nhật ký lỗi (defect log: sổ ghi nhận, phân loại, theo dõi và đóng lỗi kiểm thử) cho Nova Foods Trading & Manufacturing, case study mô phỏng giáo dục. Mẫu tạo một bản ghi có thể truy vết từ lỗi quan sát được đến bằng chứng kiểm thử, test case, yêu cầu, quy tắc nghiệp vụ hoặc dữ liệu liên quan. Lý do: lỗi không có bằng chứng, bước tái hiện và liên kết nguồn không đủ cơ sở để QA, BA hoặc đội kỹ thuật đánh giá tác động. Mọi tên, ID nghiệp vụ, dữ liệu, số tiền VND, người dùng và môi trường trong mẫu là dữ liệu tổng hợp; không mô tả ERP thực, khách hàng thật hoặc sự cố production.

Nội dung	Quy định áp dụng
Dùng khi	Tester phát hiện kết quả thực tế khác kết quả mong đợi trong thực thi test case; phát hiện lỗi dữ liệu, giao diện, tích hợp, phân quyền, hiệu năng hoặc khả năng truy cập; hoặc cần theo dõi quyết định triage (phân loại và ưu tiên xử lý lỗi).
Không dùng khi	Chưa có hành vi quan sát được hoặc bằng chứng kiểm thử; đây là yêu cầu mới, thay đổi phạm vi, câu hỏi nghiệp vụ, rủi ro dự án, sự cố production, hoặc kết luận pháp lý/kế toán/an toàn thực phẩm. Dùng artifact chuyên biệt của các luồng đó, không đổi loại vấn đề để tạo defect.
Điều kiện tối thiểu	Có test basis (cơ sở kiểm thử: nguồn xác định kết quả mong đợi), test case hoặc bước kiểm tra xác định; môi trường kiểm thử; dữ liệu tổng hợp; bước tái hiện; kết quả thực tế; kết quả mong đợi; bằng chứng an toàn để chia sẻ; người ghi nhận; thời điểm theo Asia/Ho_Chi_Minh.
Đầu ra hạ nguồn	Bản ghi dùng làm đầu vào cho triage, quyết định sửa lỗi, retest (kiểm thử lại bản sửa), regression test (kiểm thử hồi quy: kiểm tra phần không đổi sau sửa), báo cáo chất lượng và liên kết truy vết kiểm thử. Không tự tạo quyết định release hoặc cho phép triển khai production.

Owner và người dùng. Owner là Principal IT Business Analyst / Technical Curriculum Author. Owner duy trì cấu trúc mẫu, định danh, trạng thái, phiên bản và liên kết corpus; Owner không xác nhận lỗi là hợp lệ cho vận hành thực, không tự đặt ưu tiên phát hành, không phê duyệt baseline, không phê duyệt nội dung, không quyết định cấu hình ERP production. Người dùng chính gồm Tester ghi lỗi và bằng chứng; QA Lead điều phối triage; Business Analyst kiểm tra liên kết yêu cầu, acceptance criteria (tiêu chí chấp nhận) và quy tắc; Developer hoặc Technical Lead phân tích nguyên nhân và bản sửa; Business Owner xác nhận tác động nghiệp vụ khi cần. Mỗi vai trò chỉ ghi quyết định thuộc thẩm quyền mình.

Ranh giới quyết định. Một bản ghi được tạo khi có sai khác kiểm chứng được giữa expected result và actual result. Ví dụ, test case mong đợi hệ thống chặn giá trị bắt buộc nhưng màn hình lưu dữ liệu tổng hợp thiếu trường đó: đây là defect vì có điều kiện, hành vi quan sát và kết quả mong đợi để đối chiếu. Ngược lại, đề nghị thêm trường mới không là defect nếu nguồn hiện có không yêu cầu trường đó; chuyển đề nghị sang quản lý yêu cầu/thay đổi phạm vi. Khi test basis mâu thuẫn, giữ lỗi ở trạng thái cần triage và liên kết cả hai nguồn; không tự chọn nguồn đúng.

Thẩm quyền và escalation. Escalation (chuyển vấn đề đến vai trò có thẩm quyền) bắt buộc khi lỗi có thể liên quan dữ liệu cá nhân, bảo mật, truy cập trái phép, tính toàn vẹn dữ liệu, kế toán, thuế, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc, hoặc nguy cơ production. Bằng chứng: các chủ đề này vượt thẩm quyền template owner và có nguồn pháp lý/chuyên môn riêng trong corpus. Chuyển Legal/Compliance Owner cho diễn giải pháp lý; Accounting Owner cho kế toán, thuế hoặc hóa đơn; Security Owner cho bảo mật; Food Safety/Domain Owner cho an toàn thực phẩm và truy xuất; Architect hoặc Technical Lead cho kiến trúc và tích hợp; QA Lead cho mức độ nghiêm trọng, ưu tiên và quyết định kiểm thử. Ghi nhận việc escalation cùng ID defect và lý do; không ghi kết luận chuyên môn thay vai trò nhận escalation.

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

TMPL-TST-003 là định danh canonical của template Defect Log; tệp kiểm soát tương ứng là /03-templates/TMPL-TST-003_DEFECT_LOG.md. Dùng nguyên chuỗi ID và đường dẫn này trong mọi liên kết, nhật ký thay đổi, bằng chứng kiểm thử và kiểm tra chéo. Không đổi thành DEFECT_LOG, TST-003 hoặc tên dịch tiếng Việt, vì biến thể làm đứt truy vết giữa template, manifest và artifact đầu ra.

Hạng mục liên kết	Giá trị canonical	Vai trò kiểm soát	Bằng chứng suy luận
Manifest template	TEMPLATE_MANIFEST	Nguồn danh mục, phạm vi và trạng thái kế hoạch của template	Manifest quản lý template dự kiến; template không tự tạo danh tính ngoài manifest.
Định danh template	TMPL-TST-003	Khóa truy vết duy nhất cho Defect Log	Tiền tố TMPL xác định template; TST xác định miền testing; số 003 phân biệt artifact trong miền này.
Tệp kiểm soát	/03-templates/TMPL-TST-003_DEFECT_LOG.md	Vị trí canonical của nội dung template	Tên tệp được yêu cầu khớp ID TMPL-TST-003 và chức năng DEFECT_LOG.
Manifest chapter	CHAPTER_MANIFEST	Nguồn kiểm soát cấu trúc 26 handbook chapter	Chapter manifest là authoritative manifest cho chapter; template chỉ tham chiếu, không sửa chapter identity.
Registry truy vết	TRACEABILITY_ID_REGISTRY	Nguồn kiểm tra cấu trúc và tính duy nhất của ID liên kết	Registry quy định artifact khác phải giữ nguyên ID canonical khi liên kết.
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	Nguồn canonical khi defect liên quan business rule	Defect Log ghi nhận tham chiếu rule; không tự tạo hoặc phê chuẩn rule.
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY	Nguồn canonical khi defect liên quan trường dữ liệu, giá trị hoặc ràng buộc dữ liệu	Defect Log ghi nhận tham chiếu dữ liệu; không thay thế data dictionary.

Template này phục vụ chapter testing theo cấu trúc đã đăng ký trong CHAPTER_MANIFEST. Liên kết chapter phải dùng ID và tên chapter đúng như manifest tại thời điểm kiểm tra. Nếu manifest chưa cung cấp liên kết chapter cụ thể cho TMPL-TST-003, ghi nhận khoảng trống truy vết để review; không tự gán chapter, không suy diễn dependency và không biến Defect Log thành nguồn chân lý mới.

Nguồn phương pháp kiểm thử được phân loại primary testing source: ISTQB CTFL Syllabus v4.0.1 tại 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ữ defect, test basis và bằng chứng kiểm thử. Không ghi số trang, điều khoản hoặc diễn giải ngoài nội dung đã xác minh. BABOK Guide Version 3 là nguồn terminology cho phân tích nghiệp vụ; không dùng để tuyên bố yêu cầu kiểm thử là quy định pháp lý hoặc cấu hình ERP.

Mọi thay đổi làm đổi ID, filename, liên kết manifest, trường traceability, cách phân loại defect hoặc ranh giới nguồn phải được ghi trong change history của artifact và đối chiếu với TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY và CHAPTER_MANIFEST. Không sửa im lặng. IN_REVIEW và v0.9.0 không phải baseline, approval hay quyền dùng production. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi ví dụ defect, dữ liệu, người dùng, giao dịch và bằng chứng trong template chỉ dùng dữ liệu tổng hợp.

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

Sao chép toàn bộ mẫu dưới đây cho mỗi defect (lỗi). Thay mọi giá trị trong dấu ngoặc nhọn bằng dữ liệu cụ thể. Nova Foods Trading & Manufacturing chỉ là case study mô phỏng giáo dục; chỉ nhập dữ liệu tổng hợp.

2.1. Hồ sơ defect

Trường	Giá trị cần điền
Artifact ID	TMPL-TST-003
Defect ID	<ID defect canonical, ví dụ theo registry đã đăng ký>
Tiêu đề defect	<Mô tả ngắn lỗi, nêu chức năng và hành vi sai>
Trạng thái artifact	IN_REVIEW
Phiên bản artifact	v0.9.0
Ngày ghi nhận	<YYYY-MM-DD theo Asia/Ho_Chi_Minh>
Người ghi nhận	<Vai trò hoặc tên tổng hợp của người tạo defect>
Hệ thống/phạm vi	<Phân hệ ERP hoặc chức năng bị ảnh hưởng>
Môi trường kiểm thử	<Tên môi trường mô phỏng, phiên bản build hoặc release>
Loại defect	<Functional hoặc Data hoặc Integration hoặc Security hoặc Accessibility hoặc Performance hoặc Other>
Tóm tắt tác động	<Ai hoặc quy trình nào bị ảnh hưởng; kết quả nghiệp vụ hoặc kỹ thuật>
Phân loại dữ liệu	<Không có dữ liệu cá nhân hoặc Dữ liệu tổng hợp hoặc Verification required>
Tham chiếu bí mật	<Secret reference an toàn, ví dụ vault path hoặc ticket ID; không ghi mật khẩu, token, khóa API hoặc dữ liệu xác thực>

2.2. Mô tả lỗi và điều kiện tái hiện

Mục tiêu kiểm thử: <Mục tiêu nghiệp vụ hoặc kỹ thuật mà ca kiểm thử xác minh>.

Điều kiện trước: <Dữ liệu tổng hợp, quyền truy cập mô phỏng, cấu hình hoặc trạng thái giao dịch cần có trước khi chạy>.

Bước	Thao tác người kiểm thử	Dữ liệu đầu vào tổng hợp	Kết quả mong đợi
1	<Thao tác khởi đầu>	<Dữ liệu tổng hợp hoặc N/A>	<Kết quả đúng theo test basis>
2	<Thao tác tiếp theo>	<Dữ liệu tổng hợp hoặc N/A>	<Kết quả đúng theo test basis>
3	<Thao tác tạo lỗi>	<Dữ liệu tổng hợp hoặc N/A>	<Kết quả đúng theo test basis>
4	<Thao tác xác nhận lỗi hoặc N/A nếu lỗi đã xuất hiện ở bước 3>	<Dữ liệu tổng hợp hoặc N/A>	<Kết quả đúng theo test basis>

Kết quả thực tế: <Hành vi quan sát được, thông báo lỗi, giá trị hiển thị hoặc kết quả xử lý sai>.

Tần suất tái hiện: <Luôn tái hiện hoặc Không ổn định hoặc Chưa tái hiện lại>.

Phạm vi không bị ảnh hưởng: <Chức năng, vai trò, dữ liệu hoặc môi trường đã kiểm tra và không có lỗi; ghi “Chưa kiểm tra” nếu chưa có bằng chứng>.

2.3. Phân loại, quyết định và ngoại lệ

Trường quyết định	Giá trị cần điền
Severity (mức độ nghiêm trọng)	<Blocker hoặc Critical hoặc Major hoặc Minor hoặc Trivial>
Priority (độ ưu tiên xử lý)	<P1 hoặc P2 hoặc P3 hoặc P4>
Quyết định xử lý	<Fix required hoặc Defer proposed hoặc Duplicate proposed hoặc Cannot reproduce proposed hoặc Rejected proposed>
Cơ sở quyết định	<Bằng chứng nối tác động, kết quả thực tế và test basis>
Owner xử lý đề xuất	<Vai trò hoặc nhóm chịu trách nhiệm đề xuất>
Phiên bản dự kiến sửa	<Release hoặc build dự kiến, hoặc Chưa xác định>
Ngoại lệ/điều kiện đặc biệt	<Không có hoặc mô tả điều kiện khiến lỗi chỉ xuất hiện trong phạm vi cụ thể>
Escalation cần thiết	<Không hoặc Có: nêu vai trò cần xem xét và lý do>

2.4. Bằng chứng và truy vết

Loại liên kết	Tham chiếu cần điền	Mô tả sử dụng
Test case	<ID test case canonical>	<Ca kiểm thử phát hiện defect>
Test run	<ID lần chạy kiểm thử hoặc tham chiếu thực thi>	<Thời điểm và kết quả chạy>
Requirement	<ID requirement canonical hoặc Verification required>	<Yêu cầu làm test basis>
Business rule	<ID rule từ CANONICAL_BUSINESS_RULES hoặc Verification required>	<Quy tắc liên quan>
Data element	<ID hoặc tên trường từ CANONICAL_DATA_DICTIONARY hoặc Verification required>	<Dữ liệu liên quan>
Evidence file	<Tên tệp, URL nội bộ an toàn hoặc ID evidence>	<Ảnh chụp, log đã che bí mật hoặc payload tổng hợp>
Source classification	<Primary source hoặc Canonical internal source hoặc Project assumption hoặc Verification required>	<Nguồn của nhận định>
Liên kết defect liên quan	<Defect ID canonical hoặc Không có>	<Duplicate, blocker, regression hoặc dependency>

2.5. Khắc phục, kiểm tra lại và đóng đề xuất

Trường	Giá trị cần điền
Mô tả bản sửa nhận được	<Thay đổi được nhóm xử lý báo cáo; không suy diễn nếu chưa có bằng chứng>
Build/release kiểm tra lại	<Phiên bản build hoặc release>
Người kiểm tra lại	<Vai trò hoặc tên tổng hợp>
Ngày kiểm tra lại	<YYYY-MM-DD theo Asia/Ho_Chi_Minh>
Kết quả kiểm tra lại	<Pass hoặc Fail hoặc Blocked hoặc Not run>
Bằng chứng kiểm tra lại	<ID evidence, tên tệp hoặc URL nội bộ an toàn>
Regression impact	<Không phát hiện hoặc Có: nêu phạm vi và defect liên quan hoặc Chưa kiểm tra>
Trạng thái defect sau kiểm tra	<Open hoặc In Progress hoặc Resolved proposed hoặc Closed proposed hoặc Reopened proposed>
Lý do trạng thái	<Kết quả kiểm tra và bằng chứng hỗ trợ>

2.6. Review, sign-off và lịch sử thay đổi

Vai trò review	Người/nhóm tổng hợp	Ngày	Kết quả	Nhận xét hoặc tham chiếu
Người ghi nhận defect	<Tên hoặc vai trò>	<YYYY-MM-DD>	<Submitted>	<Tham chiếu hồ sơ defect>
QA/Test Lead	<Tên hoặc vai trò>	<YYYY-MM-DD hoặc Chưa thực hiện>	<Reviewed hoặc Rework requested hoặc Chưa review>	<Lý do và evidence>
Business Analyst	<Tên hoặc vai trò>	<YYYY-MM-DD hoặc Chưa thực hiện>	<Reviewed hoặc Verification required hoặc Chưa review>	<Liên kết requirement hoặc rule>
Owner xử lý	<Tên hoặc nhóm>	<YYYY-MM-DD hoặc Chưa thực hiện>	<Acknowledged hoặc Disputed hoặc Chưa phản hồi>	<Lý do và tham chiếu kỹ thuật>
Người có thẩm quyền đóng	<Vai trò phù hợp hoặc Chưa chỉ định>	<YYYY-MM-DD hoặc Chưa thực hiện>	<Không ghi approval ngầm định>	<Điều kiện đóng còn thiếu hoặc evidence đóng>

Phiên bản bản ghi	Ngày	Người cập nhật	Thay đổi	Lý do
<Phiên bản defect record>	<YYYY-MM-DD>	<Tên hoặc vai trò>	<Nội dung thay đổi>	<Lý do, evidence hoặc liên kết review>

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

Dùng một bản ghi cho một lỗi (defect: sai khác quan sát được giữa kết quả thực tế và kết quả mong đợi). Mọi giá trị trong dấu ngoặc nhọn phải được thay bằng dữ liệu kiểm chứng được. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp.

Nhóm	Trường	Giá trị cần điền
Định danh	Defect ID	<ID lỗi duy nhất theo TRACEABILITY_ID_REGISTRY; không tự tạo ID ngoài registry>
Định danh	Tiêu đề lỗi	<mô tả ngắn: chức năng + điều kiện + sai khác>
Định danh	Loại lỗi	<Functional|Data|Integration|Security|Performance|Accessibility|Usability|Documentation|Other>
Định danh	Module ERP	<tên module bị ảnh hưởng>
Định danh	Môi trường	<DEV|SIT|UAT|TRAINING; không ghi Production nếu không có bằng chứng được phép>
Định danh	Người ghi nhận	<họ tên hoặc mã vai trò mô phỏng>
Định danh	Thời điểm ghi nhận	<YYYY-MM-DD HH:mm ICT, Asia/Ho_Chi_Minh>
Phân loại	Severity	<Critical|High|Medium|Low>
Phân loại	Priority	<P1|P2|P3|P4>
Phân loại	Trạng thái	<New|Triaged|In Progress|Ready for Retest|Retest Failed|Closed|Rejected|Duplicate|Deferred>
Phân loại	Quyết định triage	<Fix now|Fix later|Reject|Duplicate|Defer>
Phân loại	Lý do quyết định	<bằng chứng tác động, phạm vi và người có thẩm quyền quyết định>
Phân loại	Owner xử lý	<vai trò hoặc nhóm chịu trách nhiệm; không suy diễn cá nhân chịu trách nhiệm>
Phạm vi	Quy trình bị ảnh hưởng	<tên quy trình hoặc use case canonical>
Phạm vi	Đối tượng dữ liệu bị ảnh hưởng	<entity, trường dữ liệu, giao dịch hoặc báo cáo>
Phạm vi	Tác động nghiệp vụ	<mô tả hậu quả quan sát được; không khẳng định thiệt hại nếu chưa đo>
Phạm vi	Tác động pháp lý/compliance	<Không xác định|Không áp dụng|Verification required; nêu lý do và owner cần xác minh>
Phạm vi	Tác động bảo mật	<Không xác định|Không áp dụng|Có; nêu loại dữ liệu, quyền truy cập và Security owner>
Kết quả	Điều kiện tiền đề	<dữ liệu, quyền, cấu hình và trạng thái cần có trước khi tái hiện>
Kết quả	Bước tái hiện	<bước 1; bước 2; bước 3; mỗi bước có hành động cụ thể>
Kết quả	Kết quả thực tế	<kết quả quan sát được, gồm thông báo lỗi nếu có>
Kết quả	Kết quả mong đợi	<kết quả dựa trên requirement, business rule hoặc acceptance criteria đã liên kết>
Kết quả	Khả năng tái hiện	<Always|Intermittent|Once|Not reproducible>
Kết quả	Tần suất/điều kiện lỗi	<số lần trên số lượt kiểm tra, hoặc điều kiện gây lỗi>

Bằng chứng	Giá trị cần điền	Quy tắc kiểm soát
Evidence ID	<ID bằng chứng theo TRACEABILITY_ID_REGISTRY>	Một bằng chứng một dòng; không gộp tệp không liên quan.
Loại bằng chứng	<Screenshot|Video|API request/response|Log|SQL result|Report export|Test data|Other>	Không ghi bí mật vào log hoặc ảnh chụp.
Vị trí lưu	<đường dẫn repository hoặc URL nội bộ được kiểm soát>	Phải truy cập được bởi reviewer có thẩm quyền.
Mô tả liên quan	<bằng chứng chứng minh bước nào, actual result nào>	Nêu cầu nối từ bằng chứng đến kết luận.
Phân loại dữ liệu	<Public|Internal|Confidential|Restricted|Verification required>	Chọn theo quy tắc phân loại dự án.
Tham chiếu bí mật an toàn	<secret-manager://tên-khoản-mục hoặc vault reference>	Không ghi mật khẩu, API key, token, cookie, chuỗi kết nối hoặc dữ liệu cá nhân thật.

Ngoại lệ và quyết định	Giá trị cần điền	Điều kiện dùng
Có ngoại lệ kiểm thử	<Có|Không>	Chọn Có khi không thể chạy đủ bước hoặc dữ liệu chuẩn.
Mô tả ngoại lệ	<lý do, phần không kiểm, rủi ro còn lại>	Bắt buộc khi chọn Có.
Biện pháp thay thế	<kiểm tra thủ công, dữ liệu thay thế hoặc môi trường thay thế>	Bắt buộc khi có ngoại lệ.
Chấp nhận rủi ro	<Không có|Verification required>	Không ghi là đã chấp nhận nếu chưa có tham chiếu quyết định có thẩm quyền.
Escalation cần thiết	<Có|Không>	Chọn Có khi liên quan bảo mật, pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc xung đột nguồn canonical.
Đích escalation	<Business Owner|QA Lead|Architect|Security Owner|Legal Owner|Accounting Owner|Compliance Owner>	Bắt buộc khi chọn Có.

Truy vết	ID/đường dẫn cần điền	Vai trò liên kết
Requirement	<REQ-ID hoặc Verification required>	Nguồn nhu cầu kiểm thử.
Business rule	<BR-ID từ CANONICAL_BUSINESS_RULES hoặc Không áp dụng>	Cơ sở xác định expected result.
Acceptance criterion	<AC-ID hoặc Verification required>	Tiêu chí đạt/không đạt.
Test case	<TC-ID>	Ca kiểm thử phát hiện hoặc xác nhận lỗi.
Test run	<TR-ID hoặc đường dẫn bằng chứng>	Lần chạy tạo actual result.
Data dictionary	<tham chiếu CANONICAL_DATA_DICTIONARY hoặc Không áp dụng>	Cơ sở cho lỗi dữ liệu.
API/specification	<OAS operationId, endpoint hoặc Không áp dụng>	Dùng cho lỗi tích hợp/API.
Source artifact	</đường/dẫn/tệp.md#heading>	Giữ boundary nguồn; không thay nguồn bằng suy diễn.
Related defect	<DEF-ID hoặc Không có>	Dùng khi lỗi trùng, nguyên nhân chung hoặc phụ thuộc.

Kiểm tra và đóng lỗi	Giá trị cần điền	Quy tắc xác nhận
Root cause reference	<liên kết phân tích nguyên nhân hoặc Verification required>	Không ghi nguyên nhân như sự thật nếu chưa có phân tích.
Fix reference	<build, change request, commit hoặc deployment reference>	Không chứa secret.
Retest result	<Pass|Fail|Blocked|Not run>	Closed chỉ hợp lệ khi là Pass.
Regression result	<Pass|Fail|Not applicable|Verification required>	Nêu phạm vi regression đã chạy.
Closure rationale	<bằng chứng fix đáp ứng expected result và không gây regression đã kiểm>	Bắt buộc khi Closed.
Closure date/time	<YYYY-MM-DD HH:mm ICT, Asia/Ho_Chi_Minh>	Bắt buộc khi Closed, Rejected, Duplicate hoặc Deferred.

Versioning, review và sign-off	Giá trị cần điền	Quy tắc kiểm soát
Defect record version	<v0.0.0>	Tăng version khi sửa nội dung kiểm soát.
Record status	IN_REVIEW	Không đổi thành baseline hoặc approved nếu không có tham chiếu hợp lệ.
Change date/time	<YYYY-MM-DD HH:mm ICT, Asia/Ho_Chi_Minh>	Ghi mỗi lần thay đổi đáng kể.
Change author	<vai trò hoặc định danh mô phỏng>	Người cập nhật không tự tạo approval.
Change summary	<trường đã đổi, lý do, bằng chứng liên quan>	Không sửa im lặng.
Reviewer	<QA Lead|Senior BA|Technical Lead|Security Owner|vai trò phù hợp>	Reviewer phải phù hợp loại lỗi.
Review outcome	<Accepted for next action|Changes requested|Escalated|Not reviewed>	Không đồng nghĩa phê duyệt nghiệp vụ.
Review evidence	<review comment ID hoặc đường dẫn>	Bắt buộc khi có review outcome khác Not reviewed.
Sign-off role	<Business Owner|QA Lead|Security Owner|Legal Owner|Accounting Owner|Không áp dụng>	Chỉ điền khi quy trình dự án yêu cầu.
Sign-off reference	<quyết định được kiểm soát hoặc Verification required>	Trống không được diễn giải là đã sign-off.

2.1 Hướng dẫn trường, giá trị hợp lệ và điều kiện áp dụng

Dùng mẫu này để ghi nhận defect (lỗi): chênh lệch có thể kiểm chứng giữa kết quả thực tế và yêu cầu, quy tắc, tiêu chí chấp nhận hoặc hành vi mong đợi. Mỗi trường dùng đúng placeholder trong ngoặc nhọn góc. Tier 2 chỉ là khung tái sử dụng; không thay placeholder bằng dữ liệu Nova Foods khi chưa có bằng chứng. Nova Foods là case mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp.

Trường	Placeholder bắt buộc	Giá trị hợp lệ / định dạng	Quy tắc kiểm tra và hướng dẫn
Defect ID	<DEFECT-ID theo registry canonical>	ID duy nhất, giữ nguyên tiền tố đã đăng ký trong TRACEABILITY_ID_REGISTRY	Không tự tạo tiền tố hoặc đổi ID sau khi liên kết evidence. Nếu chưa có ID hợp lệ, ghi <Cần đăng ký ID theo TRACEABILITY_ID_REGISTRY> và không đánh dấu record là hoàn tất.
Tiêu đề lỗi	<Mô tả ngắn: chức năng + điều kiện + kết quả sai>	Tối đa 160 ký tự; không chứa bí mật, dữ liệu cá nhân, token	Viết kết quả quan sát được, không kết luận nguyên nhân gốc. Ví dụ cấu trúc: <Tạo đơn hàng với dữ liệu hợp lệ trả về lỗi không mong đợi>.
Trạng thái	<STATUS>	NEW, TRIAGED, IN_PROGRESS, RESOLVED, RETEST, CLOSED, REJECTED, DUPLICATE, BLOCKED	CLOSED chỉ hợp lệ sau RETEST đạt và có evidence. REJECTED phải có lý do, người quyết định có thẩm quyền và traceability. Không suy diễn approval từ trạng thái.
Mức độ nghiêm trọng	<SEVERITY>	CRITICAL, HIGH, MEDIUM, LOW	Đánh giá tác động nếu lỗi xảy ra, không dựa vào cảm nhận. CRITICAL khi mất dữ liệu, sai lệch kiểm soát trọng yếu, gián đoạn luồng cốt lõi hoặc rủi ro bảo mật cần xử lý khẩn.
Ưu tiên xử lý	<PRIORITY>	P1, P2, P3, P4	Ưu tiên dựa trên severity, phạm vi ảnh hưởng, thời hạn phát hành và workaround. Không bắt buộc CRITICAL = P1; phải nêu reasoning trong trường quyết định.
Nguồn phát hiện	<DETECTION-SOURCE>	SIT, UAT, Regression, Exploratory, API test, Accessibility test, Security test, Review	Chọn một nguồn chính. Nếu nhiều nguồn, ghi nguồn phát hiện đầu tiên và liệt kê nguồn bổ sung trong evidence.
Môi trường	<ENVIRONMENT>	<Tên môi trường mô phỏng>, <build/version>, <browser/client nếu áp dụng>	Bắt buộc đủ để tái lập. Không ghi URL nội bộ thật, IP thật, tài khoản thật hoặc cấu hình production.
Ngày giờ phát hiện	<YYYY-MM-DDTHH:mm:ss+07:00>	ISO 8601; múi giờ Asia/Ho_Chi_Minh	Không dùng ngày mơ hồ. Thời điểm phải không muộn hơn thời điểm tạo record.
Người ghi nhận	<Vai trò hoặc định danh mô phỏng>	Vai trò mô phỏng hoặc ID giả lập	Không dùng họ tên, email, số điện thoại thật.
Module/chức năng	<MODULE-NAME>	Tên chức năng theo artifact nguồn	Nếu tên chưa được quản trị canonical, ghi <Cần đối chiếu artifact nguồn>; không tự chuẩn hóa tên.
Điều kiện tiên quyết	<PRECONDITIONS>	Danh sách có thứ tự; từng điều kiện kiểm chứng được	Bắt buộc khi lỗi phụ thuộc quyền, dữ liệu, cấu hình, trạng thái workflow hoặc tích hợp. Không dùng “thiết lập bình thường”.
Bước tái lập	<STEP-NO>. <ACTION>	Ít nhất một bước; tuần tự; một hành động mỗi dòng	Mỗi bước phải cho người khác tái hiện mà không đoán. Nếu không tái lập được, chọn trạng thái BLOCKED hoặc ghi rõ tính không ổn định trong ngoại lệ.
Kết quả mong đợi	<EXPECTED-RESULT>	Liên kết requirement, rule, acceptance criterion, mockup hoặc API contract	Không viết “hệ thống hoạt động đúng”. Nêu đầu ra quan sát được và căn cứ. Nếu căn cứ chưa xác minh, gắn Verification required.
Kết quả thực tế	<ACTUAL-RESULT>	Quan sát cụ thể: thông báo, mã HTTP, dữ liệu hiển thị, trạng thái	Không sao chép secret, access token, cookie, dữ liệu cá nhân hoặc payload nhạy cảm. Che dữ liệu bằng <REDACTED-SENSITIVE-DATA> khi cần.
Khả năng tái lập	<REPRODUCIBILITY>	ALWAYS, INTERMITTENT, ONCE, NOT_RETESTED	INTERMITTENT bắt buộc có số lần thử và số lần lỗi, dạng <x/y lần>. ONCE không được dùng để đóng lỗi.
Workaround	<WORKAROUND hoặc NONE>	Hướng dẫn an toàn, kiểm chứng được; hoặc NONE	Nếu workaround thay đổi dữ liệu, ảnh hưởng kiểm soát hoặc cần quyền cao, ghi Verification required và escalation đúng vai trò.
Phân loại lỗi	<DEFECT-TYPE>	Functional, Data, Integration, Performance, Security, Accessibility, Usability, Compatibility, Documentation, Other	Other bắt buộc giải thích. Security không được ghi chi tiết khai thác, secret hoặc lỗ hổng có thể bị lạm dụng trong record phổ biến.
Quyết định triage	<TRIAGE-DECISION>	FIX, DEFER, REJECT, DUPLICATE, ESCALATE, NEED_MORE_EVIDENCE	Phải nêu evidence/reasoning bridge: <Quyết định>; bằng chứng: <ID/link>; lý do: <tác động và căn cứ>. DEFER cần phiên bản hoặc mốc xem xét, không phải cam kết phát hành.
Ngoại lệ / rủi ro	<EXCEPTION-OR-RISK>	NONE hoặc mô tả kiểm chứng được	Bắt buộc nếu không tái lập, thiếu test basis, có rủi ro dữ liệu, bảo mật, pháp lý, kế toán, thuế hoặc an toàn thực phẩm. Nội dung pháp lý phải gắn Verification required; không diễn giải luật.
Owner xử lý	<ROLE/TEAM>	Vai trò hoặc nhóm mô phỏng	Không gán cá nhân thật. Owner xử lý không đồng nghĩa phê duyệt sửa lỗi.
Phiên bản phát hiện / sửa	<FOUND-IN-VERSION> / <FIXED-IN-VERSION hoặc NOT_FIXED>	Chuỗi version/build truy vết được	FIXED-IN-VERSION chỉ điền khi có build hoặc thay đổi xác định. RESOLVED không tự chứng minh sửa đã đạt.
Evidence ID	<EVIDENCE-ID>	ID theo TRACEABILITY_ID_REGISTRY	Bằng chứng gồm ảnh đã che dữ liệu, log đã lọc, request/response đã che bí mật, video, kết quả test hoặc liên kết artifact. Không nhúng secret vào Markdown.
Traceability	<SOURCE-ARTIFACT-ID>; <REQUIREMENT/RULE/TEST-ID>	Chỉ dùng ID canonical đã tồn tại	Ghi nguồn test basis và liên kết liên quan. Nếu chưa có nguồn, ghi <Thiếu test basis — NEED_MORE_EVIDENCE>; không bịa requirement hoặc rule.
Review	<REVIEWER-ROLE>; <REVIEW-DATE>; <REVIEW-OUTCOME>	Outcome: ACCEPTED_FOR_TRIAGE, RETURNED_FOR_CLARIFICATION, ESCALATED	Reviewer kiểm tra đủ thông tin và traceability, không tạo approval ngầm định.
Sign-off	<SIGN-OFF-STATUS>; <AUTHORIZED-ROLE>; <DATE>	NOT_REQUESTED, PENDING, RECORDED, NOT_APPLICABLE	Chỉ ghi RECORDED khi có tham chiếu sign-off được quản trị. Không điền tên người hoặc khẳng định người dùng phê duyệt khi không có bằng chứng.
Kiểm soát phiên bản record	<RECORD-VERSION>; <CHANGE-DATE>; <CHANGE-SUMMARY>	Version tăng theo quy tắc quản trị artifact	Mọi thay đổi trạng thái, severity, expected result, evidence, quyết định hoặc traceability phải có dòng lịch sử. Không sửa im lặng.

Mẫu tham chiếu bí mật an toàn. Không ghi mật khẩu, API key, bearer token, session cookie, chuỗi kết nối DB, khóa riêng, dữ liệu định danh cá nhân hoặc URL chứa credential. Dùng <SECRET-REFERENCE: vault-path-or-ticket-id> và <REDACTED-SENSITIVE-DATA>. Record phải nêu loại bí mật, vị trí tham chiếu an toàn, người có quyền truy cập theo quy trình dự án và lý do cần truy cập; không nêu giá trị bí mật. Ví dụ: <SECRET-REFERENCE: secure-vault-reference-required>.

Điều kiện kích hoạt phần bổ sung. Nếu DEFECT-TYPE = Security, thêm <SECURITY-IMPACT>, <AFFECTED-ASSET>, <EXPOSURE-SCOPE> và escalation Security; không công bố chi tiết khai thác. Nếu DEFECT-TYPE = Accessibility, thêm <WCAG-REFERENCE hoặc Verification required>, công nghệ hỗ trợ và thao tác bàn phím đã thử; chỉ nêu tiêu chí WCAG khi đối chiếu nguồn. Nếu DEFECT-TYPE = Integration hoặc API test, thêm <ENDPOINT/MESSAGE-REFERENCE đã che secret>, <HTTP-STATUS hoặc MESSAGE-STATUS>, <CORRELATION-ID đã che nếu nhạy cảm> và contract nguồn. Nếu lỗi liên quan dữ liệu cá nhân, thuế, kế toán, hóa đơn, truy xuất thực phẩm hoặc thu hồi, thêm <IMPACTED-DOMAIN>, <ESCALATION-ROLE> và Verification required; template không tự kết luận nghĩa vụ pháp lý hoặc tuân thủ.

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ộ dữ liệu dưới đây là dữ liệu tổng hợp, dùng locale vi-VN, múi giờ Asia/Ho_Chi_Minh và tiền tệ VND.

Trường core record	Giá trị đã điền
Defect ID	DEF-NF-ERP-20260807-001
Tiêu đề	Hệ thống cho phép xác nhận xuất kho khi số lượng lô LOT-MANGO-240701-A thấp hơn số lượng giao
Artifact	/03-templates/TMPL-TST-003_DEFECT_LOG.md
Artifact status	IN_REVIEW
Artifact version	v0.9.0
Ngày ghi nhận	2026-08-07 10:24:18 Asia/Ho_Chi_Minh
Người ghi nhận	Nguyễn Minh An — QA Analyst mô phỏng
Vai trò bị ảnh hưởng	Lê Thu Hà — Warehouse Supervisor mô phỏng
Module	ERP Inventory Management
Chức năng	Xác nhận phiếu xuất kho bán hàng
Defect type	Functional
Environment	UAT-NF-ERP-01; dữ liệu UAT tổng hợp; trình duyệt Microsoft Edge 128.0
Severity	High
Priority	P1
Trạng thái defect	New
Release bị ảnh hưởng	NF-ERP-UAT-RC3
Thành phần bị ảnh hưởng	inventory-allocation-service; màn hình Outbound Delivery Confirmation
Transaction ID	OD-NF-20260807-0142
Sales Order ID	SO-NF-20260807-0088
Delivery Note ID	DN-NF-20260807-0061
Warehouse ID	WH-HCM-01 — Kho Thành phẩm TP.HCM mô phỏng
Item ID	FG-MANGO-DRINK-1L
Tên hàng	Nước xoài Nova 1L
Batch/Lot ID	LOT-MANGO-240701-A
Đơn vị tính	THUNG
Số lượng khả dụng trước thao tác	18 THUNG
Số lượng giao yêu cầu	20 THUNG
Đơn giá mô phỏng	312.000 VND/THUNG
Giá trị giao dự kiến	6.240.000 VND
Khách hàng mô phỏng	CUS-NF-00045 — Siêu thị Bình Minh Quận 7
Phân loại nguồn	Synthetic UAT transaction data
Nguồn nghiệp vụ	Phiếu bán hàng và phiếu giao hàng mô phỏng trong UAT-NF-ERP-01
Nguồn kỹ thuật	Nhật ký ứng dụng UAT mô phỏng, correlation ID CORR-NF-UAT-20260807-102401
Phân loại dữ liệu	Internal simulated operational data; không chứa dữ liệu cá nhân, thông tin thanh toán, bí mật truy cập hoặc dữ liệu production

Mô tả lỗi. Khi người dùng mở DN-NF-20260807-0061, chọn lô LOT-MANGO-240701-A, nhập số lượng giao 20 THUNG rồi bấm Xác nhận xuất kho, hệ thống trả trạng thái thành công và tạo giao dịch xuất kho. Số lượng khả dụng trước thao tác là 18 THUNG; chênh lệch thiếu là 2 THUNG. Hệ thống vẫn ghi nhận xuất 20 THUNG, làm tồn kho khả dụng của lô thành -2 THUNG.

Dữ liệu kiểm tra	Giá trị
Tồn kho đầu kỳ của lô	18 THUNG
Số lượng yêu cầu xuất	20 THUNG
Số lượng hệ thống đã xuất	20 THUNG
Tồn kho sau xác nhận	-2 THUNG
Chênh lệch không hợp lệ	2 THUNG
Giá trị hàng vượt tồn mô phỏng	624.000 VND

Bước tái hiện.

1. Đăng nhập môi trường UAT-NF-ERP-01 bằng tài khoản kiểm thử mô phỏng qa.an.nguyen.
2. Mở Delivery Note DN-NF-20260807-0061 thuộc Sales Order SO-NF-20260807-0088.
3. Chọn kho WH-HCM-01 và lô LOT-MANGO-240701-A.
4. Xác nhận số lượng khả dụng hiển thị là 18 THUNG.
5. Nhập số lượng xuất 20 THUNG.
6. Bấm Xác nhận xuất kho.
7. Mở lịch sử tồn kho của FG-MANGO-DRINK-1L tại WH-HCM-01.

Kết quả thực tế. Hệ thống hiển thị thông báo Xuất kho thành công, tạo transaction OD-NF-20260807-0142 và cập nhật tồn khả dụng của LOT-MANGO-240701-A thành -2 THUNG.

Kết quả mong đợi. Hệ thống phải chặn xác nhận xuất kho khi số lượng yêu cầu lớn hơn số lượng khả dụng của đúng kho, đúng item và đúng lô. Hệ thống phải giữ phiếu ở trạng thái chưa xác nhận, không tạo transaction xuất kho, không thay đổi tồn kho, đồng thời hiển thị lỗi rõ: Số lượng xuất 20 THUNG vượt tồn khả dụng 18 THUNG của lô LOT-MANGO-240701-A.

Tác động nghiệp vụ. Tồn âm làm số liệu sẵn sàng giao hàng sai. Người dùng kho có thể tiếp tục lập giao dịch dựa trên số lượng không tồn tại. Giá trị mô phỏng bị ghi nhận vượt tồn là 624.000 VND. Đây là rủi ro vận hành trong case học liệu; không phải kết luận kế toán, thuế, pháp lý hoặc xác nhận cấu hình ERP thực tế.

Phân công xử lý	Giá trị
Assignee đề xuất	Trần Quốc Duy — ERP Inventory Developer mô phỏng
Reviewer đề xuất	Phạm Gia Hân — Solution Architect mô phỏng
Owner nghiệp vụ cần xác nhận rule	Võ Thanh Tùng — Supply Chain Manager mô phỏng
Target fix date đề xuất	2026-08-09
Retest owner đề xuất	Nguyễn Minh An — QA Analyst mô phỏng
Quyết định hiện hành	Chưa có quyết định xử lý được ghi nhận
Approval hiện hành	Chưa có phê duyệt được ghi nhận
Escalation	Escalate tới Supply Chain Manager mô phỏng nếu nghiệp vụ cho phép xuất âm theo chính sách kho riêng; không tự suy diễn chính sách đó từ defect record

Hồ sơ lỗi hoàn chỉnh DEF-NF-2026-0041

Trường lõi	Giá trị hoàn chỉnh
Defect ID	DEF-NF-2026-0041
Artifact	/03-templates/TMPL-TST-003_DEFECT_LOG.md
Status	IN_REVIEW
Version	v0.9.0
Ngày ghi nhận	2026-08-07 10:25 ICT
Múi giờ, locale, tiền tệ	Asia/Ho_Chi_Minh; vi-VN; VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục; toàn bộ dữ liệu tổng hợp
Người ghi nhận	Nguyễn Minh An — QA Analyst mô phỏng
Module bị ảnh hưởng	ERP Sales Order Management — tạo đơn bán hàng
Môi trường	UAT-NF-01, build ERP-NF-0.9.0-uat.20260807.2
Severity	S2-High: sai tổng tiền đơn hàng, có thể dẫn đến hóa đơn và công nợ mô phỏng sai
Priority	P1-High: cần sửa trước vòng kiểm thử hồi quy doanh thu
Loại lỗi	Calculation Defect — lỗi tính toán
Trạng thái xử lý	NEW
Owner xử lý đề xuất	Trần Quốc Bình — ERP Application Developer mô phỏng
Quyết định phát hành	Chưa có. IN_REVIEW không phải phê duyệt hoặc cho phép triển khai production.

Sự kiện kiểm thử. Ngày 2026-08-07 10:18 ICT, Nguyễn Minh An tạo đơn bán mô phỏng SO-NF-20260807-0187 cho khách hàng CUS-NF-000245 — Công ty TNHH Phân phối Đông Nam. Đơn có một dòng hàng FG-NF-CHILI-500G, số lượng 120, đơn giá trước thuế 48.000 VND, mức giảm giá thương mại 5%. Hệ thống hiển thị tổng trước thuế 5.472.000 VND, thuế VAT 547.200 VND, tổng thanh toán 6.019.200 VND. Dữ liệu đầu vào và kết quả được chụp trong bằng chứng EVD-DEF-NF-2026-0041-01.

Dòng đơn	Mã hàng	Diễn giải	SL	Đơn giá trước thuế	Giảm giá	Kết quả hệ thống	Kết quả mong đợi
SO-NF-20260807-0187-01	FG-NF-CHILI-500G	Tương ớt Nova 500 g	120	48.000 VND	5%	5.472.000 VND trước thuế; VAT 547.200 VND; 6.019.200 VND thanh toán	5.472.000 VND trước thuế; VAT 492.480 VND; 5.964.480 VND thanh toán

Hành vi hiện tại. Payload lưu đơn ghi discountAmount=288000, netAmount=5472000, taxRate=0.10, taxAmount=547200, grossAmount=6019200. Số VAT bằng netAmount × 10%, nên hệ thống tính thuế 10% trên giá trị đã giảm giá. Tuy nhiên, màn hình hiển thị VAT 10% trong khi master dữ liệu khách hàng CUS-NF-000245 tại thời điểm kiểm thử có taxRate=0.09. Bằng chứng bridge: payload API và màn hình cùng ghi tổng VAT 547.200 VND; giá trị này khớp 10% của 5.472.000 VND, không khớp 9%. Lỗi không nằm ở phép nhân VAT mà ở việc service bỏ qua thuế suất khách hàng đã chọn.

Nhu cầu nền. ERP cần lấy đúng thuế suất hiệu lực từ dữ liệu đơn hàng đã xác nhận, rồi tính thuế trên giá trị sau giảm giá. Điều này giữ nhất quán giữa màn hình, payload, hóa đơn mô phỏng và công nợ mô phỏng. Đây là yêu cầu mô phỏng; thuế suất 9% là dữ liệu test tổng hợp, không phải kết luận về thuế Việt Nam. Việc dùng thuế suất thực tế cần Accounting Owner và Legal Owner xác minh từ nguồn chính thức hiện hành.

Quy tắc	Giá trị áp dụng cho test	Cách kiểm tra
BR-NF-SO-014	lineDiscountAmount = quantity × unitPrice × discountRate	120 × 48.000 × 5% = 288.000 VND
BR-NF-SO-015	lineNetAmount = quantity × unitPrice - lineDiscountAmount	5.760.000 - 288.000 = 5.472.000 VND
BR-NF-SO-016	lineTaxAmount = lineNetAmount × taxRate, làm tròn đến VND gần nhất	5.472.000 × 9% = 492.480 VND
BR-NF-SO-017	orderGrossAmount = tổng lineNetAmount + tổng lineTaxAmount	5.472.000 + 492.480 = 5.964.480 VND

Payload tái hiện lỗi.

{
  "salesOrderId": "SO-NF-20260807-0187",
  "customerId": "CUS-NF-000245",
  "currencyCode": "VND",
  "taxRate": 0.09,
  "lines": [
    {
      "salesOrderLineId": "SO-NF-20260807-0187-01",
      "itemId": "FG-NF-CHILI-500G",
      "quantity": 120,
      "unitPrice": 48000,
      "discountRate": 0.05,
      "discountAmount": 288000,
      "netAmount": 5472000,
      "taxAmount": 547200,
      "grossAmount": 6019200
    }
  ]
}

Phương án	Mô tả	Tiêu chí đánh giá	Kết quả
OPT-01	Giữ cố định 10% trong service tính đơn	Ít thay đổi mã nhưng mâu thuẫn taxRate=0.09 trong payload	Loại
OPT-02	Lấy taxRate từ payload đã được service kiểm tra hợp lệ	Đúng dữ liệu đơn, hỗ trợ nhiều thuế suất mô phỏng, thay đổi nhỏ	Khuyến nghị
OPT-03	Tính lại thuế suất từ màn hình khi lưu đơn	Có nguy cơ khác dữ liệu payload và khó truy vết	Loại

Quyết định đề xuất. Chọn OPT-02: service tính taxAmount từ lineNetAmount × salesOrder.taxRate. Service phải từ chối taxRate ngoài khoảng 0 đến 1; phản hồi lỗi SO_TAX_RATE_INVALID khi dữ liệu không hợp lệ. Người có thẩm quyền quyết định thay đổi quy tắc nghiệp vụ mô phỏng: Business Owner mô phỏng. Người có thẩm quyền xác nhận thiết kế kỹ thuật: Solution Architect mô phỏng. QA chỉ xác nhận kết quả kiểm thử, không phê duyệt quy tắc hay phát hành.

Hậu quả nếu sửa sai. Nếu service vẫn dùng 10%, đơn SO-NF-20260807-0187 chênh 54.720 VND; chứng từ bán hàng, công nợ và báo cáo doanh thu mô phỏng có thể không khớp cùng một đơn. Nếu service dùng payload không kiểm tra, dữ liệu thuế suất bất thường có thể làm tổng tiền âm hoặc vượt phạm vi mô phỏng.

Traceability ID	Loại liên kết	Nguồn hoặc bằng chứng	Phân loại nguồn
DEF-NF-2026-0041	Hồ sơ lỗi	Record này	Artifact mô phỏng nội bộ
TC-NF-SO-032	Test case thất bại	Kiểm tra VAT theo thuế suất đơn bán	Artifact mô phỏng nội bộ
EVD-DEF-NF-2026-0041-01	Bằng chứng	Ảnh màn hình tổng tiền lúc 2026-08-07 10:18 ICT	Bằng chứng tổng hợp
EVD-DEF-NF-2026-0041-02	Bằng chứng	Request/response API POST /api/v1/sales-orders	Bằng chứng tổng hợp
BR-NF-SO-014 đến BR-NF-SO-017	Quy tắc	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Canonical planned source, IN_REVIEW
CANONICAL_DATA_DICTIONARY	Dữ liệu logic	SalesOrder.taxRate, SalesOrderLine.netAmount, SalesOrderLine.taxAmount	Canonical planned source, IN_REVIEW
ISTQB CTFL	Thuật ngữ defect, severity, priority	https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf	Nguồn chính đã xác minh; dùng thuật ngữ kiểm thử

Phân tích quyết định lỗi DEF-NF-2026-0041

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu, vai trò, giao dịch và giá trị dưới đây là dữ liệu tổng hợp. Defect là lỗi phần mềm: hành vi thực tế khác hành vi mong đợi đã được xác định từ test basis, tức tài liệu làm căn cứ kiểm thử. Lỗi này phát hiện lúc 2026-08-07 10:18:42 theo Asia/Ho_Chi_Minh, khi nhân viên kho tạo phiếu xuất nguyên liệu GI-NF-20260807-0186 cho lệnh sản xuất MO-NF-20260807-0042.

Nội dung	Ghi nhận hoàn chỉnh
Defect ID	DEF-NF-2026-0041
Tên lỗi	ERP cho phép xác nhận xuất kho vượt tồn khả dụng của lô nguyên liệu
Phân hệ	Inventory Management
Mức độ nghiêm trọng	Critical
Trạng thái	IN_REVIEW
Người ghi nhận	Lê Minh Khoa, QA Analyst mô phỏng
Người phát hiện	Trần Quốc Huy, Warehouse User mô phỏng
Môi trường	UAT-NF-ERP-01, build ERP-0.9.0-rc3
Dữ liệu giao dịch	Mã hàng RM-SUGAR-REF-001; lô LOT-SGR-260801-A; kho WH-HCM-RM-01; tồn khả dụng trước giao dịch 120 kg; số lượng xuất xác nhận 150 kg; giá trị đơn vị 18.500 VND/kg; giá trị vượt tồn 555.000 VND
Phân loại nguồn	Project assumption cho quy tắc tồn khả dụng và luồng ERP mô phỏng; Synthetic test evidence cho dữ liệu giao dịch, ảnh chụp màn hình và kết quả thực thi
Liên kết truy vết	BR-NF-INV-007; REQ-NF-INV-021; AC-NF-INV-021-03; TC-NF-INV-021-07; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md

Sự kiện đã quan sát: người dùng nhập 150 kg tại trường Issued Quantity, chọn lô còn 120 kg, rồi bấm Confirm Issue. ERP tạo phiếu GI-NF-20260807-0186 ở trạng thái POSTED, giảm tồn khả dụng lô xuống -30 kg, đồng thời trả phản hồi API HTTP 201 Created. Đây là fact vì tái hiện được ba lần trên cùng môi trường UAT với cùng dữ liệu đầu vào; bằng chứng là EVD-NF-DEF-0041-01 gồm ảnh màn hình trước xác nhận, ảnh màn hình sau xác nhận và payload phản hồi API đã che thông tin không cần thiết.

Hành vi hiện tại: dịch vụ xác nhận xuất kho chỉ kiểm tra số lượng có lớn hơn 0 hay không. Bằng chứng suy luận: 20 kg và 120 kg đều được chấp nhận; 0 kg bị chặn với thông báo Issued quantity must be greater than zero; 150 kg cũng được chấp nhận dù vượt tồn khả dụng. Vì điều kiện chặn chỉ phân biệt số dương và không dương, hệ thống chưa áp dụng điều kiện Issued Quantity <= Available Quantity trước khi ghi sổ tồn.

Nhu cầu gốc: kho cần ngăn giao dịch làm tồn khả dụng âm theo từng mã hàng, kho và lô. BR-NF-INV-007 là quy tắc nghiệp vụ mô phỏng: chỉ cho phép xác nhận xuất khi số lượng xuất dương và không lớn hơn tồn khả dụng đã khóa cho giao dịch. Lý do là lô LOT-SGR-260801-A là đơn vị truy vết nguyên liệu; nếu số dư âm được ghi nhận, báo cáo tồn kho, khả năng phân bổ nguyên liệu và đối chiếu tiêu hao cho lệnh MO-NF-20260807-0042 không còn phản ánh dữ liệu giao dịch hợp lệ. Đây không phải kết luận pháp lý hay kế toán; mọi diễn giải vận hành thực tế cần Business Owner và Accounting Owner xác minh.

Phương án	Cách xử lý	Tiêu chí đạt	Hệ quả
OPT-01	Cho phép tồn âm, cảnh báo sau khi POSTED	Không đạt BR-NF-INV-007; lỗi phát hiện muộn	Có thể phát sinh số dư âm -30 kg, cần điều chỉnh thủ công
OPT-02	Chặn tại giao diện người dùng	Chặn được luồng màn hình hiện tại, nhưng không bảo vệ API hoặc tích hợp	Có thể vượt kiểm tra qua API hoặc tiến trình khác
OPT-03	Kiểm tra tồn khả dụng trong dịch vụ xác nhận; từ chối toàn bộ giao dịch khi thiếu tồn	Bảo vệ giao diện, API và mọi kênh gọi chung dịch vụ; không tạo bút toán tồn khi bị từ chối	Đạt nhu cầu và giới hạn lỗi tại điểm ghi nhận giao dịch

Tiêu chí quyết định: phương án phải kiểm tra tại điểm dùng chung cho giao diện và API; phải dùng tồn khả dụng theo đúng Item ID + Warehouse ID + Lot ID; phải không tạo phiếu POSTED, không giảm tồn, không sinh bút toán khi số lượng yêu cầu lớn hơn tồn khả dụng; phải trả lỗi có thể hiểu cho nhân viên kho; phải giữ giao dịch hợp lệ 120 kg hoạt động bình thường. OPT-03 đáp ứng đủ năm tiêu chí. OPT-01 thất bại tiêu chí ngăn lỗi trước ghi nhận. OPT-02 thất bại tiêu chí kiểm soát mọi kênh truy cập.

Khuyến nghị: chọn OPT-03. Quy tắc xử lý đề xuất: trước khi tạo GI-NF-20260807-0186, dịch vụ khóa bản ghi tồn của RM-SUGAR-REF-001, WH-HCM-RM-01, LOT-SGR-260801-A; nếu requestedQuantity > availableQuantity, trả HTTP 409 Conflict với mã INSUFFICIENT_LOT_STOCK, không tạo phiếu xuất và không đổi tồn. Nếu requestedQuantity <= availableQuantity, tiếp tục luồng xác nhận hiện hữu. Quyết định chỉ có hiệu lực khi Business Owner mô phỏng xác nhận quy tắc vận hành và Technical Architect mô phỏng xác nhận điểm kiểm tra dịch vụ; QA Lead mô phỏng xác nhận test basis. Bản ghi hiện tại IN_REVIEW, không phải phê duyệt hay baseline.

Hậu quả nếu quyết định sai: chọn OPT-01 hoặc OPT-02 có thể để tồn âm tiếp tục phát sinh từ API; chọn ngưỡng kiểm tra sai có thể chặn xuất hợp lệ đúng bằng tồn 120 kg; không khóa tồn tại điểm xác nhận có thể cho hai giao dịch đồng thời cùng tiêu hao một lượng tồn. Vì vậy, TC-NF-INV-021-07 phải kiểm tra từ chối 150 kg, không có bản ghi phiếu xuất mới, tồn vẫn 120 kg; kiểm tra biên 120 kg được chấp nhận và tồn sau giao dịch bằng 0 kg.

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

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp. Hồ sơ lỗi DEF-NF-INV-021 ghi nhận lỗi kiểm soát tồn theo lô khi API tạo phiếu xuất nguyên liệu chấp nhận số lượng 150 kg dù tồn khả dụng của RM-SUGAR-REF-001 tại WH-HCM-RM-01, lô LOT-SGR-260801-A, chỉ là 120 kg. “Exception” là ngoại lệ nghiệp vụ: tình huống không đi theo kết quả thành công bình thường và cần hệ thống xử lý có kiểm soát.

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

ID	Tình huống	Dữ liệu tổng hợp	Kết quả quan sát tại lỗi	Kết quả mong đợi	Mức độ
EXC-NF-INV-021-01	Yêu cầu xuất lớn hơn tồn khả dụng	requestedQuantity=150, availableQuantity=120, đơn vị kg	API tạo GI-NF-20260807-0186; tồn lô bị ghi nhận âm -30 kg	API từ chối trước khi tạo phiếu; không đổi tồn; trả HTTP 409 Conflict và INSUFFICIENT_LOT_STOCK	Critical
EXC-NF-INV-021-02	Yêu cầu xuất đúng bằng tồn khả dụng	requestedQuantity=120, availableQuantity=120, đơn vị kg	Chưa xác minh trong bằng chứng hiện có	Giao dịch được tiếp tục; tồn sau xác nhận là 0 kg	High
EXC-NF-INV-021-03	Hai yêu cầu đồng thời cùng dùng một lô	Hai yêu cầu đều 80 kg; tồn khả dụng ban đầu 120 kg	Chưa xác minh cơ chế khóa bản ghi tồn	Chỉ một giao dịch được xác nhận; giao dịch còn lại bị từ chối nếu tồn sau giao dịch đầu không đủ	Critical
EXC-NF-INV-021-04	Số lượng bằng 0 kg	requestedQuantity=0	Chưa xác minh	Từ chối dữ liệu đầu vào; không tạo phiếu xuất; không đổi tồn	Medium
EXC-NF-INV-021-05	Số lượng âm	requestedQuantity=-10	Chưa xác minh	Từ chối dữ liệu đầu vào; không tạo phiếu xuất; không đổi tồn	Medium
EXC-NF-INV-021-06	Lô không thuộc kho được yêu cầu	Item ID=RM-SUGAR-REF-001, Warehouse ID=WH-HCM-RM-01, Lot ID=LOT-SGR-260801-B	Chưa xác minh	Từ chối vì tổ hợp mặt hàng, kho và lô không hợp lệ; không suy diễn tồn từ lô khác	High

Lỗi có rủi ro dữ liệu vì hệ thống ghi nhận phiếu POSTED và làm tồn lô âm. Cầu nối suy luận: tồn khả dụng là 120 kg, yêu cầu là 150 kg, nên chênh lệch là 30 kg; phiếu xuất vẫn được tạo cho thấy điểm kiểm tra không chặn giao dịch trước khi ghi nhận. Không kết luận nguyên nhân kỹ thuật khi chưa có log dịch vụ, mã nguồn hoặc kết quả review kiến trúc.

4.2 Bằng chứng lỗi

Evidence ID	Tệp hoặc nguồn	Phân loại nguồn	Thời điểm ghi nhận	Nội dung chứng minh	Giới hạn sử dụng
EVD-NF-INV-021-01	/03-templates/evidence/EVD-NF-INV-021-01_request.json	Bằng chứng test tổng hợp	2026-08-07 09:15 Asia/Ho_Chi_Minh	Yêu cầu API xuất 150 kg từ lô có tồn khả dụng 120 kg	Không phải log production
EVD-NF-INV-021-02	/03-templates/evidence/EVD-NF-INV-021-02_response.json	Bằng chứng test tổng hợp	2026-08-07 09:15 Asia/Ho_Chi_Minh	Phản hồi thành công tạo GI-NF-20260807-0186	Không xác nhận thiết kế API chính thức
EVD-NF-INV-021-03	/03-templates/evidence/EVD-NF-INV-021-03_stock_before_after.csv	Bằng chứng test tổng hợp	2026-08-07 09:16 Asia/Ho_Chi_Minh	Tồn thay đổi từ 120 kg thành -30 kg	Không phải sổ kho hay chứng từ kế toán
EVD-NF-INV-021-04	TC-NF-INV-021-07	Test case mô phỏng	2026-08-07	Test basis cho đường đi âm: yêu cầu 150 kg phải bị từ chối	Kết quả chạy lại cần QA Lead mô phỏng xác nhận
EVD-NF-INV-021-05	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Canonical rule catalog plan, IN_REVIEW	2026-08-07	Nguồn quản trị dự kiến cho quy tắc tồn; chưa có quy tắc baseline được trích dẫn	Không được coi là quy tắc vận hành đã phê duyệt

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

“Assumption” là giả định dự án dùng để tiếp tục phân tích khi chưa có nguồn quyết định. “Verification required” là mục bắt buộc kiểm tra với vai trò có thẩm quyền trước khi dùng làm quyết định.

ID	Nội dung	Cầu nối bằng chứng hoặc lý do	Nhãn	Owner xác minh
ASM-NF-INV-021-01	availableQuantity được tính theo đúng tổ hợp Item ID + Warehouse ID + Lot ID	Lỗi phát sinh ở một lô xác định; kiểm tra theo tổng mặt hàng có thể dùng nhầm tồn của lô khác	Project assumption	Business Owner mô phỏng và Technical Architect mô phỏng
ASM-NF-INV-021-02	Trạng thái POSTED là thời điểm làm thay đổi tồn kho	Bằng chứng tổng hợp cho thấy phiếu được tạo cùng thay đổi tồn; chưa có đặc tả trạng thái canonical	Project assumption	Business Owner mô phỏng
VR-NF-INV-021-01	Xác minh API có dùng giao dịch nguyên tử và khóa bản ghi tồn khi xác nhận xuất	Hai yêu cầu đồng thời có thể cùng đọc tồn 120 kg; thiếu khóa có thể tạo tồn âm dù đã có kiểm tra số lượng	Verification required	Technical Architect mô phỏng
VR-NF-INV-021-02	Xác minh thông điệp INSUFFICIENT_LOT_STOCK và mã HTTP 409 Conflict phù hợp chuẩn lỗi API của dự án	Đây là phương án xử lý đề xuất, chưa có OpenAPI baseline hoặc error catalog baseline	Verification required	Technical Architect mô phỏng
VR-NF-INV-021-03	Xác minh ảnh hưởng tới chứng từ, sổ kho và hạch toán nếu phiếu POSTED đã được ghi nhận	Luật Kế toán và quy định hóa đơn, chứng từ là nguồn pháp lý; diễn giải áp dụng cần thẩm quyền kế toán/pháp lý	Verification required	Accounting Owner mô phỏng và Legal Owner mô phỏng

4.4 Bản ghi escalation

“Escalation” là chuyển vấn đề đến vai trò có thẩm quyền khi BA không được tự quyết định. Escalation cần thiết vì lỗi chạm đồng thời quy tắc vận hành kho, kiểm soát giao dịch API và khả năng ảnh hưởng dữ liệu kế toán.

Escalation ID	Ngày	Người nhận	Vấn đề cần quyết định	Bằng chứng đính kèm	Trạng thái
ESC-NF-INV-021-01	2026-08-07	Business Owner mô phỏng	Xác nhận có cấm tồn khả dụng âm theo từng lô cho nghiệp vụ xuất nguyên liệu hay không	EVD-NF-INV-021-01 đến EVD-NF-INV-021-05	Open
ESC-NF-INV-021-02	2026-08-07	Technical Architect mô phỏng	Xác nhận điểm kiểm tra dịch vụ, cơ chế khóa và xử lý đồng thời	EXC-NF-INV-021-01, EXC-NF-INV-021-03, VR-NF-INV-021-01	Open
ESC-NF-INV-021-03	2026-08-07	QA Lead mô phỏng	Xác nhận TC-NF-INV-021-07 đủ kiểm tra từ chối 150 kg, biên 120 kg, và không tạo phiếu khi bị từ chối	TC-NF-INV-021-07, EVD-NF-INV-021-04	Open
ESC-NF-INV-021-04	2026-08-07	Accounting Owner mô phỏng và Legal Owner mô phỏng	Đánh giá xử lý dữ liệu đã ghi nhận âm trong môi trường mô phỏng; xác định có cần quy trình điều chỉnh chứng từ hay không	EVD-NF-INV-021-02, EVD-NF-INV-021-03, VR-NF-INV-021-03	Open

Không có baseline, approval, xác nhận tuân thủ pháp lý, hay quyết định triển khai production trong bản ghi này.

Ma trận truy vết đầu-cuối cho DEF-NF-INV-001

Truy vết đầu-cuối liên kết nhu cầu đến lỗi để kiểm tra lỗi có tác động nghiệp vụ thật hay chỉ là lỗi giao diện. Các ID dưới đây là dữ liệu tổng hợp cho Nova Foods Trading & Manufacturing mô phỏng, dùng trong /03-templates/TMPL-TST-003_DEFECT_LOG.md, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Chúng không là baseline, không là approval, không xác nhận cấu hình ERP thực tế. “Acceptance Criteria” (AC, tiêu chí chấp nhận) là điều kiện kiểm chứng được để xác định requirement đạt hay không.

Thứ tự	Họ ID	ID liên kết	Nội dung đã liên kết	Artifact nguồn hoặc nơi dùng	Phân loại nguồn	Cầu nối bằng chứng
1	NEED	NEED-NF-INV-001	Nhân viên kho cần chặn xuất nguyên liệu khi số lượng tồn khả dụng thấp hơn số lượng yêu cầu, tránh tạo giao dịch xuất kho âm.	Case mô phỏng Nova Foods trong template này	Dữ liệu tổng hợp giáo dục	Nhu cầu nêu kết quả cần bảo vệ: không cho tồn khả dụng âm.
2	REQ	REQ-NF-INV-014	ERP phải từ chối yêu cầu xuất kho khi requestedQuantity lớn hơn availableQuantity tại thời điểm xác nhận.	Case mô phỏng Nova Foods trong template này	Dữ liệu tổng hợp giáo dục	Requirement biến nhu cầu thành hành vi hệ thống đo được.
3	BR	BR-NF-INV-006	Chỉ cho phép tạo phiếu xuất khi requestedQuantity <= availableQuantity; số tồn khả dụng không được nhỏ hơn 0.	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Planned canonical catalog; IN_REVIEW	Quy tắc đặt điều kiện quyết định cho REQ-NF-INV-014; chưa được gọi là quy tắc vận hành đã baseline.
4	AC	AC-NF-INV-014-02	Với tồn khả dụng 120 kg và yêu cầu xuất 125 kg, hệ thống không tạo phiếu xuất, giữ tồn khả dụng 120 kg, trả mã INSUFFICIENT_AVAILABLE_STOCK.	Test basis mô phỏng của REQ-NF-INV-014	Dữ liệu tổng hợp giáo dục	AC cho giá trị vào, kết quả cấm và trạng thái dữ liệu sau xử lý.
5	DATA	DATA-NF-INV-003	availableQuantity: số thập phân không âm, đơn vị kg, giá trị kiểm tra 120.000.	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Planned canonical catalog; IN_REVIEW	Trường dữ liệu là căn cứ để đối chiếu điều kiện của BR và AC.
6	API	API-NF-WH-POST-001	POST /api/v1/warehouse-issues nhận itemCode, warehouseCode, requestedQuantity, uom; khi thiếu tồn trả HTTP 409 Conflict và mã nghiệp vụ INSUFFICIENT_AVAILABLE_STOCK.	Đặc tả API mô phỏng liên kết case này	Dữ liệu tổng hợp giáo dục; chưa là OpenAPI baseline	API là điểm thực thi được kiểm tra của requirement; HTTP 409 biểu thị xung đột với trạng thái tồn hiện có.
7	TC	TC-NF-INV-014-NEG-01	Gửi yêu cầu xuất 125 kg mã nguyên liệu RM-SOY-001 từ kho WH-HCM-01, khi tồn khả dụng là 120 kg; mong đợi HTTP 409, không có issueDocumentId, tồn vẫn 120 kg.	Test case mô phỏng cho AC-NF-INV-014-02	Dữ liệu tổng hợp giáo dục	TC tái hiện đúng dữ liệu và kết quả mong đợi của AC.
8	DEF	DEF-NF-INV-001	API trả HTTP 201 Created, tạo phiếu GI-SIM-20260807-001, cập nhật tồn khả dụng từ 120 kg thành -5 kg cho cùng dữ liệu của TC-NF-INV-014-NEG-01.	/03-templates/TMPL-TST-003_DEFECT_LOG.md	Bản ghi lỗi mô phỏng; IN_REVIEW	Kết quả thực tế trái BR-NF-INV-006, AC-NF-INV-014-02 và expected result của TC.

Liên kết cần kiểm tra	Kết quả truy vết	Tiêu chí quyết định
NEED-NF-INV-001 đến REQ-NF-INV-014	Đủ	Requirement trực tiếp xử lý rủi ro xuất vượt tồn khả dụng.
REQ-NF-INV-014 đến BR-NF-INV-006	Đủ	Cả hai dùng cùng quan hệ so sánh giữa số lượng yêu cầu và tồn khả dụng.
BR-NF-INV-006 đến AC-NF-INV-014-02	Đủ	AC kiểm tra nhánh requestedQuantity > availableQuantity, là nhánh bị cấm của BR.
AC-NF-INV-014-02 đến DATA-NF-INV-003 và API-NF-WH-POST-001	Đủ	AC nêu trường, giá trị, đơn vị, endpoint, HTTP status và mã lỗi cần kiểm chứng.
TC-NF-INV-014-NEG-01 đến DEF-NF-INV-001	Đủ	Cùng dữ liệu kiểm tra 125 kg so với 120 kg; actual result tạo tồn -5 kg, nên lỗi tái lập được.
DEF-NF-INV-001 đến CR	Không áp dụng	Chưa có change request (CR) vì lỗi là sai lệch so với requirement và AC hiện hữu, không phải yêu cầu đổi phạm vi.

4.1 Dữ liệu tái hiện lỗi, payload và bảng quyết định

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp. Gói tái hiện dùng để QA hoặc BA lặp lại lỗi DEF-NF-003 trên chức năng tạo đơn bán hàng. “Payload” là dữ liệu hệ thống gửi qua API (giao diện lập trình ứng dụng) để thực hiện thao tác. Mục tiêu kiểm tra: hệ thống không được chấp nhận số lượng đặt vượt tồn khả dụng của kho được chọn.

Thành phần	Giá trị hoàn chỉnh
Defect ID	DEF-NF-003
Tiêu đề lỗi	Hệ thống cho lưu đơn bán vượt tồn khả dụng tại kho
Môi trường mô phỏng	UAT-NOVA-01
Thời điểm tái hiện	2026-08-07 10:15:00 Asia/Ho_Chi_Minh
Người thực hiện mô phỏng	qa.nguyen.minh
Khách hàng	CUS-NF-00027 — Siêu thị An Phú
Kho xuất	WH-HCM-01 — Kho Thành phẩm Hồ Chí Minh
Sản phẩm	FG-NF-CHOCO-200 — Sữa chua Nova Choco 200g
Tồn khả dụng trước thao tác	12 hộp
Số lượng đặt	15 hộp
Đơn vị tính	HOP
Kết quả quan sát	Đơn SO-NF-20260807-0042 được lưu trạng thái CONFIRMED
Kết quả mong đợi	Không lưu đơn; hiển thị lỗi nghiệp vụ vì 15 lớn hơn 12

Sơ đồ luồng tái hiện

Người dùng mô phỏng
        |
        v
Tạo đơn SO-NF-20260807-0042
        |
        v
Chọn WH-HCM-01, FG-NF-CHOCO-200, số lượng 15
        |
        v
ERP đọc tồn khả dụng = 12 HOP
        |
        +-- Nếu số lượng <= tồn khả dụng -- Lưu đơn
        |
        +-- Nếu số lượng > tồn khả dụng --- Phải chặn lưu và báo lỗi
                                                   |
                                                   v
                                    Quan sát thực tế: vẫn lưu CONFIRMED

Payload tổng hợp đã gửi tới endpoint mô phỏng POST /api/v1/sales-orders:

{
  "salesOrderId": "SO-NF-20260807-0042",
  "orderDate": "2026-08-07",
  "customerId": "CUS-NF-00027",
  "currency": "VND",
  "warehouseId": "WH-HCM-01",
  "createdBy": "qa.nguyen.minh",
  "lines": [
    {
      "lineNo": 1,
      "itemId": "FG-NF-CHOCO-200",
      "uom": "HOP",
      "orderedQty": 15,
      "unitPrice": 18000,
      "lineAmount": 270000
    }
  ]
}

Bảng quyết định dưới đây dùng kỹ thuật kiểm thử hộp đen. Kỹ thuật này kiểm tra đầu vào và kết quả dự kiến mà không cần biết mã nguồn bên trong. Điều kiện kiểm soát là orderedQty phải là số nguyên dương và không vượt availableQty của đúng kho, đúng sản phẩm.

Quy tắc	availableQty	orderedQty	orderedQty là số nguyên dương	Kết quả phải có
DT-NF-003-01	12	10	Có	Lưu đơn; giữ trạng thái theo luồng đơn hợp lệ
DT-NF-003-02	12	12	Có	Lưu đơn; không tạo số lượng âm
DT-NF-003-03	12	15	Có	Chặn lưu; báo Số lượng đặt vượt tồn khả dụng của kho WH-HCM-01.
DT-NF-003-04	0	1	Có	Chặn lưu; báo Số lượng đặt vượt tồn khả dụng của kho WH-HCM-01.
DT-NF-003-05	12	0	Không	Chặn lưu; báo Số lượng đặt phải lớn hơn 0.
DT-NF-003-06	12	-1	Không	Chặn lưu; báo Số lượng đặt phải lớn hơn 0.
DT-NF-003-07	12	1.5	Không	Chặn lưu; báo Số lượng đặt phải là số nguyên theo đơn vị HOP.

Dữ liệu tái hiện chứng minh cầu nối suy luận: cùng warehouseId, itemId và đơn vị HOP, tồn khả dụng là 12 nhưng payload gửi orderedQty bằng 15; vì 15 > 12, hệ thống phải đi nhánh chặn lưu của bảng DT-NF-003-03. Việc đơn được lưu CONFIRMED là sai lệch cần ghi nhận trong defect log; dữ liệu này không xác nhận cấu hình ERP thực tế, không tạo baseline và không tạo phê duyệt.

5. Tier 4 ? Senior BA Quality Gate

Quality Gate là cổng kiểm soát chất lượng trước baseline. Senior BA kiểm tra defect record có đủ bằng chứng để đội kỹ thuật, QA và nghiệp vụ hiểu cùng một sai lệch hay không. Kết quả PASS chỉ nghĩa là tiêu chí kiểm tra đạt; không tạo baseline, không tạo phê duyệt, không xác nhận Nova Foods tuân thủ hoặc 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.

Mã kiểm tra	Nội dung kiểm tra	PASS	FAIL	STOP	Escalation
QG-DL-001	Tính đầy đủ	Có defectId, tiêu đề, môi trường, bước tái hiện, kết quả thực tế, kết quả mong đợi, mức độ, ưu tiên, owner, ngày ghi nhận, bằng chứng và liên kết traceability.	Thiếu trường nhưng vẫn xác định được sai lệch. Gửi lại người ghi nhận để bổ sung trước review tiếp.	Thiếu bước tái hiện, kết quả thực tế hoặc bằng chứng; không thể chứng minh defect tồn tại.	QA Lead khi thiếu test evidence; Business Owner khi thiếu kết quả mong đợi nghiệp vụ.
QG-DL-002	Tính nhất quán	itemId, warehouseId, số lượng, trạng thái, thời điểm và thông báo lỗi khớp giữa mô tả, payload, ảnh chụp, log và test case.	Một giá trị mâu thuẫn, có thể xác định nguồn đúng bằng bằng chứng gốc. Sửa record và lưu lịch sử sửa.	Hai nguồn gốc mâu thuẫn, không xác định nguồn nào đúng. Không phân loại severity hay giao xử lý.	QA Lead và Technical Lead để đối chiếu môi trường, log, dữ liệu test.
QG-DL-003	Khả năng kiểm thử	Bước tái hiện xác định rõ tiền điều kiện, dữ liệu đầu vào, thao tác, kết quả mong đợi và kết quả thực tế; người khác tái hiện được.	Thiếu chi tiết thao tác nhưng dữ liệu và quy tắc vẫn đủ để làm rõ.	Không có test basis, không có điều kiện đầu vào, hoặc kết quả mong đợi chỉ là nhận xét chủ quan.	QA Lead xác định test basis; Business Owner làm rõ hành vi mong đợi.
QG-DL-004	Traceability, nghĩa là truy vết nguồn gốc và tác động	Mỗi kỳ vọng liên kết tới requirement, business rule, acceptance criterion, test case hoặc nguồn có ID canonical. Liên kết chỉ rõ vì sao sai lệch là defect.	Có liên kết nhưng ID sai định dạng hoặc liên kết chưa chỉ rõ quan hệ.	Không có nguồn kỳ vọng; hoặc record tự tạo quy tắc mới để kết luận lỗi.	Principal IT Business Analyst / Technical Curriculum Author sửa liên kết; Business Owner quyết định rule chưa tồn tại.
QG-DL-005	Thẩm quyền nguồn	Nguồn nghiệp vụ do Business Owner sở hữu; nguồn test do QA sở hữu; nguồn kỹ thuật do Architect hoặc Technical Lead sở hữu; nguồn pháp lý, kế toán, bảo mật do role có thẩm quyền xác minh.	Nguồn được nêu nhưng chưa phân loại Verified, Project assumption hoặc Verification required.	Dùng tài liệu không canonical làm nguồn quyết định; diễn giải pháp luật, kế toán hoặc thuế như kết luận đã xác minh.	Legal Owner, Accounting Owner, Security Owner, Compliance Owner hoặc Architect theo loại nguồn.
QG-DL-006	Ownership, nghĩa là quyền chịu trách nhiệm xử lý	Có Reporter, Assignee, QA Owner và người quyết định khi cần; mỗi vai trò có phạm vi rõ.	Có assignee nhưng chưa có QA Owner hoặc người làm rõ nghiệp vụ.	Giao defect cho vai trò không có quyền sửa, xác nhận hoặc quyết định; không có owner.	Delivery Manager hoặc Product Owner phân công lại; không suy diễn approval.
QG-DL-007	Ranh giới bảo mật và riêng tư	Evidence không chứa mật khẩu, token, khóa bí mật, dữ liệu cá nhân thật hoặc dữ liệu production. Nếu có dữ liệu cá nhân mô phỏng, phải ghi mục đích và hạn chế truy cập.	Evidence có dữ liệu nhạy cảm tổng hợp nhưng chưa ghi phân loại và biện pháp che giấu.	Lộ secret, token hoạt động, dữ liệu cá nhân thật, dữ liệu production, hoặc evidence có nguy cơ truy cập trái phép. Dừng chia sẻ record.	Security Owner và Privacy/Legal Owner. Tham chiếu OWASP ASVS 5.0.0 hoặc OWASP API Security Top 10 2023 chỉ là good practice, không phải luật Việt Nam.
QG-DL-008	Ranh giới pháp lý, kế toán, hóa đơn và an toàn thực phẩm	Record phân biệt rõ fact quan sát được với Project assumption và Verification required; không tự kết luận nghĩa vụ pháp lý hay hạch toán.	Có tác động pháp lý hoặc kế toán tiềm năng nhưng nhãn xác minh chưa đầy đủ.	Defect yêu cầu quyết định về hóa đơn, thuế, lưu trữ chứng từ, dữ liệu cá nhân, truy xuất hoặc thu hồi thực phẩm mà chưa có owner có thẩm quyền.	Legal Owner, Accounting Owner, Compliance Owner, Food Safety Owner.
QG-DL-009	Tác động thay đổi	Record nêu phạm vi ảnh hưởng: quy tắc, dữ liệu, API, giao diện, báo cáo, phân quyền, test regression và artifact liên quan. Lý do tác động phải dựa trên liên kết traceability.	Chưa đủ danh sách artifact ảnh hưởng nhưng đã xác định module chính.	Thay đổi có thể ảnh hưởng số dư, tồn kho, hóa đơn, quyền truy cập hoặc dữ liệu cá nhân nhưng chưa đánh giá tác động và rollback.	Architect, QA Lead, Security Owner, Accounting Owner hoặc Business Owner theo phạm vi.
QG-DL-010	Phân loại severity và priority	Severity phản ánh mức hại nếu lỗi xảy ra; priority phản ánh thứ tự xử lý. Cả hai có lý do gắn với bằng chứng, không dựa vào chức danh người yêu cầu.	Có nhãn nhưng lý do chưa đủ.	Gán Critical hoặc yêu cầu hotfix khi chưa có bằng chứng về tác động; hoặc hạ mức lỗi để né escalation.	QA Lead, Product Owner và Technical Lead cùng rà soát.

Quy tắc quyết định: tất cả QG-DL-001 đến QG-DL-010 phải PASS mới cho phép record đi tiếp vào luồng review trước baseline. Một FAIL giữ record ở trạng thái cần chỉnh sửa và không được đóng defect. Một STOP dừng phân loại, giao việc, chia sẻ evidence rộng hơn hoặc đề xuất triển khai cho đến khi owner có thẩm quyền xử lý điểm chặn. Escalation phải giữ nguyên defectId, liên kết nguồn và bằng chứng gốc; không thay bằng diễn giải miệng.

Ranh giới nguồn: BABOK Guide Version 3 hỗ trợ thuật ngữ và thực hành BA; ISTQB CTFL Syllabus v4.0.1 hỗ trợ thuật ngữ kiểm thử. ISO/IEC/IEEE 29148:2018 chỉ được dùng theo abstract và trạng thái thư mục công khai nếu chưa kiểm tra văn bản có giấy phép. Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật 55/2010/QH12 cần Legal Owner, Accounting Owner hoặc domain owner xác minh trước khi biến thành yêu cầu hệ thống.

Phạm vi kiểm tra chất lượng Senior BA cho bản ghi lỗi Nova Foods

Senior BA (Business Analyst cấp cao) kiểm tra bản ghi lỗi trước baseline để bảo đảm lỗi có thể hiểu, tái tạo, giao cho đúng người và truy ngược về nguồn. 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 xác nhận vận hành ERP thật hay tuân thủ thực tế.

Khía cạnh	Câu hỏi kiểm tra	Bằng chứng cần có	Ranh giới quyết định
Tính đầy đủ	Bản ghi có ID, tiêu đề, mô tả, bước tái tạo, kết quả thực tế, kết quả mong đợi, mức độ, môi trường, người sở hữu và liên kết không?	Nội dung Tier 3 trong /03-templates/TMPL-TST-003_DEFECT_LOG.md	Senior BA kiểm tra cấu trúc; QA xác nhận lỗi tái tạo được.
Tính nhất quán	Tên chức năng, trạng thái, dữ liệu, tiền tệ VND, locale vi-VN và thời gian Asia/Ho_Chi_Minh có khớp cùng một case không?	Bản ghi lỗi, payload, ảnh chụp hoặc log tổng hợp	Không đổi thuật ngữ Nova Foods, ID canonical hay trạng thái nguồn để làm dữ liệu “khớp”.
Khả năng kiểm thử	Người kiểm thử độc lập có thể lặp lại bước, dùng đúng dữ liệu tổng hợp và quan sát chênh lệch xác định không?	Tiền điều kiện, bước, dữ liệu đầu vào, kết quả mong đợi, kết quả thực tế	“Không hoạt động” không đủ; phải chỉ rõ hành vi nào sai so với test basis.
Truy vết	Lỗi liên kết tới requirement, business rule, test case, test run, evidence và nguồn gốc quyết định chưa?	ID và đường dẫn canonical từ TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY khi có	Không tạo ID mới hoặc tự suy diễn liên kết thiếu nguồn.
Thẩm quyền nguồn	Kết quả mong đợi đến từ nguồn nào, nguồn đó có quyền quyết định loại nội dung này không?	Requirement được kiểm soát, rule catalog, đặc tả API, tài liệu UI hoặc nguồn chuẩn	BABOK Guide hỗ trợ thuật ngữ BA; ISTQB CTFL hỗ trợ thuật ngữ kiểm thử; không thay thế rule nghiệp vụ Nova Foods.
Ownership	Owner xử lý lỗi, người báo lỗi, người tái kiểm, người quyết định nghiệp vụ và vai trò chuyên môn có phân biệt không?	Trường owner và trách nhiệm từng vai trò	Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì artifact, không xác nhận sửa lỗi, baseline hay approval.
Bảo mật và riêng tư	Evidence có chứa dữ liệu cá nhân, bí mật xác thực, token, mật khẩu, URL nội bộ hoặc dữ liệu thật không?	Phân loại evidence, bản che dữ liệu, payload tổng hợp	Không đưa bí mật vào defect log. Áp dụng nguyên tắc OWASP ASVS và OWASP API Security Top 10 như good practice, không coi là luật Việt Nam.
Pháp lý	Lỗi có dẫn chiếu yêu cầu bảo vệ dữ liệu cá nhân, hóa đơn, kế toán hoặc an toàn thực phẩm không?	URL nguồn pháp lý chính thức, nhãn Verification required, Legal Owner xác minh	Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật 55/2010/QH12 cần vai trò có thẩm quyền diễn giải.
Kế toán	Lỗi có ảnh hưởng số tiền VND, thuế, bút toán, hóa đơn, tồn kho hoặc kỳ chốt sổ không?	Ví dụ số liệu tổng hợp, rule nguồn, đánh giá Accounting Owner	Senior BA không kết luận cách hạch toán, thuế hay tính hợp lệ hóa đơn.
Ảnh hưởng thay đổi	Sửa lỗi có thể đổi rule, dữ liệu, API, phân quyền, báo cáo, test case hoặc tài liệu nào?	Danh sách artifact ảnh hưởng và traceability link	Không coi bản sửa cục bộ là an toàn khi chưa rà soát liên kết ngược và xuôi.

Áp dụng vào ví dụ Nova Foods đã hoàn thành trong Tier 3 và Tier 4 của /03-templates/TMPL-TST-003_DEFECT_LOG.md: metadata corpus có thể đối chiếu trực tiếp với IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh và VND. Bằng chứng cho kết luận này là metadata đã được kiểm soát trong các artifact nguồn. Suy luận kiểm tra là: bản ghi lỗi dùng cùng bối cảnh quản trị thì không được gán trạng thái BASELINED, APPROVED hoặc production-ready.

Các nội dung về rule nghiệp vụ, dữ liệu logic, requirement, test case, evidence kỹ thuật, owner xử lý và tác động thay đổi chỉ được xác nhận khi Tier 3/Tier 4 có liên kết canonical tương ứng. Lý do: CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY đang ở IN_REVIEW; các artifact này không cấp thẩm quyền diễn giải pháp lý, kế toán, bảo mật hoặc vận hành.

Bất kỳ ví dụ lỗi nào có dữ liệu cá nhân, số hóa đơn, bút toán, thuế, truy xuất nguồn gốc thực phẩm hoặc yêu cầu thu hồi đều phải giữ nhãn Verification required hoặc project assumption cho đến khi Legal Owner, Accounting Owner, Security Owner và domain owner xác minh theo phạm vi của họ. Đây là ranh giới kiểm soát, không phải kết luận tuân thủ cho Nova Foods mô phỏng.

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

Đối tượng rà soát: hồ sơ lỗi đã hoàn thành trong /03-templates/TMPL-TST-003_DEFECT_LOG.md; Nova Foods Trading & Manufacturing là case học liệu mô phỏng, mọi dữ liệu là tổng hợp. Quality Gate là điểm kiểm soát trước baseline: Senior BA đối chiếu từng thông tin với nguồn có thẩm quyền, không tự biến nhận định thành phê duyệt.

Mã kiểm	Nội dung đối chiếu và cầu nối bằng chứng	Kết quả	Phát hiện ghi nhận	Hành động trước baseline
QG-DEF-001	Kiểm tra đủ trường lỗi: ID, tiêu đề, module, môi trường, mức độ, ưu tiên, bước tái hiện, kết quả kỳ vọng, kết quả thực tế, bằng chứng, owner và trạng thái. Một defect chỉ test được khi người khác tái hiện được từ dữ liệu ghi nhận.	FAIL	Không có hồ sơ Tier 3 hoàn chỉnh trong đầu vào micro-batch để đối chiếu từng trường và từng giá trị tổng hợp.	STOP. Không đánh dấu defect đủ thông tin.
QG-DEF-002	Đối chiếu ID defect, ID yêu cầu, ID quy tắc nghiệp vụ và ID test với /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Traceability là khả năng lần từ lỗi về yêu cầu, quy tắc và kiểm thử đã phát hiện lỗi.	STOP	Không có ID hồ sơ lỗi, ID test, ID requirement hoặc ID rule cụ thể được cung cấp; không thể xác nhận liên kết canonical.	Escalate đến Principal IT Business Analyst / Technical Curriculum Author để lấy liên kết đã đăng ký; không tạo ID thay thế.
QG-DEF-003	So khớp kỳ vọng với /01-curriculum/CANONICAL_BUSINESS_RULES.md và dữ liệu với /01-curriculum/CANONICAL_DATA_DICTIONARY.md. Kết quả kỳ vọng không được dựa vào suy đoán của người ghi lỗi.	STOP	Nội dung rule và data field áp dụng cho defect chưa có trong phạm vi bằng chứng hiện có.	Giữ nhận định ở mức chưa xác minh; yêu cầu artifact canonical chỉ rõ rule và field liên quan.
QG-DEF-004	Kiểm tra tính nhất quán giữa severity, priority, impact và owner. Severity là mức độ hại khi lỗi xảy ra; priority là thứ tự cần xử lý. Hai giá trị có thể khác nhau nhưng phải có lý do.	FAIL	Không có giá trị severity, priority, impact hoặc owner của case hoàn chỉnh để so sánh.	Không phân loại mức xử lý và không gán trách nhiệm cá nhân.
QG-DEF-005	Kiểm tra testability theo ISTQB CTFL: bước tái hiện, test data, expected result và actual result phải quan sát được, lặp lại được, phân biệt rõ pass/fail.	FAIL	Không có payload, ảnh chụp, log, thời điểm thực hiện hoặc kết quả quan sát của case để tái kiểm.	STOP phát hành test evidence; bổ sung bằng chứng tổng hợp có che dữ liệu nhạy cảm.
QG-DEF-006	Kiểm tra nguồn authority. BABOK Guide chỉ hỗ trợ thuật ngữ BA; ISTQB CTFL hỗ trợ thuật ngữ kiểm thử; nguồn này không xác nhận rule ERP Nova Foods.	PASS có điều kiện	Ranh giới nguồn đã rõ: corpus ở IN_REVIEW, v0.9.0, ngày 2026-08-07; không có nguồn nào được dùng để khẳng định vận hành thực tế.	Giữ nguyên phân loại học liệu mô phỏng và nguồn tham chiếu.
QG-DEF-007	Kiểm tra ownership. BA ghi nhận và giữ traceability; QA xác nhận tái hiện; Business Owner xác nhận tác động nghiệp vụ; Architect xác nhận tác động kỹ thuật.	STOP	Không có bằng chứng phân công hoặc xác nhận từ các vai trò có thẩm quyền.	Escalate theo từng ranh giới vai trò; Senior BA không thay vai trò khác kết luận.
QG-DEF-008	Kiểm tra dữ liệu cá nhân, bảo mật và API. Nếu bằng chứng chứa tên, số điện thoại, email, token, mật khẩu, URL nội bộ hoặc log định danh thì phải giảm thiểu và kiểm soát truy cập. Luật 91/2025/QH15, Nghị định 356/2025/NĐ-CP và OWASP chỉ tạo điểm kiểm tra; yêu cầu hệ thống cần Legal Owner và Security xác minh.	PASS có điều kiện	Đầu vào chỉ nêu dữ liệu tổng hợp, không chứa dữ liệu cá nhân hoặc bí mật kỹ thuật cụ thể. Không thể kết luận tuân thủ pháp lý hay bảo mật cho hệ thống thực.	Không đưa dữ liệu thật vào defect log; escalation ngay nếu evidence sau này chứa dữ liệu nhạy cảm.
QG-DEF-009	Kiểm tra biên kế toán, hóa đơn và an toàn thực phẩm. Mọi tác động đến ghi nhận kế toán, chứng từ, truy xuất lô hoặc thu hồi phải được Accounting Owner, Legal Owner và domain owner xác minh.	PASS có điều kiện	Chưa có defect cụ thể để xác định có chạm Luật Kế toán, Nghị định 123/2020/NĐ-CP hoặc Luật An toàn thực phẩm hay không.	Không suy diễn nghĩa vụ pháp lý hoặc kế toán từ template.
QG-DEF-010	Kiểm tra change impact: lỗi có thể ảnh hưởng requirement, rule, data field, API, báo cáo, phân quyền hoặc regression test. Không có phân tích tác động thì không biết phạm vi sửa và kiểm thử lại.	STOP	Không có liên kết case cụ thể nên không thể lập impact assessment.	Yêu cầu map ảnh hưởng trước khi đề xuất baseline.

Kết luận ghi nhận: Quality Gate chưa đạt điều kiện pre-baseline cho ví dụ Nova Foods vì thiếu hồ sơ Tier 3 và liên kết traceability cụ thể để kiểm chứng. Trạng thái corpus vẫn là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh. Bảng này ghi nhận finding và điểm dừng; không xác nhận approval, baseline, compliance, readiness production hoặc quyết định vận hành.

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

6.1 Đối chiếu liên tệp cho TMPL-TST-003

Đối chiếu liên tệp nhằm phát hiện mâu thuẫn trước khi defect log được dùng làm đầu vào kiểm thử, phân tích nguyên nhân hoặc đánh giá tác động. “Canonical” nghĩa là nguồn chuẩn duy nhất được phép quyết định cách viết ID, định nghĩa dữ liệu hoặc quy tắc; template không được tự tạo nguồn chuẩn thứ hai. 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 kiểm tra	Nguồn đối chiếu bắt buộc	Kết quả đối chiếu tại IN_REVIEW	Quy tắc áp dụng cho TMPL-TST-003
Metadata quản trị	/01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Nhất quán: IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND, Nova Foods mô phỏng.	Không ghi APPROVED, BASELINED, production-ready, compliant hoặc user-approved trong record lỗi.
Định danh template	/01-curriculum/TEMPLATE_MANIFEST.md	Tên tệp hiện hành là /03-templates/TMPL-TST-003_DEFECT_LOG.md; ID template là TMPL-TST-003.	Giữ nguyên ID và filename trong metadata, evidence, liên kết traceability và lịch sử thay đổi. Không dùng biến thể như TST-003, DEFECT_LOG hoặc tên dịch thay thế.
ID liên kết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Registry là nguồn chuẩn cho ID requirement, rule, data, test, API, security và traceability. Seed không cung cấp ID case cụ thể cho defect record.	Tier 2 dùng placeholder dạng <CANONICAL-ID>; Tier 3 chỉ ghi ID đã tồn tại trong registry. Không tự cấp ID để làm đầy record.
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Catalog quy tắc là nguồn chuẩn; chưa có quy tắc Nova Foods cụ thể trong seed được phép chép vào defect log.	Trường “Business rule affected” phải tham chiếu đúng canonical rule ID và nguyên văn phạm vi đã đăng ký; không biến diễn giải của tester thành quy tắc mới.
Định nghĩa dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Data dictionary là nguồn chuẩn cho tên trường logic, ý nghĩa, kiểu dữ liệu, phân loại và ràng buộc dữ liệu.	Payload, expected result và evidence chỉ dùng tên trường đã đăng ký. Không suy diễn kiểu dữ liệu, dữ liệu cá nhân, retention hoặc quyền truy cập từ tên trường.
Chapter và template liên quan	/01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md	Manifest quản lý quan hệ curriculum và template; defect log là artifact hỗ trợ kiểm thử, không thay requirement, acceptance criteria, test case hoặc quyết định sửa lỗi.	Record lỗi phải liên kết tới test basis có sẵn. Nếu test basis không tồn tại, log chỉ ghi thiếu bằng chứng; không tự viết acceptance criterion.
Downstream consumer	Consumer mô phỏng: QA review, regression test, phân tích tác động requirement/rule/data/API/report/phân quyền.	Consumer chỉ nhận finding có evidence và liên kết canonical; không được coi defect log là lệnh triển khai hoặc phê duyệt thay đổi.	Không chuyển severity, priority, workaround hoặc proposed fix thành quyết định Business Owner, Architect, Security, Legal Owner hoặc Accounting Owner.
Boundary nguồn ngoài	ISTQB CTFL Syllabus v4.0.1; OWASP ASVS 5.0.0; OWASP API Security Top 10 2023; nguồn pháp lý đã liệt kê tại /00-research/00_SOURCE_MAP.md	ISTQB hỗ trợ thuật ngữ kiểm thử. OWASP là chuẩn thực hành ngành. Nguồn pháp lý là nguồn chính thức nhưng mọi suy diễn yêu cầu hệ thống cần role có thẩm quyền xác minh.	Không gọi OWASP là luật Việt Nam. Không kết luận tuân thủ pháp lý, kế toán, hóa đơn, an toàn thực phẩm, riêng tư hoặc bảo mật chỉ từ defect record.

6.2 Tiêu chí phát hiện mâu thuẫn

Một liên kết bị coi là mâu thuẫn khi cùng một khái niệm có hai nguồn chuẩn khác nhau, ID không khớp registry, filename khác manifest, hoặc defect record khẳng định điều vượt quá thẩm quyền template. Ví dụ, record ghi một field là dữ liệu cá nhân nhưng /01-curriculum/CANONICAL_DATA_DICTIONARY.md chưa phân loại field đó: đây là thiếu căn cứ, không phải quyền để tester tự cập nhật data dictionary. Evidence hợp lệ phải chỉ ra nguồn, ID, phiên bản và quan sát tổng hợp; suy luận phải nối từ evidence tới finding, không dựa vào nhận định cá nhân.

Kết quả đối chiếu trong phạm vi source seed: không thấy mâu thuẫn metadata giữa manifest, registry, canonical catalog và template context. Kết quả này chỉ xác nhận nhất quán của thông tin đã cung cấp, không xác nhận đầy đủ toàn corpus, không xác nhận chất lượng chuyên môn và không tạo baseline. Mọi artifact tham chiếu tiếp tục giữ IN_REVIEW, v0.9.0, ngày 2026-08-07.

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

Danh sách này là điểm bàn giao có kiểm soát cho TMPL-TST-003. “Vấn đề mở” là mâu thuẫn hoặc thiếu đầu vào chặn kết luận; “giả định dự án” là điều tạm dùng để dạy và kiểm thử mô phỏng; “cần xác minh” là nội dung không được nâng thành quy tắc bắt buộc trước khi đúng người có thẩm quyền kiểm tra. Bằng chứng: toàn corpus đang IN_REVIEW, v0.9.0, ngày 2026-08-07, chưa có baseline hoặc approval; Nova Foods là case mô phỏng, chỉ dùng dữ liệu tổng hợp.

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	Hành động kế tiếp
Vấn đề mở	Chưa có baseline reference cho template hoặc nguồn đầu vào. Bằng chứng: CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES đều ghi IN_REVIEW và chưa baseline.	TMPL-TST-003; /03-templates/TMPL-TST-003_DEFECT_LOG.md; /01-curriculum/TEMPLATE_MANIFEST.md	Principal IT Business Analyst / Technical Curriculum Author	Không được gọi defect log là biểu mẫu đã chốt hoặc dùng làm căn cứ triển khai.	Giữ trạng thái IN_REVIEW; chỉ liên kết revision được ghi nhận trong artifact kiểm soát.
Vấn đề mở	Chưa có approval reference cho nội dung defect, mức độ lỗi, ưu tiên hay quyết định đóng lỗi. Bằng chứng: metadata các artifact upstream phủ định approval ngầm định.	TMPL-TST-003; TEMPLATE_MANIFEST	Business Owner, QA Owner và Principal IT Business Analyst / Technical Curriculum Author	Không được suy diễn rằng Business Owner, QA hoặc người dùng đã chấp nhận defect hay quyết định release.	Ghi quyết định tương lai cùng vai trò quyết định, ngày theo Asia/Ho_Chi_Minh và tham chiếu approval thực tế; trước đó chỉ ghi nhận trạng thái review.
Giả định dự án	Nova Foods Trading & Manufacturing là tổ chức mô phỏng giáo dục; mọi mã, người, giao dịch, lỗi và bằng chứng trong defect log là dữ liệu tổng hợp. Bằng chứng: metadata của manifest và registry quy định rõ phạm vi này.	TMPL-TST-003; CHAPTER_MANIFEST; TEMPLATE_MANIFEST; TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	Cấm dùng log làm hồ sơ sự cố thật, bằng chứng audit thật hoặc thông tin doanh nghiệp thật.	Duy trì nhãn “mô phỏng giáo dục, dữ liệu tổng hợp” khi tạo mọi Tier 3 record.
Giả định dự án	Ngữ cảnh ghi nhận dùng vi-VN, Asia/Ho_Chi_Minh, VND. Bằng chứng: metadata curriculum và registry đặt các giá trị này làm locale quản trị corpus.	TMPL-TST-003; 01_CURRICULUM_ARCHITECTURE; TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	Sai locale có thể làm sai ngày, giờ, định dạng tiền và tái lập bằng chứng kiểm thử.	Ghi timestamp theo Asia/Ho_Chi_Minh; không suy diễn quy tắc kế toán hoặc làm tròn tiền từ ký hiệu VND.
Cần xác minh	Mọi tác động về bảo vệ dữ liệu cá nhân phải do Legal/Privacy Owner xác minh. Bằng chứng: Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn chính thức, nhưng seed cấm suy diễn yêu cầu hệ thống chưa đối chiếu văn bản hiện hành.	TMPL-TST-003; CANONICAL_DATA_DICTIONARY; CANONICAL_BUSINESS_RULES	Legal Owner / Privacy Owner	Không được phân loại defect là tuân thủ pháp lý, không được kết luận dữ liệu mô phỏng đáp ứng nghĩa vụ pháp lý.	Legal/Privacy Owner đối chiếu nội dung defect với văn bản chính thức; ghi kết quả và phạm vi xác minh tại artifact kiểm soát.
Cần xác minh	Tác động hóa đơn, chứng từ, kế toán hoặc thuế phải do Accounting Owner và Legal Owner xác minh. Bằng chứng: Luật 88/2015/QH13 và Nghị định 123/2020/NĐ-CP yêu cầu diễn giải thuộc thẩm quyền chuyên môn; source seed yêu cầu kiểm tra sửa đổi trước production.	TMPL-TST-003; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Accounting Owner; Legal Owner	Không được gán severity dựa trên kết luận kế toán/thuế chưa xác minh.	Chỉ mô tả hành vi quan sát được và dữ liệu test; chuyển câu hỏi diễn giải sang hai Owner nêu trên.
Cần xác minh	Tác động truy xuất nguồn gốc, an toàn thực phẩm hoặc thu hồi phải do Domain Owner và Legal Owner xác minh. Bằng chứng: Luật 55/2010/QH12 là ngữ cảnh nguồn gốc, không tự tạo rule Nova Foods.	TMPL-TST-003; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY	Food Safety Domain Owner; Legal Owner	Không được ghi defect là vi phạm an toàn thực phẩm hoặc kích hoạt thu hồi.	Ghi defect dưới dạng quan sát kiểm thử; Domain Owner xác nhận ý nghĩa nghiệp vụ và Legal Owner xác nhận phạm vi pháp lý.
Cần xác minh	Phân loại bảo mật, quyền truy cập và API phải do Security Owner và Architect xác minh. Bằng chứng: OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 là good practice, không phải luật Việt Nam; OAS 3.1.1 chỉ chuẩn hóa mô tả API.	TMPL-TST-003; CANONICAL_DATA_DICTIONARY; TRACEABILITY_ID_REGISTRY	Security Owner; Architect	Không được gọi defect là lỗ hổng đã xác nhận, cũng không được tự áp đặt kiến trúc hoặc kiểm soát production.	Đính kèm bằng chứng test tổng hợp, endpoint mô phỏng nếu có, và chuyển đánh giá rủi ro cho Security Owner cùng Architect.

Quy tắc xử lý: một mục chạm từ hai thẩm quyền trở lên phải escalation ngay; Principal IT Business Analyst / Technical Curriculum Author chỉ lập gói vấn đề, giữ liên kết ID và lịch sử thay đổi. Không vai trò nào trong bảng tự tạo baseline, approval, kết luận pháp lý, kết luận kế toán, xác nhận compliance hoặc quyền dùng production.

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

Bàn giao có kiểm soát nghĩa là chuyển gói thông tin để vai trò nhận xử lý, không chuyển quyền phê duyệt. Gói bàn giao của /03-templates/TMPL-TST-003_DEFECT_LOG.md giữ Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh, locale vi-VN, tiền tệ mô phỏng VND. Nova Foods Trading & Manufacturing là case học liệu mô phỏng; mọi dữ liệu là tổng hợp. Bàn giao không tạo baseline, approval, xác nhận lỗi production, kết luận pháp lý, kế toán, bảo mật hay vận hành.

Thành phần bàn giao	Nguồn kiểm soát	Vai trò nhận	Kết quả được phép
Template defect log	/03-templates/TMPL-TST-003_DEFECT_LOG.md	QA Reviewer và Principal IT Business Analyst / Technical Curriculum Author	Review cấu trúc, truy vết, mức độ đầy đủ test evidence
Định danh truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Principal IT Business Analyst / Technical Curriculum Author	Kiểm tra ID giữ nguyên, không tái sử dụng, không tự sinh ID canonical
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Business Owner; Legal Owner, Accounting Owner hoặc Compliance Owner khi thuộc phạm vi họ	Xác minh nghĩa nghiệp vụ; không suy diễn rule vận hành từ defect record
Định nghĩa dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Data Owner và Architect	Xác minh tên trường, kiểu dữ liệu, giá trị hợp lệ, quan hệ dữ liệu
Danh mục template	/01-curriculum/TEMPLATE_MANIFEST.md	Principal IT Business Analyst / Technical Curriculum Author	Xác minh filename, Template ID, dependency và phạm vi template

Thay đổi chỉ bắt đầu khi người ghi nhận lập bản ghi thay đổi có: lý do, artifact nguồn, ID bị ảnh hưởng, nội dung trước và sau, tác động traceability, vai trò cần review, thời điểm theo Asia/Ho_Chi_Minh. Bằng chứng suy luận phải nối đủ ba điểm: điều quan sát trong defect log, nguồn canonical liên quan, tác động cụ thể lên requirement, test case, dữ liệu hoặc tài liệu nhận bàn giao. Không đổi ID để che lịch sử; không sửa im lặng bản ghi, evidence, filename hay liên kết nguồn.

Loại thay đổi	Lan truyền bắt buộc	Ranh giới thẩm quyền
Sửa mô tả defect, expected result hoặc actual result	Cập nhật liên kết test evidence và test basis liên quan	QA Reviewer xác minh chất lượng kiểm thử; không xác nhận rule nghiệp vụ
Sửa business rule hoặc acceptance criterion	Đánh giá lại defect, test case, requirement traceability và CANONICAL_BUSINESS_RULES	Business Owner xác nhận nghĩa nghiệp vụ; Principal IT Business Analyst / Technical Curriculum Author chỉ điều phối truy vết
Sửa trường dữ liệu, danh mục giá trị hoặc định dạng	Đánh giá lại defect payload, test data và CANONICAL_DATA_DICTIONARY	Data Owner và Architect xác minh; không tự diễn giải thành thiết kế production
Tác động dữ liệu cá nhân, hóa đơn, kế toán, an toàn thực phẩm hoặc bảo mật	Giữ nhãn Verification required; chuyển đúng owner chuyên môn	Legal Owner, Accounting Owner, Compliance Owner, Security hoặc domain owner đưa kết luận thuộc thẩm quyền

Không được đóng defect, đổi severity, đổi priority, gắn APPROVED, BASELINED, compliant hoặc production-ready chỉ vì đã bàn giao. Principal IT Business Analyst / Technical Curriculum Author duy trì gói bàn giao, version, lịch sử và liên kết; QA Reviewer đánh giá bằng chứng kiểm thử; Business Owner quyết định nghiệp vụ; Architect quyết định kiến trúc; các owner pháp lý, kế toán, bảo mật và tuân thủ quyết định phạm vi chuyên môn. Khi một thay đổi chạm từ hai thẩm quyền trở lên, giữ IN_REVIEW, bảo toàn bản ghi hiện có và escalation kèm gói tác động liên artifact.