Tmpl Tst 002 Test Data
| Trường kiểm soát | Giá trị |
|---|---|
| Artifact ID | TMPL-TST-002 |
| Tên tệp được kiểm soát | /03-templates/TMPL-TST-002_TEST_DATA.md |
| Tiêu đề artifact | Tmpl Tst 002 Test Data |
| 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 | Controlled template bốn tầng cho dữ liệu kiểm thử |
| Case study | Nova Foods Trading & Manufacturing — mô phỏng giáo dục |
| Baseline reference | Chưa có baseline reference tại v0.9.0. IN_REVIEW không phải BASELINED. |
| Approval reference | Chưa có approval reference. Metadata, lịch sử thay đổi, Owner hoặc nội dung review không tạo approval ngầm định. |
Trách nhiệm Owner: Owner duy trì đúng TMPL-TST-002, đường dẫn, trạng thái, phiên bản, ngày cập nhật và lịch sử thay đổi. Owner bảo toàn ranh giới dữ liệu mô phỏng, không sửa im lặng nội dung đã có lịch sử kiểm soát, và ghi nhận thay đổi bằng phiên bản cùng dòng lịch sử mới.
Giới hạn thẩm quyền Owner: Owner không tự xác nhận baseline, approval, chất lượng kiểm thử, yêu cầu Nova Foods, tuân thủ pháp lý, quyết định kế toán, bảo mật hay quyền dùng production. IN_REVIEW nghĩa là đang được xem xét có kiểm soát; không nghĩa là đã đúng, đã hoàn tất, đã được chấp thuận, compliant hoặc production-ready.
Ranh giới dữ liệu mô phỏng: Nova Foods Trading & Manufacturing là case study mô phỏng. Mọi mã khách hàng, mã hàng, lô hàng, số tiền VND, ngày giao dịch, người dùng, payload, kết quả kiểm thử và bằng chứng trong artifact này phải là dữ liệu tổng hợp. Không nhập dữ liệu cá nhân thật, dữ liệu khách hàng thật, bí mật thương mại, khóa truy cập, số hóa đơn thật, cấu hình ERP thật hoặc bằng chứng production. Dữ liệu tổng hợp chỉ minh họa cách thiết kế và kiểm soát dữ liệu kiểm thử; không chứng minh Nova Foods tồn tại, đang vận hành ERP, đã đáp ứng quy định hoặc đã kiểm thử thành công.
| Version | Ngày | Thay đổi | Người ghi nhận | Trạng thái kiểm soát |
|---|---|---|---|---|
v0.9.0 |
2026-08-07 |
Khởi tạo metadata quản trị cho /03-templates/TMPL-TST-002_TEST_DATA.md; đặt IN_REVIEW; thiết lập ranh giới Nova Foods mô phỏng và dữ liệu tổng hợp. |
Principal IT Business Analyst / Technical Curriculum Author | Chưa baseline; chưa có approval |
1. Tier 1 ? Metadata, Purpose, and Governance
Mục đích, điều kiện sử dụng và thẩm quyền
TMPL-TST-002 là mẫu Test Data (dữ liệu kiểm thử): dữ liệu đầu vào, dữ liệu điều kiện và kết quả mong đợi dùng để chứng minh test case kiểm tra được yêu cầu, quy tắc nghiệp vụ hoặc xử lý lỗi. Mẫu tách dữ liệu kiểm thử khỏi dữ liệu thật để người học biết rõ giá trị nào được nhập, vì sao được chọn và kết quả nào phải được quan sát. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi tên khách hàng, mã hàng, lô hàng, số tiền VND, tài khoản và payload API trong mẫu phải là dữ liệu tổng hợp.
| Nội dung | Quy định kiểm soát |
|---|---|
| Mục đích | Ghi nhận dữ liệu kiểm thử có thể tái lập, liên kết được với test case và căn cứ kiểm thử. Mỗi bộ dữ liệu phải hỗ trợ ít nhất một điều kiện kiểm tra cụ thể, không tạo dữ liệu chỉ để minh họa. |
| Khi dùng | Dùng sau khi đã có test basis, tức căn cứ kiểm thử như requirement, acceptance criteria, business rule, data rule, API contract hoặc UI behavior. Dùng khi cần kiểm tra luồng hợp lệ, biên dữ liệu, dữ liệu không hợp lệ, phân quyền, trạng thái nghiệp vụ, tích hợp hoặc truy vết lô hàng mô phỏng. |
| Khi không dùng | Không dùng thay cho test case, requirement, data dictionary, migration plan, cấu hình ERP hoặc hồ sơ dữ liệu production. Không nhập dữ liệu cá nhân thật, dữ liệu tài chính thật, bí mật thương mại, token, mật khẩu, khóa API hoặc dữ liệu lấy từ môi trường production. |
| Owner | Principal IT Business Analyst / Technical Curriculum Author duy trì cấu trúc mẫu, định danh, version, liên kết traceability và ranh giới dữ liệu mô phỏng. Owner không xác nhận dữ liệu là hợp lệ cho vận hành Nova Foods thực tế. |
| Người tiêu thụ | BA dùng để làm rõ điều kiện dữ liệu; QA/Test Analyst dùng để chuẩn bị và chạy test; Developer dùng để tái hiện lỗi; Data/Integration Analyst dùng để kiểm tra payload và mapping; Business Owner, Accounting Owner, Legal Owner, Security Owner và Architect chỉ xem xét phần thuộc thẩm quyền chuyên môn của họ. |
| Điều kiện đầu vào | Phải có ID test case hoặc ID căn cứ kiểm thử đã đăng ký; mục tiêu kiểm tra; quy tắc xác định kết quả mong đợi; phân loại dữ liệu; môi trường mô phỏng; và quyết định rõ dữ liệu là hợp lệ, không hợp lệ, biên hoặc ngoại lệ. Thiếu một trong các điều kiện này thì chưa tạo bộ test data, vì không thể chứng minh giá trị dữ liệu phục vụ kiểm tra nào. |
| Artifact đầu ra liên quan | Test case, test execution record, defect record, requirements traceability matrix, evidence log và test summary có thể tham chiếu bộ dữ liệu này. Các artifact đó không được suy diễn requirement mới từ một giá trị test data đơn lẻ. |
| Nguyên tắc kết quả mong đợi | Kết quả mong đợi phải xuất phát từ căn cứ đã liên kết. Ví dụ, giá trị âm bị từ chối chỉ được ghi nếu test basis nêu điều kiện đó; không được biến giả định của người viết thành quy tắc Nova Foods. |
Quy tắc quyết định: dùng dữ liệu đại diện khi cần xác nhận luồng thông thường; dùng dữ liệu biên khi cần kiểm tra giá trị nhỏ nhất, lớn nhất hoặc điểm chuyển trạng thái; dùng dữ liệu không hợp lệ khi cần xác nhận hệ thống từ chối hoặc báo lỗi đúng cách. Mỗi lựa chọn phải ghi cầu nối suy luận: căn cứ kiểm thử nào yêu cầu điều kiện nào, dữ liệu nào kích hoạt điều kiện đó, và quan sát nào xác nhận kết quả.
| Tình huống | Thẩm quyền quyết định | Hành động escalation |
|---|---|---|
| Không có requirement, acceptance criteria hoặc business rule làm căn cứ | Business Owner hoặc BA phụ trách requirement | Dừng tạo expected result; ghi vấn đề để làm rõ căn cứ. |
| Dữ liệu liên quan thuế, hạch toán, hóa đơn hoặc chứng từ | Accounting Owner và Legal Owner | Gắn Verification required; không diễn giải quy định pháp luật thành expected result. |
| Dữ liệu chứa thông tin cá nhân, quyền truy cập, API security hoặc phân loại bảo mật | Security Owner, Legal Owner hoặc Privacy Owner | Không ghi dữ liệu nhạy cảm; thay bằng dữ liệu tổng hợp; escalation phạm vi và cách che giấu dữ liệu. |
| Bộ dữ liệu đòi hỏi thay đổi schema, integration contract hoặc cấu hình ERP | Architect hoặc Technical Owner | Không tự xác lập field, mapping hay behavior kỹ thuật; gửi impact và liên kết test basis. |
| Kết quả chạy test mâu thuẫn với expected result | QA/Test Lead cùng Owner của test basis | Lập defect hoặc yêu cầu làm rõ; không sửa im lặng dữ liệu hay expected result. |
Thẩm quyền của Owner chỉ là quản trị học liệu và traceability. IN_REVIEW không là baseline, approval, xác nhận tuân thủ, quyết định nghiệp vụ hoặc quyền dùng dữ liệu cho production.
Ánh xạ Manifest, Định danh Canonical, Nguồn và Kiểm soát Thay đổi
/03-templates/TMPL-TST-002_TEST_DATA.md thuộc thư viện template có kiểm soát của corpus Nova Foods. Template này dùng TMPL-TST-002 làm định danh canonical. Không dùng biến thể như TST-002, TEST-DATA-002 hoặc tên dịch tiếng Việt làm khóa truy vết, vì TRACEABILITY_ID_REGISTRY quy định ID canonical ngăn nhầm lẫn giữa artifact, bản sao và bản xuất.
| Hạng mục ánh xạ | Giá trị canonical | Căn cứ và giới hạn dùng |
|---|---|---|
| Template ID | TMPL-TST-002 |
ID template được giữ nguyên trong liên kết, lịch sử thay đổi và evidence. |
| Tệp được kiểm soát | /03-templates/TMPL-TST-002_TEST_DATA.md |
Đường dẫn định danh artifact; bản sao PDF, export hoặc trích đoạn không thay thế tệp này. |
| Manifest nguồn chân lý | /01-curriculum/TEMPLATE_MANIFEST.md |
Manifest xác định danh mục template dự kiến, metadata và boundary dữ liệu mô phỏng. Template không tự tạo vị trí mới ngoài manifest. |
| Registry ID nguồn chân lý | /01-curriculum/TRACEABILITY_ID_REGISTRY.md |
Registry kiểm soát quy ước ID và escalation khi ID mâu thuẫn hoặc bị hiểu thành quyết định nghiệp vụ, pháp lý, kế toán, bảo mật hay vận hành thực. |
| Chapter manifest | /01-curriculum/CHAPTER_MANIFEST.md |
Chỉ liên kết chapter bằng chapter ID và filename đã đăng ký trong manifest. Không tự đặt chapter ID từ tên chủ đề “test data”. |
| Architecture nguồn chân lý | /01-curriculum/01_CURRICULUM_ARCHITECTURE.md |
Architecture kiểm tra chuỗi học từ requirement, acceptance criteria, traceability đến test basis. Test data phải có test basis trước khi được ghi nhận là dữ liệu phục vụ kiểm thử. |
| Quy tắc nghiệp vụ | /01-curriculum/CANONICAL_BUSINESS_RULES.md |
Mỗi giá trị dữ liệu kiểm thử dựa trên rule phải giữ liên kết rule ID canonical; template không tự biến ví dụ thành rule vận hành Nova Foods. |
| Từ điển dữ liệu | /01-curriculum/CANONICAL_DATA_DICTIONARY.md |
Tên trường, kiểu dữ liệu logic, miền giá trị và phân loại dữ liệu phải đối chiếu dictionary khi đã có entry canonical. |
Liên kết chapter dùng nguyên tắc “manifest trước, nội dung sau”. Lý do: CHAPTER_MANIFEST là nguồn kiểm soát cấu trúc 26 chapter, còn template chỉ là artifact tiêu thụ nội dung học. Khi một test-data record tham chiếu kiến thức kiểm thử, tác giả ghi chapter ID đã đăng ký cùng test basis liên quan; không suy diễn số chapter, tên tệp hoặc phạm vi chapter từ ngữ cảnh.
Nguồn thuật ngữ kiểm thử chính là ISTQB CTFL Syllabus v4.0.1: https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf. Nguồn này được dùng cho thuật ngữ như test data (dữ liệu kiểm thử), test basis (cơ sở kiểm thử) và kỹ thuật hộp đen; không dùng để khẳng định quy tắc Nova Foods. Khi test data kiểm tra requirement hoặc acceptance criteria, ISO/IEC/IEEE 29148:2018 chỉ là nguồn tham chiếu về requirements engineering qua https://www.iso.org/standard/72089.html; không trích dẫn clause khi chưa xác minh licensed text.
Mọi tên sản phẩm, khách hàng, lô hàng, mã kho, chứng từ, giá trị VND, dữ liệu cá nhân giả lập và kết quả kiểm thử Nova Foods trong template là dữ liệu tổng hợp cho học liệu. Không được diễn giải chúng là dữ liệu doanh nghiệp thật, cấu hình ERP thật, bằng chứng tuân thủ, quyết định kế toán, quyết định thuế hoặc dữ liệu đủ điều kiện production.
Thay đổi TMPL-TST-002 phải giữ đồng bộ tối thiểu giữa template, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY và artifact được liên kết. Thay đổi ID, filename, source classification, chapter link hoặc traceability link phải có dòng change history mới, ngày theo Asia/Ho_Chi_Minh, version phù hợp và lý do thay đổi. IN_REVIEW tại v0.9.0 không phải baseline hay approval. Nếu thay đổi làm phát sinh nghĩa vụ pháp lý, kế toán, bảo mật, an toàn thực phẩm hoặc quyết định vận hành, dừng cập nhật nội dung kết luận và escalation đến owner chuyên môn có thẩm quyền.
2. Tier 2 ? Blank Copy-Paste-Ready Template
Dùng nguyên mẫu này để lập một hồ sơ dữ liệu kiểm thử. Test data là dữ liệu đầu vào, dữ liệu tham chiếu và dữ liệu kỳ vọng dùng để kiểm tra hệ thống. Mỗi trường dùng placeholder mô tả trong dấu ngoặc nhọn; thay toàn bộ placeholder trước khi chuyển sang Tier 3. Không dùng dữ liệu thật, bí mật thật hoặc dữ liệu cá nhân thật.
2.1. Thông tin hồ sơ
| Trường | Giá trị cần điền | Hướng dẫn |
|---|---|---|
| Test Data Record ID | <ID hồ sơ dữ liệu kiểm thử đã đăng ký> |
Dùng ID canonical từ TRACEABILITY_ID_REGISTRY; không tự tạo biến thể ID. |
| Tên hồ sơ | <tên ngắn nêu đối tượng và mục tiêu kiểm thử> |
Nêu rõ dữ liệu kiểm tra cái gì, ví dụ đơn hàng, tồn kho, lô sản xuất. |
| Trạng thái | <IN_REVIEW hoặc trạng thái canonical được đăng ký> |
Chỉ dùng giá trị trạng thái đã được corpus cho phép. IN_REVIEW không phải phê duyệt hay baseline. |
| Phiên bản | <phiên bản theo quy tắc version của artifact> |
Ghi version đang kiểm soát; không sửa im lặng bản cũ. |
| Ngày cập nhật | <YYYY-MM-DD> |
Diễn giải theo Asia/Ho_Chi_Minh. |
| Locale | <vi-VN hoặc locale được phê duyệt> |
Ghi locale chi phối định dạng ngày, số và văn bản. |
| Múi giờ | <Asia/Ho_Chi_Minh hoặc múi giờ được phê duyệt> |
Bắt buộc khi dữ liệu có thời điểm. |
| Tiền tệ | <VND hoặc tiền tệ được phê duyệt> |
Bắt buộc khi có giá, thuế, công nợ hoặc giá trị tiền. |
| Case study | <tên case study mô phỏng> |
Phải ghi rõ mô phỏng giáo dục, dữ liệu tổng hợp. |
| Owner ghi nhận | <vai trò hoặc định danh người chịu trách nhiệm ghi nhận> |
Owner duy trì hồ sơ, không tự xác nhận approval, pháp lý hay production. |
2.2. Mục tiêu và cơ sở kiểm thử
| Trường | Giá trị cần điền | Hướng dẫn |
|---|---|---|
| Mục tiêu kiểm thử | <hành vi hoặc quy tắc cần được kiểm tra> |
Viết kết quả cần chứng minh, không viết hoạt động mơ hồ như “kiểm tra hệ thống”. |
| Test basis | <ID và tên requirement, business rule, acceptance criterion hoặc tài liệu nguồn> |
Test basis là cơ sở kiểm thử: nguồn xác định điều gì phải được kiểm tra. Chỉ liên kết nguồn đã tồn tại. |
| Lý do chọn dữ liệu | <quan hệ giữa dữ liệu, điều kiện đầu vào và kết quả cần kiểm tra> |
Nêu cầu nối suy luận: dữ liệu nào kích hoạt quy tắc nào, vì sao kết quả kỳ vọng phù hợp. |
| Kỹ thuật thiết kế dữ liệu | <equivalence partitioning, boundary value analysis, decision table, error guessing hoặc kỹ thuật khác> |
Giải thích tiếng Việt lần đầu: ví dụ boundary value analysis là phân tích giá trị biên. Chỉ chọn kỹ thuật phục vụ mục tiêu. |
| Phạm vi chức năng | <module, quy trình hoặc màn hình/API được kiểm tra> |
Không suy diễn cấu hình ERP thật từ tên chức năng mô phỏng. |
| Ngoài phạm vi | <nội dung không được kiểm tra bởi hồ sơ này> |
Nêu ranh giới để tránh dùng dữ liệu này làm bằng chứng cho chức năng khác. |
2.3. Điều kiện và quyết định dữ liệu
| Trường | Giá trị cần điền | Hướng dẫn |
|---|---|---|
| Loại dữ liệu | <master data, transaction data, reference data, negative data, boundary data hoặc kết hợp> |
Chọn mọi loại áp dụng; giải thích nếu kết hợp. |
| Mức nhạy cảm | <PUBLIC, INTERNAL, CONFIDENTIAL, RESTRICTED hoặc phân loại canonical> |
Dữ liệu mô phỏng vẫn phải được phân loại để dạy kiểm soát truy cập. |
| Có dữ liệu cá nhân mô phỏng? | <Có hoặc Không> |
Nếu Có, dùng tên, email, số điện thoại tổng hợp; không sao chép dữ liệu thật. |
| Có bí mật hoặc credential? | <Có hoặc Không> |
Nếu Có, không ghi secret, token, mật khẩu, khóa API hay chuỗi kết nối trong hồ sơ. |
| Cần dữ liệu trước điều kiện? | <Có hoặc Không> |
Nếu Có, lập dòng riêng cho từng bản ghi prerequisite trong bảng dữ liệu. |
| Quyết định reset dữ liệu | <Không cần reset, reset thủ công, reset bằng script kiểm soát hoặc giá trị khác đã đăng ký> |
Nêu cách đưa môi trường về trạng thái lặp lại được; không chạy thao tác hủy dữ liệu ngoài thẩm quyền. |
| Điều kiện dừng | <điều kiện khiến dữ liệu không an toàn, không hợp lệ hoặc không đủ cơ sở để dùng> |
Ví dụ: test basis chưa có ID canonical, nguồn mâu thuẫn, hoặc cần quyết định Legal/Accounting/Security. |
2.4. Bảng tập dữ liệu kiểm thử
| Data Set ID | Vai trò dữ liệu | Đối tượng nghiệp vụ | Trường dữ liệu | Giá trị đầu vào tổng hợp | Định dạng và ràng buộc | Kết quả kỳ vọng | Nguồn giá trị | Ghi chú |
|---|---|---|---|---|---|---|---|---|
<ID tập dữ liệu đã đăng ký> |
<prerequisite, positive, negative, boundary hoặc cleanup> |
<đối tượng như khách hàng, sản phẩm, đơn hàng> |
<tên trường canonical> |
<giá trị tổng hợp cụ thể> |
<kiểu dữ liệu, độ dài, miền giá trị, nullability> |
<giá trị, thông báo, trạng thái hoặc tác động kỳ vọng> |
<ID data dictionary, rule hoặc test basis> |
<lý do và điều kiện sử dụng> |
<ID tập dữ liệu đã đăng ký> |
<prerequisite, positive, negative, boundary hoặc cleanup> |
<đối tượng như khách hàng, sản phẩm, đơn hàng> |
<tên trường canonical> |
<giá trị tổng hợp cụ thể> |
<kiểu dữ liệu, độ dài, miền giá trị, nullability> |
<giá trị, thông báo, trạng thái hoặc tác động kỳ vọng> |
<ID data dictionary, rule hoặc test basis> |
<lý do và điều kiện sử dụng> |
<ID tập dữ liệu đã đăng ký> |
<prerequisite, positive, negative, boundary hoặc cleanup> |
<đối tượng như khách hàng, sản phẩm, đơn hàng> |
<tên trường canonical> |
<giá trị tổng hợp cụ thể> |
<kiểu dữ liệu, độ dài, miền giá trị, nullability> |
<giá trị, thông báo, trạng thái hoặc tác động kỳ vọng> |
<ID data dictionary, rule hoặc test basis> |
<lý do và điều kiện sử dụng> |
Mỗi dòng là một giá trị có thể kiểm tra. Nếu một đối tượng cần nhiều trường, tạo đủ dòng cho mọi trường cần thiết; không gộp giá trị khiến người kiểm thử không thể tái lập đầu vào. Giá trị âm phải vi phạm đúng một điều kiện khi mục tiêu là cô lập lỗi; nếu cố ý vi phạm nhiều điều kiện, ghi rõ lý do trong cột Ghi chú.
2.5. Payload, tệp và tham chiếu bí mật an toàn
| Loại đầu vào | Tên hoặc đường dẫn | Nội dung cần điền | Quy tắc an toàn |
|---|---|---|---|
| API request payload | <tên tệp payload hoặc endpoint mô phỏng> |
<JSON, XML hoặc dữ liệu cấu trúc đầy đủ bằng giá trị tổng hợp> |
Không ghi Authorization, token, cookie phiên, khóa API hoặc secret thật. |
| Tệp nhập liệu | <tên tệp tổng hợp và phần mở rộng> |
<cấu trúc cột, encoding, số dòng và checksum nếu có> |
Tệp không chứa dữ liệu thật; không nhúng mật khẩu vào tên tệp. |
| Secret reference | <vault path, secret ID hoặc biến môi trường không tiết lộ giá trị> |
<mục đích secret và môi trường được phép tham chiếu> |
Mẫu an toàn: ${<TEN_BIEN_MOI_TRUONG>} hoặc <secret-ref:system/path/key>. Không thay placeholder bằng secret. |
| Database reference | <tên môi trường mô phỏng, schema và bảng logic> |
<câu truy vấn đọc hoặc điều kiện dữ liệu cần có> |
Không ghi connection string, mật khẩu hoặc thông tin truy cập production. |
2.6. Hướng dẫn hoàn tất Tier 2
Tier 2 chỉ chứa cấu trúc tái sử dụng và placeholder mô tả. Tier 3 phải thay mọi placeholder bằng dữ liệu tổng hợp cụ thể, hoàn tất mọi dòng cần thiết và giữ nguyên ID, filename, phân loại nguồn cùng liên kết truy vết canonical. Mỗi mô tả API phải nêu actor gọi API, action, object, điều kiện đầu vào, kết quả mong đợi, artifact bằng chứng và liên kết truy vết. Không dùng dấu ..., nội dung dang dở hoặc placeholder trong ví dụ Tier 3 hoàn chỉnh. Nếu chưa xác định được nguồn cho một giá trị, không bịa quy tắc; ghi <Verification required: vai trò có thẩm quyền và nội dung cần xác minh> trong trường liên quan. Giữ trạng thái IN_REVIEW cho đến khi vai trò có thẩm quyền xác minh nội dung.
Khung Tier 2 — Quyết định, Ngoại lệ, Bằng chứng, Truy vết và Kiểm soát
Sao chép toàn bộ khung này khi tạo hồ sơ dữ liệu kiểm thử (test data). Dữ liệu thuộc Nova Foods Trading & Manufacturing chỉ là mô phỏng giáo dục, dùng dữ liệu tổng hợp. IN_REVIEW nghĩa là đang xem xét, không phải đã phê duyệt hoặc đã baseline.
| Trường kiểm soát | Giá trị cần điền |
|---|---|
| Test Data Record ID | <ID hồ sơ dữ liệu kiểm thử đã đăng ký trong TRACEABILITY_ID_REGISTRY> |
| Tên bộ dữ liệu | <tên mô tả rõ mục đích dữ liệu> |
| Module ERP | <ví dụ: Sales, Procurement, Inventory, Finance> |
| Phạm vi kiểm thử | <quy trình, màn hình, API hoặc báo cáo được kiểm thử> |
| Loại kiểm thử | <Functional|Integration|Regression|UAT|Security|Data migration> |
| Môi trường | <DEV|SIT|UAT|TRAINING> |
| Phân loại dữ liệu | <Synthetic|Masked|Reference-only> |
| Chứa dữ liệu cá nhân | <Không|Có — Verification required> |
| Chứa bí mật | <Không|Có — chỉ ghi secret reference> |
| Trạng thái | IN_REVIEW |
| Phiên bản | v0.9.0 |
| Ngày ghi nhận | 2026-08-07 |
| Múi giờ | Asia/Ho_Chi_Minh |
| Locale và tiền tệ | vi-VN, VND |
| Người lập | <vai trò hoặc định danh người lập> |
| Chủ sở hữu nội dung | <Business Owner|QA Owner|Data Owner theo phạm vi> |
| Giới hạn sử dụng | <chỉ môi trường mô phỏng; không dùng production> |
| ID dòng dữ liệu | Thực thể dữ liệu | Mục đích kiểm thử | Giá trị đầu vào tổng hợp | Kết quả mong đợi | Tiền điều kiện | Hậu điều kiện | Trạng thái dòng |
|---|---|---|---|---|---|---|---|
<TD-ROW-001> |
<tên entity canonical> |
<điều cần chứng minh> |
<payload hoặc giá trị tổng hợp> |
<kết quả quan sát được> |
<dữ liệu/cấu hình phải tồn tại> |
<dữ liệu thay đổi hoặc không thay đổi> |
<Draft|Ready|Blocked|Retired> |
<TD-ROW-002> |
<tên entity canonical> |
<điều cần chứng minh> |
<payload hoặc giá trị tổng hợp> |
<kết quả quan sát được> |
<dữ liệu/cấu hình phải tồn tại> |
<dữ liệu thay đổi hoặc không thay đổi> |
<Draft|Ready|Blocked|Retired> |
<TD-ROW-003> |
<tên entity canonical> |
<điều cần chứng minh> |
<payload hoặc giá trị tổng hợp> |
<kết quả quan sát được> |
<dữ liệu/cấu hình phải tồn tại> |
<dữ liệu thay đổi hoặc không thay đổi> |
<Draft|Ready|Blocked|Retired> |
Mỗi dòng phải có mục đích và kết quả mong đợi. Cầu nối suy luận: mục đích xác định hành vi cần kiểm tra; đầu vào kích hoạt hành vi; kết quả mong đợi chứng minh hoặc bác bỏ điều kiện kiểm thử. Không dùng dữ liệu thật của khách hàng, nhân viên, nhà cung cấp, tài khoản ngân hàng, mã truy cập hoặc khóa API.
| ID quyết định | Câu hỏi quyết định | Điều kiện hoặc bằng chứng đầu vào | Lựa chọn được ghi nhận | Người có thẩm quyền quyết định | Trạng thái quyết định | Lý do và tác động |
|---|---|---|---|---|---|---|
<TD-DEC-001> |
<có được dùng loại dữ liệu này không?> |
<phân loại dữ liệu, phạm vi môi trường, nguồn dữ liệu> |
<Approve for review|Reject|Escalate> |
<Data Owner|Security Owner|Business Owner> |
<Open|Resolved|Escalated> |
<lý do; tác động đến test case hoặc lịch> |
<TD-DEC-002> |
<có cần dữ liệu biên hoặc dữ liệu lỗi không?> |
<requirement, business rule hoặc acceptance criterion> |
<Include|Exclude|Escalate> |
<QA Owner|Business Owner> |
<Open|Resolved|Escalated> |
<lý do; rủi ro nếu loại trừ> |
<TD-DEC-003> |
<có cần tham chiếu bí mật không?> |
<kiểu xác thực, môi trường, kiểm soát truy cập> |
<Use secret reference|No secret required|Escalate> |
<Security Owner|System Owner> |
<Open|Resolved|Escalated> |
<lý do; không ghi bí mật trực tiếp> |
| ID ngoại lệ | Điều kiện kích hoạt | Dữ liệu hoặc dòng bị ảnh hưởng | Cách xử lý an toàn | Người xử lý | Cần escalation | Kết quả đóng ngoại lệ |
|---|---|---|---|---|---|---|
<TD-EXC-001> |
<dữ liệu chứa thông tin không tổng hợp> |
<TD-ROW-xxx> |
<dừng sử dụng; thay bằng dữ liệu tổng hợp> |
<Data Owner> |
<Có> |
<tham chiếu hồ sơ xử lý> |
<TD-EXC-002> |
<kết quả thực tế khác kết quả mong đợi> |
<TD-ROW-xxx> |
<ghi defect hoặc làm rõ test basis; không tự đổi expected result> |
<QA Owner> |
<Có|Không> |
<ID defect hoặc quyết định liên quan> |
<TD-EXC-003> |
<thiếu quyền hoặc môi trường không sẵn sàng> |
<TD-ROW-xxx> |
<đánh dấu Blocked; không dùng tài khoản cá nhân> |
<Environment Owner> |
<Có|Không> |
<ID yêu cầu môi trường> |
| ID bằng chứng | Loại bằng chứng | Vị trí hoặc liên kết kiểm soát | Liên kết dòng dữ liệu | Thời điểm thu thập | Người thu thập | Tính toàn vẹn |
|---|---|---|---|---|---|---|
<TD-EVD-001> |
<ảnh chụp màn hình|log|API response|query result|test execution record> |
<đường dẫn kho kiểm soát hoặc URL nội bộ được phép> |
<TD-ROW-xxx> |
<YYYY-MM-DDThh:mm:ss+07:00> |
<vai trò hoặc định danh> |
<hash/checksum nếu có; hoặc N/A có lý do> |
<TD-EVD-002> |
<ảnh chụp màn hình|log|API response|query result|test execution record> |
<đường dẫn kho kiểm soát hoặc URL nội bộ được phép> |
<TD-ROW-xxx> |
<YYYY-MM-DDThh:mm:ss+07:00> |
<vai trò hoặc định danh> |
<hash/checksum nếu có; hoặc N/A có lý do> |
| ID truy vết | Loại nguồn | ID hoặc đường dẫn canonical | Phần được liên kết | Cầu nối suy luận |
|---|---|---|---|---|
<TD-TRC-001> |
<Requirement|Business rule|Acceptance criterion|Test case|Defect> |
<ID canonical, không tự tạo biến thể> |
<trường hoặc TD-ROW-xxx> |
<nguồn yêu cầu hành vi; dòng dữ liệu cung cấp đầu vào để kiểm tra hành vi đó> |
<TD-TRC-002> |
Data dictionary |
CANONICAL_DATA_DICTIONARY |
<entity và field liên quan> |
<dictionary xác định nghĩa dữ liệu; giá trị kiểm thử phải khớp kiểu, miền giá trị và ràng buộc> |
<TD-TRC-003> |
Business rule catalog |
CANONICAL_BUSINESS_RULES |
<rule ID liên quan> |
<rule xác định điều kiện; expected result phản ánh kết quả rule khi điều kiện được kích hoạt> |
<TD-TRC-004> |
Identifier registry |
TRACEABILITY_ID_REGISTRY |
<mọi ID trong hồ sơ> |
<registry bảo đảm ID duy nhất và truy vết được giữa artifact> |
| Phiên bản | Ngày giờ thay đổi | Người thay đổi | Mô tả thay đổi | Lý do thay đổi | Tác động đến dữ liệu, test case, bằng chứng | Trạng thái |
|---|---|---|---|---|---|---|
v0.9.0 |
2026-08-07T<giờ>:<phút>:<giây>+07:00 |
<vai trò hoặc định danh> |
<mô tả thay đổi cụ thể> |
<nguồn, lỗi hoặc quyết định kích hoạt> |
<ID TD-ROW, TD-EVD, TD-TRC bị ảnh hưởng> |
IN_REVIEW |
| Loại review hoặc sign-off | Vai trò cần tham gia | Phạm vi xem xét | Kết quả | Ngày giờ | Tham chiếu nhận xét hoặc bằng chứng |
|---|---|---|---|---|---|
| Review dữ liệu | <Data Owner> |
<tính tổng hợp, phân loại, phù hợp môi trường> |
<Pending|Accepted with comments|Rejected|Escalated> |
<YYYY-MM-DDThh:mm:ss+07:00 hoặc Chưa ghi nhận> |
<ID comment, TD-EVD hoặc N/A có lý do> |
| Review kiểm thử | <QA Owner> |
<đủ dữ liệu dương, âm, biên và expected result> |
<Pending|Accepted with comments|Rejected|Escalated> |
<YYYY-MM-DDThh:mm:ss+07:00 hoặc Chưa ghi nhận> |
<ID comment, TD-EVD hoặc N/A có lý do> |
| Review nghiệp vụ | <Business Owner> |
<phù hợp requirement, rule và acceptance criterion> |
<Pending|Accepted with comments|Rejected|Escalated> |
<YYYY-MM-DDThh:mm:ss+07:00 hoặc Chưa ghi nhận> |
<ID comment, TD-TRC hoặc N/A có lý do> |
| Review bảo mật, nếu kích hoạt | <Security Owner> |
<secret reference, phân loại dữ liệu, quyền truy cập> |
<Pending|Accepted with comments|Rejected|Escalated|Not applicable> |
<YYYY-MM-DDThh:mm:ss+07:00 hoặc Chưa ghi nhận> |
<ID comment, TD-EVD hoặc lý do Not applicable> |
| Sign-off có thẩm quyền, nếu quy trình yêu cầu | <vai trò được chỉ định bởi governance> |
<phạm vi sign-off được nêu rõ> |
<Not requested|Pending|Recorded|Rejected> |
<YYYY-MM-DDThh:mm:ss+07:00 hoặc Chưa ghi nhận> |
<tham chiếu ghi nhận; không suy diễn approval từ review> |
Review kiểm tra nội dung trong phạm vi đã ghi nhận. Review không tạo approval, không tạo baseline, không thay thế sign-off. Chỉ ghi Recorded khi artifact có ghi nhận sign-off từ vai trò có thẩm quyền theo governance; nếu chưa có ghi nhận, giữ Pending hoặc Not requested và giữ trạng thái hồ sơ IN_REVIEW.
| Loại bí mật | Giá trị được phép ghi trong template | Giá trị cấm ghi | Tham chiếu an toàn |
|---|---|---|---|
| Mật khẩu, token, API key, private key | <secret reference dạng vault://... hoặc ID secret được quản lý> |
Giá trị bí mật thô | <vault://<tên-kho>/<ID-secret>; quyền truy cập do Security Owner quản lý> |
| Chuỗi kết nối DB | <connection reference hoặc ID cấu hình> |
Host thật, username thật, password, connection string hoàn chỉnh | <config://<môi-trường>/<ID-cấu-hình>> |
| Tài khoản kiểm thử | <test-account reference> |
Email, số điện thoại, định danh cá nhân thật | <identity://<môi-trường>/<ID-tài-khoản-tổng-hợp>> |
Người lập chỉ ghi tham chiếu bí mật an toàn. Security Owner quản lý quyền truy cập bí mật. Data Owner dừng sử dụng dòng dữ liệu khi phát hiện dữ liệu không tổng hợp hoặc dữ liệu cá nhân chưa được xác minh. QA Owner giữ nguyên expected result cho đến khi Business Owner, Data Owner hoặc nguồn canonical làm rõ thay đổi cần thiết. Hậu quả của việc ghi bí mật thô hoặc dùng dữ liệu thật là dòng dữ liệu phải bị chặn, ngoại lệ phải được ghi nhận và hồ sơ vẫn giữ IN_REVIEW.
Hướng dẫn trường, giá trị hợp lệ, quy tắc kiểm tra và điều kiện áp dụng
Dùng dấu <...> cho mọi giá trị chưa điền tại Tier 2. Mỗi placeholder phải mô tả dữ liệu cần nhập, không dùng giá trị chung chung như <text> hoặc <value>. Lý do: người lập test data cần tạo dữ liệu có thể kiểm tra, còn người review cần biết nguồn, mục đích và giới hạn từng trường. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; chỉ nhập dữ liệu tổng hợp.
| Nhóm trường | Placeholder bắt buộc | Hướng dẫn nhập | Giá trị hợp lệ | Quy tắc kiểm tra |
|---|---|---|---|---|
| Định danh bộ dữ liệu | <TD-XXX: mã test-data duy nhất> |
Gán một mã duy nhất, giữ nguyên khi sửa nội dung cùng bộ dữ liệu. | Chữ hoa, số, dấu gạch nối; theo registry đã đăng ký. | Không trùng mã trong cùng phạm vi kiểm thử. Nếu chưa có mã canonical, ghi <Cần đăng ký ID theo TRACEABILITY_ID_REGISTRY> và không tự tạo mã canonical. |
| Tên bộ dữ liệu | <tên nêu đối tượng, tình huống, kết quả mong đợi> |
Nêu rõ dữ liệu kiểm tra cái gì. | Tiếng Việt rõ nghĩa; giữ tên thuật ngữ ERP khi cần. | Không dùng tên mơ hồ như “test 1”. |
| Loại dữ liệu | <positive|negative|boundary|exception|integration|security|accessibility> |
Positive là dữ liệu hợp lệ; negative là dữ liệu phải bị từ chối; boundary là tại ngưỡng; exception là ngoại lệ nghiệp vụ. | Chỉ một hoặc nhiều giá trị trong danh sách, ngăn cách bằng ;. |
Mỗi loại phải có kết quả mong đợi tương ứng. Nếu chọn security, không ghi bí mật thật. |
| Môi trường | <DEV|TEST|UAT mô phỏng> |
Chỉ nêu môi trường mô phỏng được phép dùng. | DEV, TEST, UAT mô phỏng. |
Cấm PROD và dữ liệu production. |
| Thực thể nghiệp vụ | <tên thực thể theo CANONICAL_DATA_DICTIONARY> |
Ví dụ dạng hướng dẫn: khách hàng, đơn bán hàng, lô hàng, hóa đơn. | Tên đã có trong CANONICAL_DATA_DICTIONARY; nếu chưa xác minh, ghi <Verification required: thực thể chưa có mục canonical>. |
Không suy diễn tên bảng DB hoặc cấu hình ERP từ tên logic. |
| Trường dữ liệu | <tên trường logic> |
Một dòng cho một trường cần kiểm tra. | Tên logic từ data dictionary hoặc nhãn Verification required. |
Không để trống nếu payload, màn hình, file import hoặc API có trường đó. |
| Giá trị đầu vào | <giá trị tổng hợp cụ thể> |
Dùng giá trị cụ thể, tái lập được. Với VND dùng số nguyên không có phần thập phân nếu rule chưa xác minh khác. | Phù hợp kiểu dữ liệu và rule liên kết. | Không dùng dữ liệu cá nhân thật, số tài khoản thật, token, mật khẩu, khóa API hoặc URL nội bộ. |
| Kiểu dữ liệu | <string|integer|decimal|date|datetime|boolean|enum|object|array> |
Ghi kiểu logic cần kiểm tra. | Danh sách trong placeholder. | date dùng YYYY-MM-DD; datetime dùng ISO 8601 kèm +07:00 khi có giờ; boolean chỉ true hoặc false. |
| Nguồn tạo dữ liệu | <manual synthetic|generator synthetic|masked synthetic> |
Nêu cách tạo để reviewer đánh giá rủi ro dữ liệu. | manual synthetic, generator synthetic, masked synthetic. |
Không chọn masked synthetic nếu nguồn gốc dữ liệu chưa được Security và Privacy Owner xác minh. |
| Kết quả mong đợi | <chấp nhận|từ chối|cảnh báo|chuyển trạng thái> |
Nêu phản hồi quan sát được và dữ liệu lưu hoặc không lưu. | chấp nhận, từ chối, cảnh báo, chuyển trạng thái. |
Negative test phải nêu lỗi hoặc thông báo mong đợi; không chỉ ghi “fail”. |
| Bằng chứng | <đường dẫn bằng chứng hoặc mã evidence> |
Ghi tham chiếu screenshot, log đã che, kết quả API đã che, hoặc báo cáo chạy test. | Đường dẫn kiểm soát hoặc ID evidence. | Bằng chứng không chứa secret, PII thật, header Authorization, cookie, token, private key. |
| Truy vết | <REQ/BR/AC/TC-ID canonical> |
Liên kết đến yêu cầu, business rule, acceptance criterion hoặc test case có ID canonical. | ID tồn tại trong artifact nguồn. | Không tự gán quan hệ “đã đáp ứng”; chỉ ghi quan hệ cần kiểm tra. |
| Trạng thái dữ liệu | <DRAFT|READY_FOR_REVIEW|BLOCKED|RETIRED> |
READY_FOR_REVIEW nghĩa là đủ để review, không nghĩa là approved. |
Bốn giá trị liệt kê. | BLOCKED phải có lý do và vai trò cần xử lý. |
| Phiên bản dòng dữ liệu | <v0.0.1> |
Tăng phiên bản khi thay đổi giá trị, rule, traceability hoặc expected result. | Dạng v<major>.<minor>.<patch>. |
Không sửa im lặng dòng đã được ghi bằng chứng. |
| Người lập, người review, sign-off | <họ tên hoặc vai trò mô phỏng> |
Ghi vai trò và ngày theo Asia/Ho_Chi_Minh. |
Vai trò mô phỏng phù hợp. | Trường sign-off chỉ ghi trạng thái Chưa ghi nhận; không suy diễn approval từ tên người review. |
| Điều kiện | Phần template kích hoạt | Cách điền bắt buộc | Lý do và cầu nối bằng chứng |
|---|---|---|---|
| Dữ liệu kiểm tra API | Payload, HTTP method, endpoint, response expected, correlation ID đã che | Ghi <GET|POST|PUT|PATCH|DELETE>; <endpoint không chứa secret>; <HTTP status mong đợi>. |
OAS 3.1.1 là nguồn chuẩn cho mô tả HTTP API. Vì test data tác động request/response, cần kiểm tra method, payload và status thay vì chỉ ghi tên API. |
| Có trường tiền tệ | Currency, amount, rounding rule, negative-value handling | Ghi VND; <số tiền tổng hợp>; <Verification required: quy tắc làm tròn>. |
Locale corpus là vi-VN/VND. Quy tắc kế toán hoặc thuế chưa xác minh không được biến thành rule bắt buộc. |
| Có ngày giờ | Timezone, thời điểm tạo, thời điểm hiệu lực | Ghi Asia/Ho_Chi_Minh và ISO 8601. |
Timezone corpus đã cố định. Dữ liệu thời gian thiếu múi giờ có thể làm sai thứ tự xử lý và expected result. |
| Có dữ liệu cá nhân, sức khỏe, định danh, liên hệ | Data classification, privacy risk, masking decision, escalation owner | Ghi <Verification required: Privacy/Legal Owner>; dùng dữ liệu tổng hợp không nhận diện cá nhân. |
Nguồn pháp lý nêu có hiệu lực nhưng yêu cầu hệ thống phải do Legal Owner xác minh. Vì vậy template chỉ ghi nhãn và escalation, không kết luận tuân thủ. |
| Có batch, lot, expiry, recall | Traceability scope, domain-owner check, evidence source | Ghi <Verification required: Food Safety/Domain Owner> và liên kết nguồn nghiệp vụ. |
Luật An toàn thực phẩm là bối cảnh truy xuất/thu hồi; chi tiết rule Nova Foods chưa được xác minh nên không tự đặt ngưỡng hoặc chu kỳ. |
| Có lỗi, ngoại lệ, dữ liệu bị từ chối | Exception ID, trigger, expected handling, data persistence check | Ghi <mã exception>; <điều kiện kích hoạt>; <dữ liệu có/không được lưu>. |
Exception cần kiểm tra riêng vì “từ chối” không đủ chứng minh hệ thống không lưu dữ liệu sai hoặc không tạo giao dịch dở dang. |
| Có quyền truy cập hoặc bí mật | Secret reference, access role, rotation/expiry reference, redaction check | Dùng <secret-ref: vault://<vault-name>/<path>#<version>> hoặc <secret-ref: environment-variable:<NAME>>. |
OWASP ASVS và OWASP API Security Top 10 hỗ trợ nhận thức bảo mật. Secret phải được tham chiếu, không chép vào template, payload, log hay bằng chứng. |
Quy tắc secret-reference: chỉ ghi định danh tham chiếu không tiết lộ giá trị, ví dụ <secret-ref: environment-variable:NOVA_TEST_API_TOKEN>. Cấm điền mật khẩu, API key, bearer token, session cookie, private key, connection string chứa mật khẩu, mã OTP, ảnh chụp màn hình chưa che. Nếu test không thể chạy thiếu secret, đặt trạng thái <BLOCKED> và ghi <Security Owner cần cấp quyền test tối thiểu>; không thay bằng secret giả nếu điều đó làm sai hành vi cần kiểm tra.
3. Tier 3 ? Fully Completed Nova Foods Case: Core Record
Bối cảnh: Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp. Test data là dữ liệu kiểm thử, dùng để tạo điều kiện đầu vào xác định và kiểm tra kết quả hệ thống ERP. Kịch bản kiểm tra tạo đơn bán hàng cho khách hàng hợp lệ, đủ tồn kho và áp dụng đơn giá đã công bố trong dữ liệu mô phỏng.
| Trường core record | Giá trị hoàn chỉnh |
|---|---|
| Template ID | TMPL-TST-002 |
| Test data set ID | TDS-SO-20260807-001 |
| Test scenario ID | TSC-SO-CREATE-VALID-001 |
| Tên kịch bản | Tạo đơn bán hàng hợp lệ cho khách hàng siêu thị |
| Trạng thái dữ liệu | READY_FOR_TEST |
| Ngày tạo | 2026-08-07 |
| Múi giờ | Asia/Ho_Chi_Minh |
| Locale | vi-VN |
| Tiền tệ | VND |
| Hệ thống mô phỏng | Nova Foods ERP Sales Order |
| Môi trường mô phỏng | SIT-NOVA-01 |
| Người chuẩn bị dữ liệu | Nguyễn Minh An, Test Data Analyst, nhân sự tổng hợp |
| Người thực thi dự kiến | Trần Gia Huy, QA Analyst, nhân sự tổng hợp |
| Đối tượng nghiệp vụ | Đơn bán hàng SO-NF-20260807-0001 |
| Nguồn phân loại | PROJECT_ASSUMPTION_SYNTHETIC |
| Ranh giới nguồn | Không phải dữ liệu vận hành, hóa đơn, khách hàng, giá bán hay tồn kho thực tế của Nova Foods. |
Sự kiện nghiệp vụ mô phỏng: Ngày 2026-08-07, nhân viên kinh doanh tạo đơn bán SO-NF-20260807-0001 cho khách hàng CUS-NF-00021. Đơn gồm hai mặt hàng thành phẩm có tồn kho khả dụng lớn hơn số lượng đặt. Hệ thống phải tính đúng thành tiền từng dòng và tổng tiền đơn. Đây là giả định dự án phục vụ học liệu; Business Owner và Accounting Owner chưa xác nhận đây là quy tắc vận hành thực tế.
| Loại bản ghi | ID | Dữ liệu hoàn chỉnh | Phân loại nguồn |
|---|---|---|---|
| Pháp nhân bán | ORG-NF-001 |
Nova Foods Trading & Manufacturing, đơn vị mô phỏng | SYNTHETIC_ORGANIZATION |
| Kho xuất | WH-HCM-01 |
Kho Thành phẩm Hồ Chí Minh, địa chỉ mô phỏng: 18 Đường Số 9, Khu Công nghiệp Tân Bình, Phường Tây Thạnh, TP. Hồ Chí Minh | SYNTHETIC_MASTER_DATA |
| Nhân viên bán | EMP-NF-0017 |
Lê Quốc Bảo, Sales Executive, hoạt động | SYNTHETIC_ACTOR |
| Khách hàng | CUS-NF-00021 |
Siêu thị An Phú, mã số khách hàng mô phỏng, điều khoản thanh toán NET_15 |
SYNTHETIC_MASTER_DATA |
| Người nhận hàng | CON-NF-0021 |
Phạm Thu Hà, Warehouse Receiver, số liên hệ mô phỏng 0900000021 |
SYNTHETIC_CONTACT |
| Sản phẩm 1 | FG-NUOCMAM-500 |
Nước mắm Nova 500 ml, đơn vị CHAI |
SYNTHETIC_MASTER_DATA |
| Sản phẩm 2 | FG-TUONGOT-250 |
Tương ớt Nova 250 g, đơn vị CHAI |
SYNTHETIC_MASTER_DATA |
| Bảng giá | PL-HCM-2026-08 |
Bảng giá khách hàng khu vực Hồ Chí Minh, hiệu lực mô phỏng 2026-08-01 đến 2026-08-31 |
PROJECT_ASSUMPTION_SYNTHETIC |
| Tồn kho 1 | INV-WH-HCM-01-FG-NUOCMAM-500 |
Tồn khả dụng: 480 CHAI |
SYNTHETIC_TRANSACTIONAL_DATA |
| Tồn kho 2 | INV-WH-HCM-01-FG-TUONGOT-250 |
Tồn khả dụng: 350 CHAI |
SYNTHETIC_TRANSACTIONAL_DATA |
| Dòng đơn | Product ID | Số lượng đặt | Đơn giá chưa thuế | Thành tiền chưa thuế | Tồn khả dụng trước đặt | Kết quả kiểm tra dữ liệu |
|---|---|---|---|---|---|---|
SO-NF-20260807-0001-01 |
FG-NUOCMAM-500 |
120 CHAI |
38.000 VND |
4.560.000 VND |
480 CHAI |
Hợp lệ vì 120 ≤ 480 |
SO-NF-20260807-0001-02 |
FG-TUONGOT-250 |
80 CHAI |
22.000 VND |
1.760.000 VND |
350 CHAI |
Hợp lệ vì 80 ≤ 350 |
| Tổng đơn | SO-NF-20260807-0001 |
200 CHAI |
Không áp dụng | 6.320.000 VND |
Không áp dụng | 4.560.000 + 1.760.000 = 6.320.000 VND |
Payload nhập mô phỏng: Dữ liệu JSON là cấu trúc trao đổi dữ liệu có cặp tên trường và giá trị. Payload này không chứa secret, dữ liệu cá nhân thật, token hay thông tin truy cập.
{
"salesOrderId": "SO-NF-20260807-0001",
"orderDate": "2026-08-07",
"currencyCode": "VND",
"customerId": "CUS-NF-00021",
"warehouseId": "WH-HCM-01",
"salesEmployeeId": "EMP-NF-0017",
"paymentTermCode": "NET_15",
"requestedDeliveryDate": "2026-08-09",
"lines": [
{
"lineId": "SO-NF-20260807-0001-01",
"productId": "FG-NUOCMAM-500",
"uom": "CHAI",
"orderedQuantity": 120,
"unitPriceExcludingTax": 38000,
"lineAmountExcludingTax": 4560000
},
{
"lineId": "SO-NF-20260807-0001-02",
"productId": "FG-TUONGOT-250",
"uom": "CHAI",
"orderedQuantity": 80,
"unitPriceExcludingTax": 22000,
"lineAmountExcludingTax": 1760000
}
],
"totalAmountExcludingTax": 6320000,
"dataClassification": "PROJECT_ASSUMPTION_SYNTHETIC"
}
Cơ sở chọn dữ liệu: Số lượng đặt thấp hơn tồn khả dụng tại WH-HCM-01, nên kịch bản cô lập kiểm tra tạo đơn hợp lệ thay vì trộn lỗi thiếu hàng. Hai đơn giá khớp PL-HCM-2026-08, nên sai lệch tổng tiền sẽ chỉ ra lỗi lấy giá hoặc tính toán. Thuế, xuất hóa đơn, hạch toán, giữ hàng và giao hàng không nằm trong core record này; các nội dung đó cần Accounting Owner, Legal Owner hoặc Business Owner xác minh nếu được đưa vào phạm vi sau.
Bản ghi dữ liệu kiểm thử đã điền đủ: tạo lệnh 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. Toàn bộ người dùng, khách hàng, hàng hóa, giao dịch và giá trị dưới đây là dữ liệu tổng hợp. Bản ghi này kiểm thử quy tắc chặn phát hành đơn bán hàng khi công nợ sau đơn vượt hạn mức tín dụng đã cấu hình.
| Trường lõi | Giá trị đã điền |
|---|---|
| Test Data ID | TD-NF-SO-CRL-001 |
| Tên dữ liệu kiểm thử | Đơn bán hàng vượt hạn mức tín dụng khách hàng |
| Trạng thái dữ liệu | READY_FOR_TEST |
| Phiên bản dữ liệu | v0.9.0 |
| Ngày tạo | 2026-08-07 |
| Múi giờ | Asia/Ho_Chi_Minh |
| Locale và tiền tệ | vi-VN, VND |
| Hệ thống mô phỏng | Nova Foods ERP — Sales and Receivables |
| Môi trường mô phỏng | SIT-NOVA-01 |
| Người tạo dữ liệu | USR-NF-BA-021 — Lê Minh Anh, Business Analyst mô phỏng |
| Người thực thi dự kiến | USR-NF-QA-014 — Trần Quốc Bảo, QA Analyst mô phỏng |
| Phân loại nguồn | Dữ liệu kiểm thử tổng hợp nội bộ case study |
| Phân loại thông tin | INTERNAL-SYNTHETIC; không chứa dữ liệu cá nhân thật |
| Traceability rule | BR-NF-AR-003 |
| Traceability requirement | FR-NF-SALES-012 |
| Traceability acceptance criterion | AC-NF-SALES-012-03 |
| Test basis | CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY |
| Mục tiêu | Xác nhận ERP không cho phát hành đơn SO-NF-260807-018 khi tổng công nợ mở và giá trị đơn mới vượt hạn mức 300.000.000 VND. |
Sự kiện kiểm thử: Nhân viên bán hàng tạo đơn cho khách hàng có công nợ mở 245.000.000 VND. Đơn mới có tổng thanh toán 66.000.000 VND. Tổng phơi nhiễm tín dụng dự kiến là 311.000.000 VND, cao hơn hạn mức 11.000.000 VND. Vì 311.000.000 VND > 300.000.000 VND, quy tắc phải chặn phát hành đơn.
| Thực thể | ID | Dữ liệu đã điền | Phân loại nguồn |
|---|---|---|---|
| Khách hàng | CUS-NF-000184 |
Công ty TNHH Phân phối An Phúc, hạn mức tín dụng 300.000.000 VND, điều khoản thanh toán NET30, trạng thái ACTIVE |
Tổng hợp nội bộ |
| Nhân viên bán hàng | USR-NF-SALES-008 |
Nguyễn Hải Nam, vai trò Sales Executive, trạng thái ACTIVE |
Tổng hợp nội bộ |
| Kho xuất dự kiến | WH-NF-HCM-01 |
Kho Thành phẩm Bình Tân, trạng thái ACTIVE |
Tổng hợp nội bộ |
| Hàng hóa 1 | SKU-NF-OML-500 |
Nova Oat Milk 500 ml, số lượng 600, đơn giá chưa VAT 45.000 VND, VAT 8% theo giả định dự án |
Tổng hợp nội bộ; VAT là giả định dự án |
| Hàng hóa 2 | SKU-NF-GRB-250 |
Nova Granola Bar 250 g, số lượng 300, đơn giá chưa VAT 90.000 VND, VAT 8% theo giả định dự án |
Tổng hợp nội bộ; VAT là giả định dự án |
| Công nợ mở | AR-NF-260731-044 |
Hóa đơn mô phỏng chưa thanh toán 245.000.000 VND, đến hạn 2026-08-30, trạng thái OPEN |
Tổng hợp nội bộ |
| Đơn bán hàng | SO-NF-260807-018 |
Ngày đơn 2026-08-07, trạng thái khởi tạo DRAFT, khách hàng CUS-NF-000184 |
Tổng hợp nội bộ |
| Dòng đơn | SKU | Số lượng | Đơn giá chưa VAT | Thành tiền chưa VAT | VAT | Tổng dòng |
|---|---|---|---|---|---|---|
SOL-NF-260807-018-01 |
SKU-NF-OML-500 |
600 | 45.000 VND | 27.000.000 VND | 2.160.000 VND | 29.160.000 VND |
SOL-NF-260807-018-02 |
SKU-NF-GRB-250 |
300 | 90.000 VND | 27.000.000 VND | 2.160.000 VND | 29.160.000 VND |
| Tổng đơn | Không áp dụng | 900 | Không áp dụng | 54.000.000 VND | 4.320.000 VND | 58.320.000 VND |
| Phí giao hàng | SVC-NF-DEL-HCM |
1 | 7.680.000 VND | 7.680.000 VND | 0 VND | 7.680.000 VND |
| Tổng thanh toán đơn | Không áp dụng | Không áp dụng | Không áp dụng | 61.680.000 VND | 4.320.000 VND | 66.000.000 VND |
Quy tắc áp dụng: BR-NF-AR-003 quy định: trước khi chuyển đơn từ DRAFT sang RELEASED, hệ thống tính Công nợ mở + Tổng thanh toán đơn. Nếu kết quả lớn hơn hạn mức tín dụng khách hàng, hệ thống phải giữ đơn ở CREDIT_HOLD, không tạo yêu cầu xuất kho, và ghi lý do chặn. Quy tắc là giả định nghiệp vụ mô phỏng; Accounting Owner và Business Owner phải xác minh trước mọi sử dụng vận hành hoặc production.
| Giá trị tính | Công thức | Kết quả |
|---|---|---|
| Công nợ mở hiện tại | Giá trị AR-NF-260731-044 |
245.000.000 VND |
| Tổng thanh toán đơn mới | Tổng SO-NF-260807-018 |
66.000.000 VND |
| Phơi nhiễm tín dụng sau đơn | 245.000.000 + 66.000.000 |
311.000.000 VND |
| Hạn mức tín dụng | Giá trị khách hàng CUS-NF-000184 |
300.000.000 VND |
| Phần vượt hạn mức | 311.000.000 - 300.000.000 |
11.000.000 VND |
| Trạng thái trước thao tác | Thao tác | Điều kiện đánh giá | Trạng thái mong đợi | Hệ quả dữ liệu mong đợi |
|---|---|---|---|---|
DRAFT |
Release Sales Order bởi USR-NF-SALES-008 |
311.000.000 VND > 300.000.000 VND |
CREDIT_HOLD |
Không tạo PICK_REQUEST; không tạo DELIVERY_NOTE; giữ nguyên công nợ mở 245.000.000 VND |
CREDIT_HOLD |
Người dùng xem chi tiết đơn | Lý do chặn phải hiển thị | CREDIT_HOLD |
Hiển thị Credit limit exceeded by 11.000.000 VND |
CREDIT_HOLD |
Người dùng thử phát hành lại không có quyền phê duyệt tín dụng | Hạn mức vẫn bị vượt | CREDIT_HOLD |
Không phát sinh bản ghi xuất kho hoặc giao hàng |
Payload đầu vào mô phỏng dùng tại API nội bộ POST /api/v1/sales-orders/SO-NF-260807-018/release:
{
"salesOrderId": "SO-NF-260807-018",
"requestedByUserId": "USR-NF-SALES-008",
"requestedAt": "2026-08-07T10:15:00+07:00",
"customerId": "CUS-NF-000184",
"currency": "VND",
"creditExposureBeforeOrder": 245000000,
"salesOrderGrossAmount": 66000000,
"creditLimit": 300000000
}
| Lựa chọn | Mô tả | Tiêu chí đánh giá | Kết quả |
|---|---|---|---|
OPT-NF-CRL-01 |
Tự phát hành đơn dù vượt hạn mức | Tăng tốc giao hàng nhưng mất kiểm soát rủi ro công nợ | Loại |
OPT-NF-CRL-02 |
Chặn phát hành, chuyển CREDIT_HOLD |
Ngăn phát sinh xuất kho khi khách hàng vượt hạn mức; tạo dấu vết xử lý | Khuyến nghị |
OPT-NF-CRL-03 |
Chặn toàn bộ tạo đơn khi gần hạn mức | Giảm rủi ro hơn nhưng ngăn Sales chuẩn bị đơn nháp | Loại |
Quyết định mô phỏng: chọn OPT-NF-CRL-02. Thẩm quyền quyết định nghiệp vụ thuộc Business Owner và Accounting Owner; Business Analyst chỉ ghi nhận logic, dữ liệu và traceability. Nếu chọn sai, ERP có thể phát sinh giao hàng cho khách hàng vượt hạn mức hoặc chặn đơn hợp lệ, gây sai lệch doanh thu, công nợ và vận hành kho trong tình huống mô phỏng.
Bối cảnh quyết định dữ liệu kiểm thử Nova Foods
Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Kịch bản kiểm thử: nhân viên bán hàng tạo đơn SO-NF-20260807-001 cho khách CUS-NF-00027 — Siêu thị An Phú, gồm 120 thùng SKU-NF-NUOCMAM-500, đơn giá 185.000 VND/thùng, giảm giá thương mại 5%, VAT 10% là giả định dự án để kiểm thử tính toán, không phải kết luận thuế. Tổng tiền hàng 22.200.000 VND; giảm giá 1.110.000 VND; tiền trước thuế 21.090.000 VND; VAT 2.109.000 VND; tổng thanh toán 23.199.000 VND.
| Thành phần | Giá trị dữ liệu kiểm thử | Phân loại nguồn | Sự thật cần kiểm |
|---|---|---|---|
| Kho xuất | WH-HCM-01 — Kho TP.HCM |
Dữ liệu mô phỏng Nova Foods | Tồn khả dụng của SKU-NF-NUOCMAM-500 là 150 thùng lúc 2026-08-07 09:15:00 Asia/Ho_Chi_Minh. |
| Lô hàng | LOT-NF-20260715-A |
Dữ liệu mô phỏng Nova Foods | Lô còn 150 thùng, ngày sản xuất 2026-07-15, hạn dùng 2027-07-15. |
| Người tạo đơn | USR-NF-SALES-014 — Lê Minh Khoa |
Dữ liệu mô phỏng Nova Foods | Vai trò Sales Executive, được phép tạo đơn bán. |
| Người duyệt giá | USR-NF-SM-003 — Trần Ngọc Mai |
Dữ liệu mô phỏng Nova Foods | Vai trò Sales Manager, là authority quyết định ngoại lệ giảm giá. |
| Trạng thái đầu vào | Draft |
Quy ước dữ liệu kiểm thử | Đơn chưa giữ tồn, chưa phát hành chứng từ, chưa tạo bút toán. |
| Trạng thái mong đợi | Confirmed |
Quy ước dữ liệu kiểm thử | Hệ thống giữ 120 thùng tồn và tạo yêu cầu xuất kho. |
Hành vi hiện tại giả định: ERP cho phép nhập giảm giá 5%, nhưng chưa kiểm tra quyền duyệt theo ngưỡng. Người dùng USR-NF-SALES-014 có thể tự chuyển đơn từ Draft sang Confirmed. Bằng chứng suy luận: giảm giá làm giảm doanh thu dự kiến 1.110.000 VND; nếu không có kiểm soát quyền, cùng một vai trò vừa tạo vừa xác nhận ngoại lệ giá. Nhu cầu gốc không phải thêm màn hình duyệt; nhu cầu là chặn xác nhận khi giảm giá vượt quyền người tạo đơn.
| Phương án | Mô tả | Tiêu chí đánh giá | Kết quả |
|---|---|---|---|
OPT-01 |
Cho phép Sales Executive tự xác nhận mọi mức giảm giá | Tốc độ nhập đơn cao; kiểm soát doanh thu thấp | Không khuyến nghị. |
OPT-02 |
Sales Executive tự xác nhận khi giảm giá tối đa 3%; mức trên 3% cần Sales Manager duyệt |
Phân tách trách nhiệm; kiểm thử rõ ngưỡng; ít thay đổi quy trình | Khuyến nghị cho case mô phỏng. |
OPT-03 |
Mọi đơn cần Sales Manager duyệt | Kiểm soát cao; chậm xử lý đơn giá trị thấp | Không chọn cho kịch bản này. |
Quy tắc kiểm thử đề xuất BR-NF-SALES-012: khi discountRate > 3, hệ thống phải đặt đơn ở trạng thái PendingPriceApproval; chỉ USR-NF-SM-003 hoặc vai trò Sales Manager mới được chuyển đơn sang Confirmed. Khi discountRate <= 3, Sales Executive được xác nhận nếu tồn khả dụng không nhỏ hơn số lượng đặt. Đây là rule mô phỏng; Business Owner và Sales Manager là authority quyết định nghiệp vụ, không có phê duyệt nào được ghi nhận trong artifact IN_REVIEW v0.9.0.
Nếu áp dụng sai, đơn SO-NF-20260807-001 có thể xác nhận giảm giá 5% không đúng thẩm quyền, làm sai giá trị doanh thu dự kiến 1.110.000 VND; hoặc hệ thống có thể giữ tồn khi chưa có quyết định giá hợp lệ. Kiểm thử phải phân biệt lỗi quyền duyệt, lỗi chuyển trạng thái và lỗi tính tiền; không suy diễn đây là quy định kế toán, thuế hoặc vận hành thực tế.
4. Tier 3 ? Fully Completed Nova Foods Case: Evidence and Traceability
Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi đơn hàng, người dùng, giá và bằng chứng dưới đây là dữ liệu tổng hợp. Ngoại lệ là tình huống lệch khỏi luồng xác nhận thông thường. Đường đi âm là kiểm thử cố ý gửi dữ liệu hoặc thao tác không hợp lệ để chứng minh hệ thống chặn đúng chỗ. Bằng chứng không chứng minh Nova Foods vận hành thực tế; bằng chứng chỉ cho thấy cơ sở thiết kế và kiểm thử của kịch bản SO-NF-20260807-001.
| ID | Ngoại lệ hoặc đường đi âm | Dữ liệu mô phỏng | Kết quả bắt buộc theo BR-NF-SALES-012 |
Bằng chứng tham chiếu | Liên kết kiểm thử |
|---|---|---|---|---|---|
EXC-NF-SALES-001 |
Sales Executive giảm giá 5%, vượt ngưỡng tự xác nhận 3% |
Đơn SO-NF-20260807-001; giá trước giảm 1.200.000 VND; giá sau giảm 1.140.000 VND; người tạo USR-NF-SE-014 |
Trạng thái phải là PendingPriceApproval; USR-NF-SE-014 không được chuyển đơn sang Confirmed. |
BR-NF-SALES-012; phương án OPT-02 trong section 3; tính toán 1.200.000 × 95% = 1.140.000 VND. |
TC-NF-SALES-012-01 |
EXC-NF-SALES-002 |
Sales Executive cố xác nhận đơn đang chờ duyệt giá | SO-NF-20260807-001; discountRate=5; actor USR-NF-SE-014 |
API hoặc giao diện phải từ chối thao tác; trạng thái giữ PendingPriceApproval; không phát sinh xác nhận đơn. |
BR-NF-SALES-012; nguyên tắc phân tách trách nhiệm trong lựa chọn OPT-02. |
TC-NF-SALES-012-02 |
EXC-NF-SALES-003 |
Sales Manager xác nhận giảm giá đúng thẩm quyền nhưng tồn khả dụng thiếu | SO-NF-20260807-001; số lượng đặt 120; tồn khả dụng mô phỏng 80; actor USR-NF-SM-003 |
Không chuyển Confirmed; hệ thống báo thiếu 40 đơn vị; không giữ tồn vượt khả dụng. |
BR-NF-SALES-012: điều kiện xác nhận gồm quyền duyệt và tồn khả dụng. |
TC-NF-SALES-012-03 |
EXC-NF-SALES-004 |
Giảm giá đúng ngưỡng nhưng giá trị biên 3% |
Giá trước giảm 1.200.000 VND; discountRate=3; giá sau giảm 1.164.000 VND; actor USR-NF-SE-014; tồn khả dụng 120 |
Sales Executive được xác nhận nếu tồn khả dụng không nhỏ hơn 120; không chuyển qua PendingPriceApproval. |
Điều kiện discountRate <= 3 trong BR-NF-SALES-012; tính toán 1.200.000 × 97% = 1.164.000 VND. |
TC-NF-SALES-012-04 |
EXC-NF-SALES-005 |
Gửi tỷ lệ giảm giá âm hoặc vượt 100% |
discountRate=-1 và discountRate=101; actor USR-NF-SE-014 |
Hệ thống từ chối dữ liệu đầu vào trước khi đánh giá quyền duyệt; không tạo hoặc sửa đơn với giá trị giảm giá không hợp lệ. | Ranh giới dữ liệu cần kiểm thử theo thuật ngữ black-box testing của ISTQB CTFL Syllabus v4.0.1. Không suy diễn giới hạn này từ luật hay quy tắc Nova Foods thực tế. | TC-NF-SALES-012-05 |
| ID giả định | Giả định dự án mô phỏng | Cầu nối bằng chứng và suy luận | Trạng thái |
|---|---|---|---|
ASM-NF-SALES-001 |
discountRate là phần trăm trên tổng giá đơn trước giảm giá, không phải mức giảm trên từng dòng hàng. |
Ví dụ section 3 dùng một giá trị giảm 5% và doanh thu dự kiến 1.110.000 VND; chưa có data dictionary hoặc đặc tả API canonical xác định cấp áp dụng giảm giá. |
Verification required |
ASM-NF-SALES-002 |
Tồn khả dụng được kiểm tra tại lúc xác nhận, không tại lúc tạo đơn. | BR-NF-SALES-012 nêu điều kiện tồn cho hành động Confirmed; không có bằng chứng cho cơ chế reserve, allocation hoặc thời điểm đồng bộ tồn. |
Verification required |
ASM-NF-SALES-003 |
USR-NF-SM-003 mang vai trò Sales Manager trong dữ liệu mô phỏng. |
Rule nêu rõ USR-NF-SM-003 hoặc vai trò Sales Manager được xác nhận; chưa có nguồn canonical về mô hình phân quyền ERP. |
Verification required |
ASM-NF-SALES-004 |
Thông báo từ chối không hiển thị giá trị tồn kho cho người không có quyền phù hợp. | Thiếu tồn là dữ liệu nghiệp vụ; thiết kế hiển thị cần Security Owner và Architect xác định quyền xem dữ liệu. OWASP ASVS là chuẩn thực hành bảo mật, không phải quyết định quyền cho Nova Foods. | Verification required |
| ID xác minh | Nội dung phải xác minh | Vai trò có thẩm quyền | Bằng chứng cần có | Điều kiện đóng |
|---|---|---|---|---|
VRF-NF-SALES-001 |
Ngưỡng 3% áp dụng cho mọi khách hàng hay chỉ khách hàng bán buôn. |
Business Owner; Sales Manager | Quyết định nghiệp vụ được ghi nhận trong artifact kiểm soát phù hợp. | Có tham chiếu quyết định; BR-NF-SALES-012 được cập nhật qua kiểm soát thay đổi. |
VRF-NF-SALES-002 |
Công thức giá có bao gồm thuế, phí giao hàng hoặc làm tròn VND không. | Accounting Owner; Business Owner | Quy tắc giá và ví dụ tính toán được xác nhận bởi vai trò thẩm quyền. | Có rule canonical hoặc change record; test case cập nhật theo rule. |
VRF-NF-SALES-003 |
Cơ chế kiểm tra tồn có cần giữ tồn khi đơn chờ duyệt giá không. | Inventory Owner; Solution Architect | Mô tả trạng thái tồn và quyết định kiến trúc. | Có đặc tả trạng thái và bằng chứng kiểm thử tích hợp. |
| ID escalation | Vấn đề | Tác động nếu không quyết định | Người nhận | Trạng thái tại 2026-08-07 |
Hành động kiểm soát |
|---|---|---|---|---|---|
ESC-NF-SALES-001 |
Chưa xác minh phạm vi áp dụng ngưỡng giảm giá 3%. |
Có thể duyệt sai đơn khách hàng hoặc tạo test case không phản ánh quyết định nghiệp vụ. | Business Owner; Sales Manager | Open |
Giữ BR-NF-SALES-012 là rule mô phỏng IN_REVIEW; không gọi là baseline hoặc rule vận hành. |
ESC-NF-SALES-002 |
Chưa xác minh thời điểm kiểm tra và giữ tồn. | Có thể xác nhận đơn khi tồn đã bị đơn khác sử dụng, hoặc khóa tồn quá sớm. | Inventory Owner; Solution Architect | Open |
Chỉ kiểm thử điều kiện tồn tại thời điểm xác nhận như mô tả hiện có; không suy diễn cơ chế reserve. |
ESC-NF-SALES-003 |
Chưa xác minh cách tính giá sau giảm liên quan thuế và làm tròn. | Giá trị 1.110.000 VND có thể bị hiểu sai là giá kế toán hoặc giá hóa đơn. |
Accounting Owner; Business Owner | Open |
Gắn nhãn số tiền là ví dụ mô phỏng; không dùng cho hạch toán, thuế hoặc hóa đơn. |
Nguồn bằng chứng: BR-NF-SALES-012 và OPT-02 là bằng chứng nội bộ của case mô phỏng, trạng thái IN_REVIEW, version v0.9.0, chưa có baseline. ISTQB CTFL Syllabus v4.0.1 là nguồn chính cho thuật ngữ kiểm thử và kỹ thuật kiểm thử hộp đen: https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf. OWASP ASVS 5.0.0 là nguồn industry security verification, không phải luật Việt Nam: https://owasp.org/www-project-application-security-verification-standard/. Access date: 2026-08-07.
Ma trận truy vết đầu-cuối cho kịch bản nhập lô nguyên liệu mô phỏng
Truy vết đầu-cuối là liên kết có kiểm soát từ nhu cầu đến bằng chứng kiểm thử. Kịch bản Nova Foods Trading & Manufacturing là mô phỏng giáo dục, dữ liệu tổng hợp: nhân viên kho ghi nhận nhập 500 kg bột cacao lô CC-260807-A vào phiếu nhận hàng GRN-NF-260807-001. Không có baseline hay approval; các ID dưới đây là liên kết làm việc tại IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh.
| Thứ tự | Family / ID | Nội dung đã liên kết | Nguồn hoặc căn cứ | Cầu nối suy luận |
|---|---|---|---|---|
| 1 | NEED-NF-001 |
Cần ghi nhận lô nguyên liệu khi nhận hàng để kho biết số lượng và lô nào sẵn sàng cho truy xuất nội bộ. | Nhu cầu mô phỏng Nova Foods; phân loại: SIMULATED_PROJECT_NEED. |
Không có số lô thì không thể phân biệt 500 kg này với lô cacao khác trong dữ liệu kho. |
| 2 | REQ-NF-001 |
ERP phải tạo phiếu nhận hàng chỉ khi receivedQuantityKg lớn hơn 0, có supplierLotCode, và receiptDate không sau ngày hệ thống. |
NEED-NF-001; /01-curriculum/CANONICAL_DATA_DICTIONARY.md; phân loại: PLANNED_CANONICAL_DATA_SOURCE. |
Nhu cầu truy xuất cần lượng, mã lô, ngày nhận; chặn lượng âm hoặc ngày tương lai ngăn bản ghi không có ý nghĩa vận hành. |
| 3 | BR-NF-001 |
Một dòng nhận hàng chỉ được gán trạng thái RECEIVED khi số lượng nhận không vượt số lượng đặt mua còn mở của cùng mã hàng và cùng đơn mua. |
REQ-NF-001; quy tắc dự kiến trong /01-curriculum/CANONICAL_BUSINESS_RULES.md; phân loại: PLANNED_CANONICAL_RULE_SOURCE. |
Phiếu nhận phải phản ánh lượng đã đặt; vượt lượng còn mở tạo chênh lệch cần xử lý, không được tự ghi nhận. |
| 4 | AC-NF-001 |
Khi gửi dữ liệu hợp lệ cho đơn mua PO-NF-260801-014, hệ thống tạo GRN-NF-260807-001, trạng thái RECEIVED, và lưu đúng 500.000 kg cùng lô CC-260807-A. |
REQ-NF-001, BR-NF-001; phân loại: SIMULATED_ACCEPTANCE_CRITERION. |
Acceptance criterion là điều kiện chấp nhận có thể kiểm tra; nó biến yêu cầu thành kết quả quan sát được. |
| 5 | DATA-NF-001 |
goods_receipt.receipt_no = GRN-NF-260807-001; purchase_order_no = PO-NF-260801-014; item_code = RM-COCOA-001; supplier_lot_code = CC-260807-A; received_quantity_kg = 500.000; uom = KG; receipt_date = 2026-08-07. |
REQ-NF-001; /01-curriculum/CANONICAL_DATA_DICTIONARY.md; phân loại: PLANNED_CANONICAL_DATA_SOURCE. |
Các trường này là dữ liệu tối thiểu để kiểm tra AC và đối chiếu lô, lượng, đơn mua. |
| 6 | API-NF-001 |
POST /api/v1/goods-receipts nhận dữ liệu phiếu nhận và trả về mã phiếu, trạng thái, thời điểm tạo. |
REQ-NF-001; OpenAPI Specification 3.1.1; phân loại: STANDARD_REFERENCE cho mô tả HTTP API, không phải cấu hình production. |
API là điểm trao đổi dữ liệu; hợp đồng request/response cho phép kiểm thử độc lập giao diện. |
| 7 | TC-NF-001 |
Gửi payload hợp lệ; kỳ vọng HTTP 201, receiptNo = GRN-NF-260807-001, status = RECEIVED, lượng 500.000. |
AC-NF-001, DATA-NF-001, API-NF-001; ISTQB CTFL v4.0.1; phân loại: SIMULATED_TEST_CASE và STANDARD_REFERENCE cho thuật ngữ kiểm thử. |
Test case kiểm tra trực tiếp điều kiện chấp nhận bằng dữ liệu xác định. |
| 8 | TC-NF-002 |
Gửi receivedQuantityKg = 0; kỳ vọng HTTP 422, mã RECEIVED_QUANTITY_MUST_BE_POSITIVE; không tạo phiếu nhận. |
REQ-NF-001; phân loại: SIMULATED_TEST_CASE. |
Giá trị biên bằng 0 vi phạm điều kiện lớn hơn 0; đây là đường kiểm thử âm. |
| 9 | TC-NF-003 |
Gửi receivedQuantityKg = 501.000 khi lượng đơn mua còn mở là 500.000; kỳ vọng HTTP 409, mã RECEIPT_QUANTITY_EXCEEDS_OPEN_PO; không tạo phiếu nhận. |
BR-NF-001; phân loại: SIMULATED_TEST_CASE. |
Lượng vượt ngưỡng quy tắc; hệ thống phải từ chối thay vì tự đổi số lượng đơn mua. |
| 10 | DEF-NF-001 |
Không ghi nhận tại v0.9.0. Chỉ tạo khi kết quả thực thi TC-NF-001 đến TC-NF-003 lệch AC hoặc BR và có bằng chứng tái lập. |
Không có bằng chứng lỗi trong micro-batch này; phân loại: NOT_APPLICABLE_YET. |
Tạo defect khi chưa chạy test sẽ biến giả định thành lỗi. |
| 11 | CR-NF-001 |
Không ghi nhận tại v0.9.0. Chỉ tạo change request khi thay đổi nhu cầu, yêu cầu, quy tắc, dữ liệu hoặc API sau khi có quyết định thay đổi được ghi nhận. |
Không có yêu cầu thay đổi được cung cấp; phân loại: NOT_APPLICABLE_YET. |
Không có thay đổi đầu vào thì không có cơ sở tạo CR. |
| Liên kết kiểm tra | Kết quả truy vết |
|---|---|
NEED-NF-001 đến REQ-NF-001 |
Nhu cầu truy xuất được chuyển thành yêu cầu dữ liệu bắt buộc và điều kiện hợp lệ. |
REQ-NF-001 đến BR-NF-001 |
Yêu cầu tạo phiếu nhận được giới hạn bởi lượng đơn mua còn mở. |
BR-NF-001 đến AC-NF-001 |
AC kiểm tra trường hợp hợp lệ; TC-NF-003 kiểm tra vi phạm quy tắc. |
REQ-NF-001 đến DATA-NF-001 và API-NF-001 |
Trường dữ liệu và hợp đồng HTTP là phương tiện kỹ thuật để truyền, lưu, kiểm tra yêu cầu. |
AC-NF-001, REQ-NF-001, BR-NF-001 đến TC-NF-001–TC-NF-003 |
Mỗi điều kiện có ít nhất một kiểm thử dương hoặc âm; không có test case mồ côi. |
TC-NF-001–TC-NF-003 đến DEF-NF-001 hoặc CR-NF-001 |
Chưa có liên kết thực thi vì chưa có kết quả test, defect hay thay đổi được ghi nhận. Không suy diễn baseline từ ma trận này. |
Bộ dữ liệu kiểm thử và bảng quyết định: chặn xuất kho lô hết hạn
Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi mã, ngày, số lượng và giá trị dưới đây là dữ liệu tổng hợp. Hàm cần kiểm thử: ERP chỉ cho phép xác nhận xuất kho khi lô hàng còn hạn dùng tại thời điểm xác nhận. Bảng quyết định biến điều kiện nghiệp vụ thành tổ hợp đầu vào và kết quả kỳ vọng; người học dùng từng hàng làm dữ liệu test, không suy diễn thành cấu hình ERP thực tế.
| Điều kiện / hành động | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
Mã lô tồn tại và trạng thái AVAILABLE |
Có | Có | Có | Không |
| Ngày hết hạn lớn hơn ngày xác nhận xuất | Có | Không | Không | Có |
| Số lượng yêu cầu không vượt tồn khả dụng | Có | Có | Không | Có |
| Cho phép xác nhận xuất | Có | Không | Không | Không |
| Kết quả kỳ vọng | Tạo phiếu xuất | Chặn do hết hạn | Chặn do thiếu tồn | Chặn do lô không khả dụng |
| Test data ID | Ngày giờ xác nhận, Asia/Ho_Chi_Minh |
Kho | SKU | Mã lô | Hạn dùng | Trạng thái lô | Tồn khả dụng | SL yêu cầu | Kết quả kỳ vọng |
|---|---|---|---|---|---|---|---|---|---|
TD-NF-EXP-001 |
2026-08-07T09:15:00+07:00 |
WH-HCM-01 |
SKU-NF-NUOCMAM-500 |
LOT-NF-260801-A |
2026-12-31 |
AVAILABLE |
240 | 120 | Áp dụng R1; tạo phiếu xuất mô phỏng DO-NF-260807-001; tồn khả dụng còn 120. |
TD-NF-EXP-002 |
2026-08-07T09:20:00+07:00 |
WH-HCM-01 |
SKU-NF-NUOCMAM-500 |
LOT-NF-250701-B |
2026-08-06 |
AVAILABLE |
80 | 20 | Áp dụng R2; từ chối xác nhận; không tạo phiếu xuất; tồn khả dụng giữ 80. |
TD-NF-EXP-003 |
2026-08-07T09:25:00+07:00 |
WH-HCM-01 |
SKU-NF-NUOCMAM-500 |
LOT-NF-260801-A |
2026-12-31 |
AVAILABLE |
120 | 121 | Áp dụng R3; từ chối xác nhận; không tạo phiếu xuất; tồn khả dụng giữ 120. |
TD-NF-EXP-004 |
2026-08-07T09:30:00+07:00 |
WH-HCM-01 |
SKU-NF-NUOCMAM-500 |
LOT-NF-260801-C |
2026-12-31 |
QUARANTINED |
60 | 10 | Áp dụng R4; từ chối xác nhận; không tạo phiếu xuất; tồn khả dụng giữ 60. |
{
"warehouseCode": "WH-HCM-01",
"confirmationAt": "2026-08-07T09:15:00+07:00",
"lines": [
{
"sku": "SKU-NF-NUOCMAM-500",
"lotCode": "LOT-NF-260801-A",
"requestedQuantity": 120,
"uom": "BOT"
}
],
"currency": "VND",
"dataClassification": "SYNTHETIC"
}
Payload mô tả dữ liệu đầu vào logic cho ca TD-NF-EXP-001, không phải hợp đồng API hay OpenAPI Specification. confirmationAt mang múi giờ rõ ràng để so sánh ngày hết hạn nhất quán; lotCode xác định lô cần kiểm tra; requestedQuantity là số lượng yêu cầu. Trường currency giữ locale case study VND dù giao dịch xuất kho này không tính tiền.
5. Tier 4 ? Senior BA Quality Gate
Senior BA Quality Gate là cổng rà soát trước baseline: Senior Business Analyst kiểm tra test data có đủ để kiểm thử, có khớp requirement và rule, và không vượt thẩm quyền chuyên môn. Kết quả PASS nghĩa là điều kiện kiểm tra có bằng chứng đầy đủ trong artifact đang IN_REVIEW; không phải approval, baseline, xác nhận tuân thủ hay cho phép production. FAIL nghĩa là phát hiện sai lệch có thể sửa trong phạm vi artifact. STOP nghĩa là không được tiếp tục baseline hoặc dùng dữ liệu làm test basis vì thiếu nguồn, mâu thuẫn kiểm soát, hoặc rủi ro thuộc thẩm quyền khác. ESCALATE nghĩa là chuyển gói bằng chứng đến đúng Owner có thẩm quyền; Senior BA chỉ ghi nhận và giữ traceability.
| ID kiểm tra | Hạng mục | Cách kiểm tra và cầu nối bằng chứng | PASS | FAIL | STOP | Escalation |
|---|---|---|---|---|---|---|
QG-TD-001 |
Tính đầy đủ | Đối chiếu từng field, dòng dữ liệu, payload, expected result, ngoại lệ và liên kết truy vết với phạm vi test đã nêu. Test data là đầu vào để tái tạo điều kiện kiểm thử; thiếu một phần tử làm kết quả không kiểm chứng được. | Mọi phần tử cần thiết có giá trị xác định. | Thiếu giá trị không làm đổi quyết định nghiệp vụ; bổ sung trong artifact. | Thiếu expected result, rule áp dụng, hoặc dữ liệu điều kiện quyết định. | QA Owner khi thiếu test basis; Business Owner khi thiếu quyết định nghiệp vụ. |
QG-TD-002 |
Tính nhất quán | So sánh ID, ngày giờ, kho, SKU, lô, đơn vị tính, số lượng, trạng thái và kết quả giữa bảng với JSON payload. Cùng một fact phải có cùng giá trị ở mọi biểu diễn. | Không có mâu thuẫn. | Sai định dạng hoặc lỗi chép lại cục bộ. | Cùng ID mang hai giá trị nghiệp vụ khác nhau, hoặc kết quả trái rule. | Principal IT Business Analyst / Technical Curriculum Author để điều phối sửa; Business Owner nếu rule mâu thuẫn. |
QG-TD-003 |
Khả năng kiểm thử | Kiểm tra mỗi ca có tiền điều kiện, hành động, dữ liệu đầu vào, kết quả mong đợi và trạng thái dữ liệu sau xử lý. Theo ISTQB CTFL, test case cần cho phép so sánh kết quả thực tế với kết quả mong đợi. | Tester tái chạy được ca mà không suy đoán. | Thiếu mô tả phụ trợ nhưng kết quả vẫn xác định. | Không xác định được pass/fail của ca, hoặc không tái tạo được điều kiện. | QA Owner. |
QG-TD-004 |
Truy vết | Mỗi ca phải liên kết rule, requirement hoặc quyết định nguồn bằng ID canonical; không dùng nhãn tự đặt thay nguồn. Traceability cho biết vì sao dữ liệu tồn tại và thay đổi nào bị ảnh hưởng. | Liên kết rõ, đúng ID và không đứt chuỗi. | Liên kết có nhưng sai vị trí hoặc sai định dạng. | Không có nguồn test basis, ID không đăng ký, hoặc một ca dựa trên suy diễn không ghi nhãn. | Owner của /01-curriculum/TRACEABILITY_ID_REGISTRY.md; Business Owner nếu cần xác nhận ý nghĩa nghiệp vụ. |
QG-TD-005 |
Thẩm quyền nguồn | Phân loại nguồn: canonical artifact, nguồn chuẩn chính thức, luật chính thức, project assumption, hoặc Verification required. Không biến nguồn học liệu thành quy định vận hành. |
Nguồn đúng loại và giới hạn sử dụng rõ. | Thiếu nhãn phân loại nguồn. | Rule pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo mật được khẳng định bắt buộc khi chưa có xác minh đúng thẩm quyền. | Legal Owner, Accounting Owner, Compliance Owner, Security Owner hoặc Domain Owner theo chủ đề. |
QG-TD-006 |
Ownership | Kiểm tra ai sở hữu quyết định về dữ liệu, rule, test result và thay đổi. Người ghi artifact không tự thay thế người có thẩm quyền phê duyệt. | Owner và giới hạn thẩm quyền được ghi rõ. | Thiếu tên vai trò review nội bộ. | Quyết định bị gán cho Senior BA hoặc curriculum owner khi thuộc Business, Legal, Accounting, Security, Architect hoặc QA. | Vai trò có thẩm quyền tương ứng. |
QG-TD-007 |
Bảo mật và riêng tư | Xác nhận Nova Foods là mô phỏng giáo dục, SYNTHETIC, không chứa dữ liệu cá nhân thật, thông tin đăng nhập, khóa bí mật, dữ liệu khách hàng thật hay dữ liệu production. Tham chiếu pháp luật dữ liệu cá nhân chỉ là bối cảnh; yêu cầu tuân thủ cần Legal Owner xác minh. |
Chỉ có dữ liệu tổng hợp, phân loại rõ, không có bí mật. | Nhãn SYNTHETIC thiếu tại một biểu diễn dữ liệu. |
Phát hiện dữ liệu thật, secret, định danh cá nhân thật, hoặc yêu cầu truy cập hệ thống thật. | Security Owner và Legal Owner; dừng chia sẻ rộng cho đến khi xử lý. |
QG-TD-008 |
Ranh giới pháp lý, kế toán, hóa đơn và an toàn thực phẩm | Kiểm tra dữ liệu không diễn giải Luật Kế toán, Nghị định 123/2020/NĐ-CP, Luật Bảo vệ dữ liệu cá nhân, Nghị định 356/2025/NĐ-CP hoặc Luật An toàn thực phẩm thành cấu hình ERP bắt buộc. Những nội dung chưa đối chiếu văn bản chính thức hiện hành phải ghi Verification required hoặc project assumption. |
Không có kết luận vượt nguồn hoặc thẩm quyền. | Thiếu nhãn Verification required. |
Artifact khẳng định tuân thủ, định khoản, thuế, hóa đơn, lưu trữ chứng từ hoặc truy xuất thực phẩm là đúng cho vận hành thực. | Legal Owner, Accounting Owner, Tax Owner hoặc Food Safety Domain Owner. |
QG-TD-009 |
Tác động thay đổi | Kiểm tra thay đổi field, rule, trạng thái, thời gian, số lượng hoặc expected result có danh sách ca bị ảnh hưởng và liên kết artifact nguồn. Một thay đổi rule có thể làm vô hiệu expected result cũ. | Tác động và ca cần kiểm thử lại được xác định. | Danh sách tác động chưa đủ chi tiết nhưng nguồn thay đổi rõ. | Thay đổi canonical rule hoặc data definition không có phân tích tác động, hoặc làm đứt traceability. | Owner của CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, QA Owner và Architect khi có tác động kỹ thuật. |
QG-TD-010 |
Trạng thái quản trị | Kiểm tra filename /03-templates/TMPL-TST-002_TEST_DATA.md, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. |
Metadata khớp hợp đồng corpus. | Lỗi trình bày metadata không làm đổi nội dung. | Gọi artifact là BASELINED, APPROVED, production-ready hoặc đã được người dùng chấp thuận khi không có tham chiếu kiểm soát. |
Principal IT Business Analyst / Technical Curriculum Author. |
Quy tắc quyết định: Một STOP có ưu tiên cao hơn mọi PASS; không cộng điểm để bù lỗi dừng. Một ESCALATE mở thì kết quả toàn bộ quality gate là IN_REVIEW — ESCALATION OPEN. Chỉ sau khi Owner có thẩm quyền ghi kết luận trong artifact kiểm soát, Senior BA mới được rà soát lại mục liên quan.
Ma trận kiểm tra chất lượng dữ liệu kiểm thử
Dữ liệu kiểm thử là giá trị đầu vào, bản ghi nền, điều kiện truy cập và kết quả mong đợi dùng để chứng minh yêu cầu ERP hoạt động hoặc bị từ chối đúng. Senior BA kiểm tra dữ liệu trước baseline để tránh tình trạng ca kiểm thử có vẻ chạy được nhưng không chứng minh đúng quy tắc, nguồn hay ranh giới trách nhiệm. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi giá trị chỉ là dữ liệu tổng hợp, dùng vi-VN, Asia/Ho_Chi_Minh và VND.
| Khía cạnh | Câu hỏi kiểm tra từ nguyên lý | Bằng chứng phải có trong TMPL-TST-002_TEST_DATA |
Lý do kết luận | Ranh giới quyết định |
|---|---|---|---|---|
| Tính đầy đủ | Mỗi ca kiểm thử có đủ dữ liệu đầu vào, dữ liệu nền, quyền người dùng, tiền điều kiện và kết quả mong đợi không? | Mỗi dòng dữ liệu gắn Test Case ID, tên trường, giá trị tổng hợp, trạng thái bản ghi, vai trò mô phỏng, tiền điều kiện, expected result. |
Thiếu một thành phần làm người thực thi tự đoán; kết quả không lặp lại được. | BA ghi thiếu hụt; QA xác nhận đủ để thực thi. |
| Tính nhất quán | Cùng một mã, ngày, đơn vị tính, tiền tệ, trạng thái hay quy tắc có giữ cùng nghĩa giữa test data, test case và nguồn canonical không? | So sánh với CANONICAL_DATA_DICTIONARY, CANONICAL_BUSINESS_RULES, TRACEABILITY_ID_REGISTRY; dùng đúng VND, định dạng ngày vi-VN, múi giờ Asia/Ho_Chi_Minh. |
Một giá trị mang hai nghĩa tạo lỗi giả hoặc che lỗi thật. | BA không tự đổi nghĩa trường hay quy tắc canonical. |
| Khả năng kiểm thử | Giá trị có tạo được quan sát nhị phân: hệ thống chấp nhận, từ chối, tính đúng, chặn đúng quyền, hay ghi nhận đúng không? | Giá trị biên, giá trị hợp lệ, giá trị không hợp lệ, kết quả mong đợi đo được; không dùng nhận xét mơ hồ như “xử lý phù hợp”. | Test cần điều kiện xác minh được, không dựa vào cảm nhận người chạy. | QA sở hữu kỹ thuật kiểm thử; BA bảo toàn liên kết business rule. |
| Khả năng truy vết | Mỗi dữ liệu chứng minh yêu cầu, quy tắc, rủi ro hoặc quyết định nào? | Liên kết Test Data ID với Test Case ID, requirement ID hoặc rule ID canonical, artifact nguồn, phiên bản v0.9.0. |
Không truy vết được thì không biết dữ liệu tồn tại để chứng minh gì và thay đổi nào bị ảnh hưởng. | Không tạo ID biến thể ngoài TRACEABILITY_ID_REGISTRY. |
| Thẩm quyền nguồn | Giá trị hoặc quy tắc lấy từ nguồn nào, nguồn đó có quyền quyết định nội dung không? | Phân loại nguồn: canonical nội bộ, giả định dự án, nguồn pháp lý chính thức, chuẩn kỹ thuật chính thức, hoặc Verification required. |
Nguồn hướng dẫn không tự biến thành nghĩa vụ pháp lý hay chính sách Nova Foods. | Legal Owner xác minh nghĩa vụ pháp lý; Accounting Owner xác minh hạch toán; không suy diễn từ URL thành điều khoản. |
| Ownership | Ai tạo, xác nhận nghiệp vụ, xác nhận kỹ thuật, giữ dữ liệu và xử lý thay đổi? | Owner theo vai trò cho từng tập dữ liệu: BA, Business Owner, QA, Security, Legal Owner, Accounting Owner, Data Owner. | Có người chịu trách nhiệm rõ giúp ngăn BA hoặc QA tự nhận thẩm quyền ngoài phạm vi. | Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì artifact, không phê duyệt nội dung nghiệp vụ hay production. |
| Bảo mật và riêng tư | Dữ liệu có chứa dữ liệu cá nhân, bí mật xác thực, thông tin tài khoản, dữ liệu khách hàng thật hoặc dữ liệu nhạy cảm không? | Nhãn phân loại dữ liệu, loại dữ liệu tổng hợp, vai trò truy cập mô phỏng, biện pháp che giấu nếu có trường nhạy cảm. | Test data rò rỉ có thể gây hại dù hệ thống chưa production. | Không dùng người thật, số điện thoại thật, email thật, token, mật khẩu, số tài khoản hoặc định danh thật. Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP cần Legal Owner xác minh trước khi suy ra yêu cầu hệ thống. |
| Pháp lý, kế toán, hóa đơn và an toàn thực phẩm | Dữ liệu có mô phỏng thuế, bút toán, hóa đơn, chứng từ, truy xuất lô hay thu hồi không? | Nhãn project assumption hoặc Verification required; liên kết nguồn chính thức nếu đã dùng; owner chuyên môn được chỉ định. |
Giá trị minh họa như thuế suất, định khoản, số hóa đơn hay thời hạn lưu trữ không phải kết luận pháp lý hoặc kế toán. | Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP, Luật An toàn thực phẩm 55/2010/QH12 là ranh giới tham chiếu; Accounting Owner, Legal Owner và domain owner quyết định diễn giải. |
| Ảnh hưởng thay đổi | Khi đổi trường dữ liệu, quy tắc, quyền hay trạng thái, tập dữ liệu nào và ca kiểm thử nào phải xem lại? | Danh sách liên kết ngược từ trường dữ liệu tới Test Data ID, Test Case ID, rule ID và artifact canonical. |
Thay đổi không phân tích ảnh hưởng dễ để dữ liệu cũ xác minh quy tắc mới. | BA ghi phạm vi ảnh hưởng; owner từng artifact xác nhận thay đổi thuộc thẩm quyền. |
Quy tắc áp dụng: một dữ liệu chỉ được dùng làm bằng chứng khi giá trị, nguồn, mục tiêu kiểm thử và liên kết truy vết cùng hiện diện. Ví dụ, giá trị tổng hợp 25.000 VND chỉ chứng minh được phép tính nếu chỉ rõ trường tiền tệ, quy tắc làm tròn hoặc tính tiền liên quan, ca kiểm thử dùng giá trị đó và expected result. Nếu chỉ có 25.000 VND, giá trị là mẫu minh họa, chưa là dữ liệu kiểm thử đủ căn cứ.
IN_REVIEW và v0.9.0 nghĩa là nội dung còn xem xét. Không diễn giải bảng này là baseline, phê duyệt, xác nhận tuân thủ, xác nhận kế toán, xác nhận pháp lý hay quyền dùng production.
Áp dụng Quality Gate cho bản Nova Foods hoàn chỉnh
Bản áp dụng này kiểm tra Tier 3 của TMPL-TST-002_TEST_DATA cho Nova Foods Trading & Manufacturing, case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Pass nghĩa là bằng chứng đủ để tiếp tục review; Fail nghĩa là nội dung sai hoặc thiếu nhưng chưa chặn toàn bộ; Stop nghĩa là không được baseline; Escalation nghĩa là chuyển đúng vai trò có thẩm quyền quyết định.
| Hạng mục kiểm tra | Bằng chứng trong ví dụ Nova Foods | Cầu nối suy luận | Kết quả | Ghi nhận xử lý |
|---|---|---|---|---|
| Tính đầy đủ | Tier 3 có core record, dữ liệu đầu vào, kết quả mong đợi, ngoại lệ và liên kết evidence tại Tier 3. | Test data chỉ tái lập được khi đủ giá trị nhập, tiền điều kiện và kết quả kỳ vọng. | Pass | Không thấy trường mô tả bằng placeholder tại Tier 3. |
| Tính nhất quán | Context corpus dùng vi-VN, Asia/Ho_Chi_Minh, VND, ngày 2026-08-07, Status IN_REVIEW, Version v0.9.0. |
Dữ liệu test mâu thuẫn locale, múi giờ hoặc tiền tệ sẽ làm kết quả tính toán và hiển thị không lặp lại được. | Pass | Giữ nguyên định dạng ngày, thời gian và VND của record đã hoàn chỉnh. |
| Khả năng kiểm thử | Ví dụ có dữ liệu hợp lệ, dữ liệu biên và dữ liệu không hợp lệ; mỗi kết quả mong đợi có tiêu chí quan sát được. | Kiểm thử hộp đen cần đầu vào và đầu ra quan sát được, không dựa vào suy đoán nội bộ hệ thống. | Pass | QA vẫn phải chạy test trên môi trường mô phỏng phù hợp trước khi dùng làm bằng chứng thực thi. |
| Truy vết | Liên kết quản trị dùng TRACEABILITY_ID_REGISTRY, quy tắc dùng CANONICAL_BUSINESS_RULES, trường dữ liệu dùng CANONICAL_DATA_DICTIONARY. |
Một test record không truy về rule, data definition và nguồn evidence thì không chứng minh được lý do tồn tại. | Pass | Liên kết là traceability học liệu; không xác nhận rule vận hành ERP thực tế. |
| Thẩm quyền nguồn | BABOK Guide, ISTQB CTFL v4.0.1 và nguồn pháp lý trong source seed được gắn đúng ranh giới sử dụng. | BABOK hỗ trợ thuật ngữ BA; ISTQB hỗ trợ thuật ngữ test; nguồn pháp lý chỉ là nguồn chính thức cần vai trò chuyên môn diễn giải. | Pass có điều kiện | Không suy diễn số điều, nghĩa vụ pháp lý hoặc tiêu chí tuân thủ từ catalog nguồn. |
| Ownership | Owner corpus là Principal IT Business Analyst / Technical Curriculum Author; giới hạn thẩm quyền đã nêu trong artifact nguồn. | Người duy trì template có thể bảo toàn cấu trúc và traceability, nhưng không thay Business Owner, QA, Legal, Accounting, Security hoặc Architect. | Pass | Không có tên người phê duyệt, baseline reference hoặc approval reference. |
| Bảo mật và riêng tư | Nova Foods được ghi là mô phỏng; dữ liệu tổng hợp; không có thông tin cá nhân thật, thông tin đăng nhập, khóa API hoặc dữ liệu khách hàng thật. | Dữ liệu test phải loại rủi ro lộ dữ liệu tại trust boundary, gồm nhập liệu, API và xuất báo cáo. | Pass | Nếu record sau này chứa dữ liệu cá nhân hoặc định danh thật, chuyển Security Owner và Legal/Privacy Owner trước khi dùng. |
| Ranh giới pháp lý | Luật 91/2025/QH15 và Nghị định 356/2025/NĐ-CP là nguồn chính thức trong seed, nhưng yêu cầu hệ thống phát sinh từ chúng cần Legal Owner xác minh. | Nguồn chính thức không tự tạo diễn giải áp dụng cho Nova Foods mô phỏng hoặc production. | Stop | Không baseline bất kỳ yêu cầu privacy nào được diễn đạt là nghĩa vụ bắt buộc khi chưa có xác minh Legal Owner. |
| Ranh giới kế toán và hóa đơn | Luật 88/2015/QH13 và Nghị định 123/2020/NĐ-CP có trong source seed; không có kết luận cấu hình hạch toán, thuế hoặc hóa đơn điện tử. | Test data liên quan số tiền VND có thể ảnh hưởng accounting treatment; BA không được tự xác nhận cách hạch toán. | Stop | Chuyển Accounting Owner và Legal Owner nếu test case được mở rộng sang bút toán, thuế hoặc hóa đơn. |
| Ranh giới an toàn thực phẩm và truy xuất | Luật 55/2010/QH12 chỉ được dùng làm context; không có khẳng định Nova Foods đáp ứng truy xuất hoặc recall. | Dữ liệu lô hàng, hạn dùng và thu hồi có hậu quả domain; cần domain-owner xác minh. | Escalation | Chuyển Food Safety/Operations Owner khi Tier 3 dùng dữ liệu để quyết định release, recall hoặc truy xuất thực tế. |
| Tác động thay đổi | IN_REVIEW và chưa có baseline reference tại v0.9.0; thay đổi field, expected result hoặc trace link có thể làm lệch test basis. |
Khi nguồn dữ liệu hoặc rule thay đổi, test data cũ không còn chứng minh đúng hành vi cần kiểm tra. | Fail | Ghi change record, kiểm tra lại liên kết tới ba artifact canonical trước khi thay nội dung. |
Kết luận review: Cấu trúc test data Nova Foods mô phỏng đạt mức dùng để tiếp tục review học liệu. Có hai điều kiện Stop: diễn giải privacy/pháp lý và diễn giải kế toán/hóa đơn chưa có xác minh của vai trò có thẩm quyền. Không có approval, baseline, compliance sign-off hoặc xác nhận sẵn sàng production được ghi nhận.
6. Cross-File Checks, Open Issues, and Escalation
6.1 Kiểm tra chéo nguồn kiểm soát
Kiểm tra chéo nhằm bảo đảm cùng một dữ kiện chỉ có một nguồn chuẩn, gọi là canonical source: artifact được chỉ định làm nguồn quyết định cho loại dữ kiện đó. Kiểm tra này không xác nhận nghiệp vụ Nova Foods đúng ngoài đời thực. 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.
| Đối tượng kiểm tra | Nguồn chuẩn phải đối chiếu | Bằng chứng đối chiếu | Kết quả tại IN_REVIEW v0.9.0 |
Tiêu chí mâu thuẫn |
|---|---|---|---|---|
| Định danh template và đường dẫn | /01-curriculum/TEMPLATE_MANIFEST.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md |
Template hiện hành dùng ID TMPL-TST-002; đường dẫn /03-templates/TMPL-TST-002_TEST_DATA.md. |
Không được tự đổi ID, tên tệp, tiền tố TMPL, hoặc đường dẫn trong template. Cần đối chiếu đăng ký chính thức trước khi gọi ID là đã đăng ký. |
Manifest hoặc registry ghi ID, tên tệp, loại artifact khác với TMPL-TST-002 hoặc /03-templates/TMPL-TST-002_TEST_DATA.md. |
| Trạng thái, phiên bản, locale | CHAPTER_MANIFEST; TEMPLATE_MANIFEST; TRACEABILITY_ID_REGISTRY; CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY |
Mọi artifact phụ thuộc được cung cấp cùng trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND. |
Nhất quán ở cấp metadata được cung cấp. IN_REVIEW không phải APPROVED, BASELINED, compliant, production-ready hoặc user-approved. |
Bất kỳ artifact nào gắn APPROVED, BASELINED, phiên bản khác, ngày khác, locale khác, hoặc tiền tệ thực ngoài VND mô phỏng mà không có change record. |
| Quy tắc nghiệp vụ | /01-curriculum/CANONICAL_BUSINESS_RULES.md |
Catalog quy tắc là nguồn chuẩn cho business rule; template test data không được tự tạo rule từ expected result. | Test data chỉ tham chiếu rule đã tồn tại và giữ nguyên ID rule. Không có rule Nova Foods cụ thể được xác nhận trong đầu vào này. | Expected result, exception, dữ liệu đầu vào hoặc verdict tạo nghĩa vụ nghiệp vụ không có liên kết rule canonical. |
| Định nghĩa trường dữ liệu | /01-curriculum/CANONICAL_DATA_DICTIONARY.md |
Data dictionary là nguồn chuẩn cho tên logic, ý nghĩa, kiểu, miền giá trị và phân loại dữ liệu. | Template không được đổi nghĩa field bằng tên cột, giá trị mẫu hoặc ghi chú test. Dữ liệu tổng hợp không chứng minh cấu hình ERP thật. | Một field cùng tên có kiểu, định nghĩa, format, sensitivity classification hoặc allowed value khác data dictionary. |
| Cấu trúc học liệu liên quan | /01-curriculum/01_CURRICULUM_ARCHITECTURE.md; /01-curriculum/CHAPTER_MANIFEST.md; /01-curriculum/TEMPLATE_MANIFEST.md |
Architecture quy định chuỗi requirement, acceptance criteria, traceability và test basis; manifest kiểm soát phạm vi chapter/template. | Test data là đầu ra hỗ trợ kiểm thử; không thay requirement, acceptance criteria, test basis hoặc quyết định vận hành. | Template yêu cầu người học suy diễn rule, acceptance criterion hoặc quyết định Nova Foods khi artifact nguồn chưa cung cấp nội dung đó. |
| Consumer hạ nguồn | Test case, test execution record, defect record, traceability matrix và báo cáo kiểm thử được tạo sau template này | Consumer phải giữ TMPL-TST-002, ID dữ liệu, nguồn rule/data dictionary và status nguồn. |
Không có consumer nào được phép diễn giải test data là bằng chứng compliance, phê duyệt, baseline hoặc sẵn sàng production. | Consumer làm mất trace link, đổi expected result, dùng dữ liệu mô phỏng làm dữ liệu thật, hoặc nâng trạng thái IN_REVIEW. |
| Nguồn pháp lý, chuẩn và good practice | /00-research/00_SOURCE_MAP.md và verified primary-source seed |
BABOK Guide, ISTQB CTFL, ISO/IEC/IEEE 29148, OWASP, WCAG, OpenAPI và nguồn pháp lý Việt Nam có ranh giới sử dụng riêng. | Chỉ dùng nguồn cho thuật ngữ, phương pháp hoặc context đã nêu. Không suy ra nghĩa vụ pháp lý, kế toán, thuế, privacy, an toàn thực phẩm hoặc cấu hình production. | Test data nêu yêu cầu bắt buộc pháp lý, kết luận kế toán, compliance claim hoặc cấu hình ERP mà không có xác minh vai trò có thẩm quyền. |
6.2 Quy tắc xác định mâu thuẫn
Một liên kết được xem là hợp lệ khi ID nguồn, phiên bản nguồn, ý nghĩa dữ liệu, rule tham chiếu và mục đích kiểm thử cùng chỉ đến một cách hiểu. Ví dụ, nếu một test row dùng trường expiryDate, data dictionary phải là nơi quyết định ý nghĩa và format của trường; canonical rule catalog phải là nơi quyết định điều kiện nghiệp vụ liên quan hạn dùng; test case chỉ dùng test data để kiểm tra điều kiện đó. Nếu ba artifact cho ba ý nghĩa khác nhau, không được chọn theo suy đoán của BA.
Không dùng nguồn học thuật hoặc nguồn pháp lý làm bằng chứng trực tiếp cho một giá trị Nova Foods mô phỏng. BABOK Guide hỗ trợ thuật ngữ BA; ISTQB CTFL hỗ trợ thuật ngữ và kỹ thuật kiểm thử; ISO/IEC/IEEE 29148 hỗ trợ khái niệm requirements; các nguồn pháp lý Việt Nam chỉ tạo context cần xác minh. Cầu nối suy luận là: nguồn ngoài giải thích phương pháp, artifact canonical của corpus mới kiểm soát ID và nội dung mô phỏng, còn vai trò có thẩm quyền mới có thể xác nhận nghĩa vụ thực tế.
6.3 Kết quả kiểm tra cho phạm vi micro-batch
| Hạng mục | Trạng thái kiểm tra | Kết luận kiểm soát |
|---|---|---|
| Metadata corpus | Pass có điều kiện | Giữ nguyên IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND. |
| Ranh giới mô phỏng | Pass | Không có nội dung nào gọi Nova Foods là doanh nghiệp thật, cấu hình ERP thật hoặc dữ liệu thật. |
| Authority boundary | Pass có điều kiện | Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability và governance; không có quyền baseline, approval, legal, accounting, security, compliance hoặc production decision. |
| Canonical rule và data link | Verification required | Đầu vào không cung cấp ID rule, ID field hoặc row dữ liệu cụ thể của TMPL-TST-002; không được bịa liên kết. Chỉ kiểm tra được cơ chế liên kết và nguồn chuẩn. |
Đăng ký TMPL-TST-002 |
Verification required | Cần đối chiếu entry nguyên văn trong TEMPLATE_MANIFEST và TRACEABILITY_ID_REGISTRY trước khi xác nhận registration status. |
| Consumer hạ nguồn | Verification required | Chưa có test case, execution record, defect record hoặc traceability matrix cụ thể để so khớp từng ID. Không suy diễn rằng consumer đã tồn tại hoặc đã dùng template. |
Sổ vấn đề mở, giả định dự án và mục cần xác minh
Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. “Vấn đề mở” là điểm chưa đủ căn cứ để chốt dữ liệu kiểm thử. “Giả định dự án” là lựa chọn tạm để minh họa, không phải quy tắc vận hành. “Cần xác minh” là nội dung chỉ vai trò có thẩm quyền mới kết luận. Mọi mục dưới đây giữ IN_REVIEW, v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND.
| ID theo dõi | Loại | ID/tệp bị ảnh hưởng | Bằng chứng và cầu nối suy luận | Owner xử lý | Ảnh hưởng | Hành động kế tiếp |
|---|---|---|---|---|---|---|
OI-TST-001 |
Vấn đề mở | TMPL-TST-002; /03-templates/TMPL-TST-002_TEST_DATA.md; TEMPLATE_MANIFEST |
TEMPLATE_MANIFEST ở IN_REVIEW, chưa baseline, chưa approval. Vì test data chỉ được dùng làm học liệu, không thể gắn nhãn dữ liệu sẵn sàng production. |
Principal IT Business Analyst / Technical Curriculum Author | Cao: người học có thể hiểu sai dữ liệu mô phỏng là cấu hình ERP thật. | Giữ nhãn simulated/synthetic trên mọi Tier 3 record; chỉ đổi trạng thái khi artifact kiểm soát ghi nhận thay đổi hợp lệ. |
ASM-TST-001 |
Giả định dự án | TMPL-TST-002; CANONICAL_DATA_DICTIONARY |
Metadata corpus quy định vi-VN, Việt Nam, VND. Chưa có data dictionary đã xác nhận kiểu dữ liệu vật lý. Vì vậy dùng ngày YYYY-MM-DD, tiền tệ VND, tên và mã tổng hợp để minh họa. |
Principal IT Business Analyst / Technical Curriculum Author | Trung bình: định dạng minh họa có thể khác ERP thật. | Gắn từng payload Tier 3 với trường logic từ CANONICAL_DATA_DICTIONARY; không suy ra schema, độ dài cột, khóa DB hoặc API thật. |
VR-TST-001 |
Cần xác minh | CANONICAL_DATA_DICTIONARY; TMPL-TST-002 |
CANONICAL_DATA_DICTIONARY là nguồn canonical cho nghĩa trường dữ liệu. Seed chỉ cung cấp metadata, không cung cấp định nghĩa trường Nova Foods đã được xác nhận. Vì thiếu nguồn trường, không thể kết luận giá trị biên, bắt buộc hay quan hệ dữ liệu. |
Data Owner và Business Owner | Cao: test case có thể kiểm sai rule hoặc bỏ sót dữ liệu bắt buộc. | Data Owner xác nhận định nghĩa logic, kiểu, miền giá trị, nullability và quan hệ; cập nhật traceability trước khi dùng test data làm test basis. |
VR-TST-002 |
Cần xác minh | CANONICAL_BUSINESS_RULES; TMPL-TST-002 |
CANONICAL_BUSINESS_RULES nêu rõ Owner không xác nhận quy tắc vận hành. Seed không chứa rule Nova Foods đã được phê duyệt. Vì vậy kết quả mong đợi trong test data không được diễn đạt là business rule thật. |
Business Owner | Cao: expected result có thể bị hiểu là quyết định nghiệp vụ. | Business Owner xác nhận rule, ngoại lệ và tiêu chí chấp nhận; liên kết rule ID canonical vào record test sau khi có nguồn kiểm soát. |
VR-TST-003 |
Cần xác minh | TMPL-TST-002; Luật 91/2025/QH15; Nghị định 356/2025/NĐ-CP |
Seed xác nhận nguồn pháp lý bảo vệ dữ liệu cá nhân nhưng yêu cầu Legal Owner xác minh mọi requirement suy ra. Vì dữ liệu test có thể mô phỏng khách hàng, nhân viên hoặc liên hệ, không được tự kết luận cách xử lý dữ liệu cá nhân. | Legal Owner và Privacy/Compliance Owner | Cao: rủi ro diễn giải pháp lý sai hoặc dùng dữ liệu thật. | Xác nhận phạm vi dữ liệu cá nhân, căn cứ xử lý, che giấu dữ liệu và thời hạn lưu cho môi trường thật; trước đó chỉ dùng tên, số điện thoại, email tổng hợp không gắn người thật. |
VR-TST-004 |
Cần xác minh | TMPL-TST-002; Luật 88/2015/QH13; Nghị định 123/2020/NĐ-CP |
Seed yêu cầu Accounting Owner hoặc Legal Owner xác minh diễn giải kế toán, thuế và hóa đơn. Không có điều khoản đã kiểm chứng cho cách tính, đánh số hoặc lưu chứng từ Nova Foods. | Accounting Owner và Legal Owner | Cao: test data tài chính có thể bị hiểu là hướng dẫn tuân thủ. | Giữ số tiền chỉ là VND tổng hợp; không kết luận thuế suất, hạch toán, số hóa đơn hay retention. Xác minh văn bản hiện hành trước nội dung production. |
VR-TST-005 |
Cần xác minh | TMPL-TST-002; Luật 55/2010/QH12 |
Seed nêu luật an toàn thực phẩm chỉ cho bối cảnh truy xuất/thu hồi và yêu cầu domain-owner, legal verification. Vì không có quy tắc lô hàng Nova Foods đã xác nhận, không thể suy ra cấu trúc mã lô hoặc quy trình recall. | Food Safety Domain Owner và Legal Owner | Cao: sai traceability sản phẩm hoặc ngộ nhận tuân thủ. | Xác nhận dữ liệu lô, hạn dùng, truy xuất và thu hồi cho phạm vi thật; dữ liệu Tier 3 chỉ minh họa tổng hợp. |
VR-TST-006 |
Cần xác minh | TMPL-TST-002; OWASP ASVS 5.0.0; OWASP API Security Top 10 2023 |
Seed phân loại OWASP là chuẩn kiểm chứng ngành/good practice, không phải luật Việt Nam. Không có kiến trúc, phân quyền hay API Nova Foods được xác nhận. Vì vậy không thể chốt test data cho token, role, endpoint hoặc log bảo mật. | Security Owner và Solution Architect | Cao: dữ liệu test có thể làm lộ bí mật hoặc kiểm sai kiểm soát truy cập. | Xác nhận data classification, role matrix, masking, secret handling và API contract; cấm password, token, khóa API và dữ liệu định danh thật trong template. |
VR-TST-007 |
Cần xác minh | TMPL-TST-002; ISTQB CTFL Syllabus v4.0.1 |
ISTQB là nguồn thuật ngữ và kỹ thuật test; seed không cấp test strategy Nova Foods. Vì vậy phân vùng tương đương, giá trị biên và dữ liệu âm chỉ là kỹ thuật học tập, chưa đủ để xác nhận coverage dự án. | QA Owner | Trung bình: thiếu hoặc thừa test data so với rủi ro thật. | QA Owner xác nhận test level, test basis, coverage, môi trường và exit criteria; ghi liên kết tới test case/requirement canonical khi các ID tồn tại. |
ASM-TST-002 |
Giả định dự án | TMPL-TST-002; TRACEABILITY_ID_REGISTRY |
TRACEABILITY_ID_REGISTRY là nguồn định danh canonical, nhưng seed không cung cấp ID test-case, requirement hoặc data-record dành riêng cho template này. Vì vậy chỉ dùng ID artifact đã công bố, không tự tạo ID canonical mới. |
Principal IT Business Analyst / Technical Curriculum Author | Trung bình: tránh collision và traceability giả. | Đăng ký ID mới theo registry trước khi tham chiếu chéo; đến lúc đó ghi đường dẫn artifact và loại nguồn thay vì bịa ID requirement/test case. |
OI-TST-002 |
Vấn đề mở | CHAPTER_MANIFEST; TEMPLATE_MANIFEST; TMPL-TST-002 |
Hai manifest là planning artifact, đều IN_REVIEW; seed không cung cấp downstream consumer cụ thể của test data. Vì thiếu consumer contract, không thể chốt CSV, JSON, SQL hay import mapping. |
Solution Architect và QA Owner | Trung bình: sai định dạng bàn giao hoặc lỗi import. | Xác nhận consumer, định dạng trao đổi, encoding, delimiter, schema version và quy tắc nạp dữ liệu trước khi tạo dữ liệu dùng cho công cụ. |
Không mục nào trong bảng tạo approval, baseline, quyết định pháp lý, kế toán, bảo mật, kiến trúc hay vận hành. Owner template chỉ điều phối, giữ liên kết TMPL-TST-002 và chuyển mục đúng thẩm quyền; kết luận chỉ được ghi trong artifact kiểm soát của vai trò có thẩm quyền.
6.1 Bàn giao cuối và quy tắc lan truyền thay đổi
Bàn giao (handoff) là chuyển gói dữ liệu kiểm thử để vai trò nhận có thể dùng, truy vết và phản hồi mà không tự suy diễn quy tắc mới. Gói này thuộc Nova Foods Trading & Manufacturing mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. TMPL-TST-002 giữ IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải baseline, approval, xác nhận chất lượng, xác nhận tuân thủ hay quyền dùng production.
| Thành phần bàn giao | Giá trị kiểm soát | Vai trò nhận được phép làm | Vai trò nhận không được phép làm |
|---|---|---|---|
| Template dữ liệu kiểm thử | /03-templates/TMPL-TST-002_TEST_DATA.md |
Dùng làm mẫu ghi dữ liệu kiểm thử, liên kết test case và ghi phát hiện review | Tuyên bố dữ liệu là production-ready hoặc đã được phê duyệt |
| Danh mục template | /01-curriculum/TEMPLATE_MANIFEST.md |
Kiểm tra ID, đường dẫn, trạng thái và phạm vi template | Tự đổi ID hoặc đăng ký ngầm template mới |
| Registry định danh | /01-curriculum/TRACEABILITY_ID_REGISTRY.md |
Xác nhận ID traceability tồn tại và dùng đúng cú pháp canonical | Tái sử dụng ID cho đối tượng khác hoặc tạo ID chưa đăng ký |
| Catalog quy tắc | /01-curriculum/CANONICAL_BUSINESS_RULES.md |
Đối chiếu rule làm test basis, tức cơ sở để thiết kế kiểm thử | Suy diễn rule mới từ giá trị dữ liệu kiểm thử |
| Từ điển dữ liệu | /01-curriculum/CANONICAL_DATA_DICTIONARY.md |
Đối chiếu tên trường, kiểu dữ liệu, miền giá trị và ý nghĩa logic | Chuyển định nghĩa logic thành cấu hình ERP hoặc quyết định kỹ thuật |
| Danh mục chapter | /01-curriculum/CHAPTER_MANIFEST.md |
Xác nhận dependency học liệu và nơi nhận traceability | Diễn giải chapter manifest thành approval nội dung |
Quy tắc lan truyền thay đổi: thay đổi chỉ bắt đầu khi có yêu cầu thay đổi được ghi nhận, nêu rõ artifact nguồn, ID bị ảnh hưởng, lý do, người đề xuất, thời điểm Asia/Ho_Chi_Minh và mức ảnh hưởng. Không sửa im lặng dữ liệu, tên trường, ID, rule reference, đường dẫn hay trạng thái. Bằng chứng là các artifact kiểm soát đều quy định IN_REVIEW, v0.9.0, chưa có baseline reference và chưa có approval reference; vì vậy thay đổi phải giữ được lịch sử, không được gắn nhãn BASELINED hoặc APPROVED.
| Loại thay đổi | Điểm khởi phát canonical | Lan truyền bắt buộc | Người quyết định | Điều kiện hoàn tất |
|---|---|---|---|---|
| Đổi hoặc bổ sung ID | TRACEABILITY_ID_REGISTRY |
Cập nhật mọi liên kết trong TMPL-TST-002, template manifest và artifact dùng ID |
Principal IT Business Analyst / Technical Curriculum Author chỉ điều phối registry; thẩm quyền chuyên môn liên quan giữ nguyên | ID không trùng, liên kết cũ được truy vết, lịch sử thay đổi được ghi |
| Đổi định nghĩa trường hoặc miền dữ liệu | CANONICAL_DATA_DICTIONARY |
Rà soát payload, dữ liệu biên, expected result và traceability trong TMPL-TST-002 |
Data owner hoặc Architect xác nhận nội dung thuộc thẩm quyền; Owner corpus điều phối | Không còn dữ liệu trái định nghĩa canonical |
| Đổi quy tắc nghiệp vụ | CANONICAL_BUSINESS_RULES |
Rà soát test basis, expected result và test case liên quan | Business Owner; Legal Owner, Accounting Owner hoặc Security khi rule chạm phạm vi đó | Quy tắc và dữ liệu kiểm thử cùng phiên bản tham chiếu |
| Đổi cấu trúc hoặc trạng thái template | TEMPLATE_MANIFEST |
Rà soát /03-templates/TMPL-TST-002_TEST_DATA.md và consumer phụ thuộc |
Principal IT Business Analyst / Technical Curriculum Author quản trị cấu trúc, không tự phê duyệt nội dung | Manifest và tệp cùng ID, đường dẫn, status, version |
| Đổi nghĩa vụ pháp lý, kế toán, thuế, riêng tư, an toàn thực phẩm | Nguồn chính thức và owner chuyên môn có thẩm quyền | Giữ nhãn Verification required hoặc project assumption đến khi có kết luận được ghi nhận |
Legal Owner, Accounting Owner, Compliance Owner hoặc domain owner phù hợp | Không còn diễn đạt suy đoán như nghĩa vụ bắt buộc |
Khi thay đổi ảnh hưởng nhiều artifact, gói lan truyền phải đi theo thứ tự: xác định nguồn canonical; ghi phạm vi ID bị ảnh hưởng; cập nhật artifact nguồn; cập nhật liên kết tiêu thụ; thực hiện review traceability; ghi kết quả và trạng thái còn IN_REVIEW. Template không được tự trở thành nguồn chân lý thay cho /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md hoặc /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Escalation bắt buộc khi một thay đổi đồng thời chạm hai hay nhiều boundary: nghiệp vụ, pháp lý, kế toán, bảo mật, kiến trúc, QA hoặc vận hành. Principal IT Business Analyst / Technical Curriculum Author lập gói vấn đề, bảo toàn ID và liên kết, nhưng không thay Business Owner, Legal Owner, Accounting Owner, Security, Architect hoặc QA quyết định. Không consumer nào được dùng gói bàn giao này để xác nhận Nova Foods tuân thủ pháp luật, cấu hình ERP thực tế hoặc sẵn sàng production.