20 Uat Planning Defects And Regression

Artifact Governance Metadata

Trường kiểm soát	Giá trị
Tên tệp được kiểm soát	/02-handbook/20-uat-planning-defects-and-regression.md
Tiêu đề tài liệu	20 Uat Planning Defects And Regression
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ quản trị	Asia/Ho_Chi_Minh
Locale	vi-VN
Tiền tệ case study	VND
Owner	Principal IT Business Analyst / Technical Curriculum Author
Phân loại nguồn	Handbook giáo dục có kiểm soát; dùng nguồn chính đã xác minh trong /00-research/00_SOURCE_MAP.md theo safe use boundary.
Traceability upstream	/01-curriculum/CHAPTER_MANIFEST.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md; /01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/CANONICAL_DATA_DICTIONARY.md
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục; chỉ dùng dữ liệu tổng hợp.
Baseline	Chưa có baseline reference tại v0.9.0. IN_REVIEW không phải BASELINED.
Approval	Chưa có approval reference. Metadata và nội dung tài liệu không tạo approval ngầm định.
Ranh giới thẩm quyền	Tài liệu không thay quyết định Business Owner, QA, Architect, Legal, Accounting, Security hoặc quyền triển khai production.

1. Concept l? g??

Core

UAT planning, defects and regression là ba phần nối tiếp để kiểm tra ERP trước khi đưa thay đổi vào sử dụng. UAT là User Acceptance Testing, kiểm thử chấp nhận bởi người dùng nghiệp vụ. Mục tiêu không phải chứng minh phần mềm có mã nguồn tốt; mục tiêu là xác định hệ thống hỗ trợ đúng công việc, dữ liệu và kết quả nghiệp vụ đã được xác định làm test basis.

UAT planning là lập kế hoạch UAT. Kế hoạch trả lời trước khi kiểm thử: phạm vi nào được kiểm tra, dữ liệu tổng hợp nào được dùng, môi trường nào được phép dùng, ai chịu trách nhiệm thực hiện, tiêu chí nào quyết định kết quả và bằng chứng nào phải lưu. Lý do cần kế hoạch: cùng một màn hình có thể chạy được nhưng vẫn sai nghiệp vụ, ví dụ tính sai tổng tiền hoặc không chặn thao tác không hợp lệ. Không có kế hoạch, nhóm test dễ kiểm tra ngẫu nhiên; kết quả không chứng minh phạm vi đã được bao phủ.

Defect là lỗi được ghi nhận khi kết quả thực tế khác với kết quả mong đợi đã có căn cứ. Căn cứ có thể là requirement, business rule, acceptance criteria, thiết kế đã kiểm soát hoặc test case. Một nhận xét như “giao diện khó dùng” chưa tự động là defect. Nó cần mô tả hành vi quan sát được, điều kiện tái hiện và outcome mong đợi để người phụ trách đánh giá. Phân biệt này giữ báo cáo lỗi có thể xử lý, tránh biến ý kiến chưa chuẩn hóa thành kết luận kỹ thuật.

Regression testing là kiểm thử lại chức năng đã từng đúng sau khi có thay đổi, thường sau khi sửa defect, cấu hình ERP thay đổi hoặc tích hợp thay đổi. Sửa một điểm có thể ảnh hưởng điểm khác vì chúng dùng chung dữ liệu, quy tắc hoặc luồng xử lý. Vì vậy, trạng thái defect là “đã sửa” chưa đủ để kết luận thay đổi an toàn; cần kiểm tra lại defect và vùng bị ảnh hưởng đã xác định.

Source mermaid — có thể chỉnh sửa

flowchart TB
    P[UAT planning<br/>phạm vi, dữ liệu tổng hợp, môi trường,<br/>người thực hiện, tiêu chí, bằng chứng]
    B[Căn cứ kết quả mong đợi<br/>requirement, business rule, acceptance criteria,<br/>thiết kế hoặc test case đã kiểm soát]
    P --> E[Thực hiện UAT<br/>so sánh kết quả thực tế với mong đợi]
    B --> E

    E -->|Phù hợp| C[UAT đạt theo tiêu chí<br/>lưu bằng chứng kết quả]
    E -->|Khác mong đợi| D[Defect<br/>ghi nhận và phân loại]

    D --> V[Đánh giá defect<br/>xác định disposition]
    V -->|Sửa hoặc cấu hình lại| F[Sửa đổi hoặc cấu hình lại]
    V -->|Không phải defect| N[Không phải defect<br/>lưu căn cứ và bằng chứng]
    V -->|Hoãn xử lý| H[Hoãn xử lý<br/>lưu căn cứ và bằng chứng]
    V -->|Chấp nhận không sửa| A[Chấp nhận không sửa<br/>lưu căn cứ và bằng chứng]

    F --> T[Kiểm tra lại defect đã sửa]
    T -->|Đã sửa đúng| R[Regression testing<br/>kiểm tra vùng ảnh hưởng]
    T -->|Chưa sửa đúng| D
    R -->|Đạt| C
    R -->|Không đạt| D

    C -.-> X[Không bao gồm quyết định release<br/>hoặc phê duyệt nghiệp vụ]

Khái niệm chương này có ranh giới rõ: tập trung lập kế hoạch kiểm thử chấp nhận, ghi nhận lỗi và kiểm thử hồi quy trong bối cảnh ERP. Không thay thiết kế test automation, không thay kiểm thử hiệu năng, kiểm thử bảo mật chuyên sâu, quyết định release, phê duyệt nghiệp vụ hoặc xác nhận tuân thủ pháp lý. Các nội dung đó cần artifact, tiêu chí và thẩm quyền riêng.

Thuật ngữ cốt lõi: ai làm gì với gì để đạt kết quả nào?

Trong UAT, User Acceptance Testing là kiểm thử chấp nhận người dùng: kiểm tra ERP có hỗ trợ nhu cầu nghiệp vụ đã mô tả hay không. Người học không bắt đầu từ màn hình hay nút bấm. Bắt đầu từ một tình huống có thể kiểm tra: một vai trò thực hiện hành động lên đối tượng nghiệp vụ và nhận kết quả mong đợi. Bốn thành phần này tạo câu mô tả kiểm thử tối thiểu, giúp BA, người dùng nghiệp vụ và QA hiểu cùng một việc.

Thuật ngữ	Nghĩa Việt ngắn	Câu hỏi phải trả lời	Ví dụ Nova Foods mô phỏng, dữ liệu tổng hợp
UAT (User Acceptance Testing)	Kiểm thử chấp nhận người dùng	Nghiệp vụ có chấp nhận kết quả hệ thống không?	Nhân viên Kho kiểm tra ERP có cho xác nhận nhập kho lô hàng đúng thông tin hay không.
Actor	Tác nhân; người hoặc hệ thống thực hiện hành động	Ai khởi tạo hoặc chịu trách nhiệm thao tác?	Warehouse Clerk là nhân viên Kho. Không ghi tên người thật.
Action	Hành động nghiệp vụ hoặc thao tác hệ thống	Actor làm gì?	Xác nhận phiếu nhập kho.
Object	Đối tượng bị tác động	Hành động áp dụng lên dữ liệu, chứng từ, hàng hóa hay bản ghi nào?	Phiếu nhập kho mô phỏng GRN-SIM-00021.
Outcome	Kết quả đầu ra có thể quan sát, kiểm tra	Sau hành động, trạng thái, dữ liệu hoặc thông báo nào phải có?	ERP lưu trạng thái Received và hiển thị số lô LOT-SIM-260807-01.
Test scenario	Kịch bản kiểm thử; bối cảnh nghiệp vụ cần xác minh	Cần kiểm tra luồng nào và vì sao?	Nhập kho nguyên liệu có đủ số lô.
Test case	Ca kiểm thử; hướng dẫn kiểm tra cụ thể	Dữ liệu nào, bước nào, kết quả nào?	Mở GRN-SIM-00021, nhập số lô, xác nhận, kiểm tra trạng thái.
Expected result	Kết quả mong đợi	Điều kiện nào chứng minh ca kiểm thử đạt?	Hệ thống không cho hoàn tất nếu thiếu số lô; khi đủ, lưu đúng số lô.
Actual result	Kết quả thực tế	Hệ thống đã làm gì khi chạy kiểm thử?	Người kiểm thử ghi nhận trạng thái và thông báo thực tế.
Defect	Lỗi; khác biệt giữa kết quả thực tế và kết quả mong đợi	Sai ở đâu so với căn cứ kiểm thử?	ERP cho hoàn tất phiếu khi trường số lô để trống, dù kết quả mong đợi yêu cầu chặn.
Regression testing	Kiểm thử hồi quy; kiểm tra chức năng cũ sau thay đổi	Thay đổi có làm hỏng hành vi từng hoạt động đúng không?	Sau khi sửa kiểm tra số lô, chạy lại ca nhập kho có số lô hợp lệ.
Test basis	Căn cứ kiểm thử	Dùng nguồn nào để xác định đúng/sai?	Requirement, business rule, acceptance criteria đã được ghi nhận. Không dùng suy đoán cá nhân.

Cấu trúc câu chuẩn: Actor thực hiện Action trên Object để tạo hoặc kiểm tra Outcome. Ví dụ: “Warehouse Clerk xác nhận phiếu GRN-SIM-00021 có số lô LOT-SIM-260807-01 để ERP lưu trạng thái Received.” Câu này chưa là test case đầy đủ, nhưng đã khóa bốn ý chính. Thiếu actor thì không rõ quyền và trách nhiệm; thiếu object thì không rõ dữ liệu nào bị tác động; thiếu outcome thì không có tiêu chí pass/fail.

Pass là đạt: actual result khớp expected result theo test basis. Fail là không đạt: có chênh lệch cần ghi nhận. Fail không tự động chứng minh phần mềm sai; BA cần đối chiếu test basis. Bằng chứng là expected result chỉ hợp lệ khi truy được requirement, rule hoặc acceptance criteria. Nếu căn cứ thiếu, kết quả đúng là “cần làm rõ test basis”, không tự tạo quy tắc Nova Foods.

Phạm vi thuật ngữ này là lập kế hoạch UAT, ghi nhận defect và chọn regression test trong Nova Foods Trading & Manufacturing mô phỏng. Không xác nhận cấu hình ERP thực tế, không tạo requirement vận hành, không diễn giải nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm hay bảo vệ dữ liệu cá nhân. Mọi ID và dữ liệu ví dụ là tổng hợp; artifact corpus hiện IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp. Ví dụ tối thiểu: người kiểm thử UAT phát hiện đơn bán SO-SIM-00017 không chuyển sang trạng thái Confirmed sau khi chọn lệnh Xác nhận. Họ ghi nhận hiện tượng, dữ liệu đầu vào, bước tái hiện và kết quả mong đợi vào defect. BA làm rõ lỗi này có ảnh hưởng quy tắc nghiệp vụ hay chỉ là cách hiển thị; QA dùng bản ghi đó để kiểm tra bản sửa; đội phát triển sửa phần mềm; người dùng nghiệp vụ xác nhận kết quả UAT theo thẩm quyền được phân công. Đây là chuỗi UAT, quản lý defect và regression: phát hiện trong điều kiện gần nghiệp vụ, ghi nhận có thể tái hiện, sửa có kiểm soát, rồi kiểm tra lại phần đã sửa và phần có nguy cơ bị ảnh hưởng.

Thành phần	Nội dung ví dụ mô phỏng
Facts	Ngày kiểm thử 2026-08-07, múi giờ Asia/Ho_Chi_Minh; đơn SO-SIM-00017; giá trị tổng hợp 1250000 VND; người kiểm thử chọn Xác nhận
Current Behavior	ERP vẫn hiển thị trạng thái Draft; không có thông báo lỗi hiển thị cho người dùng
Underlying Need	Đơn hợp lệ cần phản ánh trạng thái xử lý đúng để bộ phận tiếp theo biết có thể tiếp tục thao tác
Options	Ghi nhận là defect; ghi nhận là yêu cầu thay đổi; ghi nhận là lỗi dữ liệu kiểm thử
Decision Criteria	So sánh hành vi với test basis đã được cung cấp cho UAT; kiểm tra khả năng tái hiện; kiểm tra dữ liệu đầu vào có hợp lệ
Decision	Phân loại tạm thời là defect khi cùng dữ liệu và bước thao tác tái hiện được sai khác với kết quả mong đợi trong test basis
Authority	BA bảo toàn mô tả và truy vết; QA quản lý kiểm thử; đội phát triển đánh giá kỹ thuật; Business Owner quyết định nghiệp vụ khi cần. Không có approval ngầm định
Artifact	Bản ghi defect liên kết test case UAT, bằng chứng tổng hợp và phạm vi regression
Consequence if Wrong	Gọi nhầm defect là change có thể trì hoãn sửa lỗi; bỏ qua regression có thể làm lỗi mới xuất hiện ở luồng bán hàng liên quan

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Người kiểm thử UAT thao tác đơn SO-SIM-00017] --> B[So sánh kết quả thực tế với test basis]
    B --> C{Có sai khác?}

    C -- Không --> D[Người kiểm thử UAT ghi kết quả UAT]
    D --> Q[Kết quả UAT được ghi nhận theo thẩm quyền]

    C -- Có --> E[QA kiểm tra khả năng tái hiện và dữ liệu đầu vào hợp lệ]
    E --> F{Sai khác tái hiện được và trái test basis?}

    F -- Không, dữ liệu không hợp lệ --> G[Ghi nhận lỗi dữ liệu kiểm thử và sửa dữ liệu]
    G --> A

    F -- Không, cần thay đổi --> H[Ghi nhận yêu cầu thay đổi]
    H --> X[Chuyển sang quy trình xử lý theo thẩm quyền]

    F -- Không, chưa đủ bằng chứng --> I[Bổ sung bước tái hiện và bằng chứng]
    I --> E

    F -- Có --> J[Ghi defect có bước tái hiện và bằng chứng]
    J --> K[BA bảo toàn mô tả và truy vết defect]
    K --> L[BA làm rõ sai khác ảnh hưởng quy tắc nghiệp vụ hay chỉ hiển thị]
    L --> M{Cần quyết định nghiệp vụ?}
    M -- Có --> N[Business Owner quyết định nghiệp vụ]
    M -- Không --> O[QA quản lý defect, test case UAT và bằng chứng]
    N --> O
    O --> P[Đội phát triển phân tích và sửa]

    P --> R[QA kiểm tra bản sửa]
    R --> S{Bản sửa đạt?}
    S -- Không --> P
    S -- Có --> T[QA regression các luồng bị ảnh hưởng]

    T --> U{Regression phát hiện lỗi?}
    U -- Có --> V[Ghi sai khác regression có bước tái hiện và bằng chứng]
    V --> E
    U -- Không --> W[Người dùng nghiệp vụ xác nhận kết quả UAT theo thẩm quyền]
    W --> Q

Ranh giới khái niệm: chapter này giải thích cách lập kế hoạch UAT, ghi nhận và theo dõi defect, chọn phạm vi regression. Actor là vai trò thực hiện, như người kiểm thử UAT hoặc BA. Action là hành động, như xác nhận đơn hoặc chạy lại test. Object là đối tượng bị tác động, như đơn bán, defect hoặc test case. Outcome là kết quả quan sát được, như trạng thái Confirmed, defect đã retest, hoặc regression không phát hiện lỗi.

Loại trừ: ví dụ không xác nhận cấu hình ERP thật, không tạo quy tắc Nova Foods có hiệu lực vận hành, không kết luận nguyên nhân kỹ thuật, không quyết định mức ưu tiên phát hành, không xác nhận tuân thủ pháp lý, kế toán, thuế, an toàn thực phẩm hay bảo vệ dữ liệu cá nhân. Các nội dung đó cần artifact phù hợp và thẩm quyền Business Owner, QA, Architect, Security, Legal hoặc Accounting.

2. T?i sao concept n?y t?n t?i?

Core

UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng), quản lý defect (lỗi được ghi nhận có cấu trúc) và regression testing (kiểm thử hồi quy: chạy lại luồng bị ảnh hưởng sau thay đổi) tồn tại để chặn ba dạng thất bại. Thứ nhất, lỗi nghiệp vụ đi qua vì người kiểm thử chỉ nói “hệ thống sai” mà không có bước tái hiện, dữ liệu, kết quả mong đợi và bằng chứng. Thứ hai, đội phát triển sửa một điểm nhưng làm hỏng luồng liên quan vì phạm vi regression không được xác định. Thứ ba, governance bị mơ hồ vì không rõ ai xác nhận lỗi, ai phân loại tác động, ai quyết định chấp nhận rủi ro còn lại.

Không có kế hoạch UAT, mỗi người kiểm thử chọn luồng theo trí nhớ. Không có defect chuẩn, BA không phân biệt được lỗi cấu hình, lỗi dữ liệu mô phỏng, lỗi yêu cầu, hay đề xuất thay đổi. Không có regression, kết quả retest chỉ chứng minh lỗi ban đầu đã hết; nó không chứng minh các chức năng phụ thuộc vẫn hoạt động. Đây là khoảng trống kiểm soát, không phải bằng chứng hệ thống Nova Foods mô phỏng có lỗi thật.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[UAT test case có kết quả mong đợi] --> B[Người kiểm thử thực hiện]
    B --> C{Kết quả thực tế khớp?}
    C -- Có --> I[Passed: trạng thái kiểm thử và bằng chứng có truy vết]
    C -- Không --> D[Defect: bước tái hiện, dữ liệu, kết quả mong đợi, bằng chứng]

    D --> E{Xác nhận và phân loại theo governance dự án}
    E -- Không tái hiện được --> V[Đóng hoặc từ chối: lý do và bằng chứng có truy vết]
    E -- Không phải defect --> V
    E -- Lỗi cấu hình --> K[Phân tích tác động]
    E -- Dữ liệu mô phỏng --> K
    E -- Lỗi yêu cầu --> K
    E -- Đề xuất thay đổi --> J[Quy trình change control]
    J --> W[Trạng thái đề xuất thay đổi có truy vết]

    K --> M{Người có thẩm quyền theo governance dự án quyết định xử lý}
    M -- Khắc phục --> N[Đội phát triển, cấu hình hoặc dữ liệu khắc phục theo phân loại]
    N --> O[Người kiểm thử retest defect]
    O --> P{Người phê duyệt UAT theo governance dự án xác nhận retest đạt?}
    P -- Không --> D
    P -- Có --> Q[Người kiểm thử regression luồng bị ảnh hưởng]
    Q --> R{Người phê duyệt UAT theo governance dự án xác nhận regression đạt?}
    R -- Không --> D
    R -- Có --> S[Đóng defect: retest, regression và bằng chứng có truy vết]

    M -- Chấp nhận rủi ro còn lại --> T[Người có thẩm quyền theo governance dự án chấp nhận rủi ro]
    T --> U[Trạng thái riêng: rủi ro còn lại được chấp nhận; người phê duyệt, lý do và bằng chứng có truy vết]

Applied

Thành phần	Nội dung kiểm soát cho Nova Foods mô phỏng
Facts	UAT cần so sánh kết quả thực tế với kết quả mong đợi của test case. Defect cần bằng chứng để người khác tái hiện. Regression cần xét chức năng bị ảnh hưởng sau sửa đổi.
Current Behavior	Nếu chỉ trao đổi lỗi qua chat hoặc lời nói, đội phát triển có thể thiếu dữ liệu tái hiện; QA không có bản ghi để retest; BA không nối được lỗi với yêu cầu và test case.
Underlying Need	Một nguồn ghi nhận chung cho sai khác quan sát được, xử lý sai khác và phạm vi kiểm thử lại.
Options	(1) Ghi nhận tự do qua chat. (2) Dùng defect record có ID, test case liên kết, bước tái hiện, expected result, actual result, evidence, trạng thái và tác động regression.
Decision Criteria	Khả năng tái hiện; truy vết tới test basis; phân vai rõ; bằng chứng retest; nhận diện luồng cần regression.
Decision	Dùng defect record có cấu trúc và liên kết UAT test case; lập phạm vi regression theo tác động được phân tích.
Authority	QA quản lý quy trình kiểm thử; BA duy trì truy vết yêu cầu và test basis; đội phát triển phân tích sửa; Business Owner quyết định nghiệp vụ hoặc chấp nhận rủi ro khi cần. Không có approval ngầm định.
Artifact	Defect record, UAT execution record, evidence reference, regression scope record.
Consequence if Wrong	Lỗi không tái hiện được; sửa nhầm; retest thiếu căn cứ; lỗi mới lọt qua luồng liên quan; không xác định được trách nhiệm và trạng thái quyết định.

Senior Lens

Senior BA không dùng UAT để “tìm mọi lỗi”. UAT xác nhận hệ thống hỗ trợ kết quả nghiệp vụ đã được mô tả trong test basis. Vì vậy defect tốt phải mô tả sai khác quan sát được, không tự kết luận nguyên nhân kỹ thuật. Ví dụ, “trạng thái đơn không chuyển theo expected result của test case” là quan sát có thể kiểm tra. “ERP lỗi do API” là giả thuyết kỹ thuật, cần đội phát triển hoặc Architect xác minh.

Regression là quyết định theo tác động, không phải chạy lại ngẫu nhiên toàn bộ test. Khi thay đổi chạm dữ liệu đơn bán, BA và QA cần xác định luồng nào đọc, ghi, tính toán hoặc hiển thị cùng dữ liệu đó. Nếu chưa đủ bằng chứng để xác định phạm vi, trạng thái đúng là cần phân tích thêm; không được tuyên bố regression hoàn tất.

Quick Reference

Rủi ro cần chặn	Kiểm soát tối thiểu
Mơ hồ về lỗi	Defect có test case liên kết, bước tái hiện, expected result, actual result, bằng chứng
Rework do sửa nhầm	Không kết luận nguyên nhân kỹ thuật trong defect; phân tích bởi vai trò có thẩm quyền
Lỗi mới sau sửa	Xác định và thực hiện regression theo tác động
Mất truy vết	Liên kết UAT execution record, defect record, retest và regression scope
Governance mơ hồ	Ghi rõ vai trò QA, BA, đội phát triển và Business Owner; không suy diễn approval

Core

UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) và quản lý lỗi tồn tại để biến phản hồi “hệ thống không đúng” thành bằng chứng có thể kiểm tra, phân loại và quyết định. Không có chuỗi test case, lỗi, sửa lỗi và regression test (kiểm thử hồi quy), cùng một lỗi có thể quay lại sau lần sửa khác mà nhóm không nhận ra.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp.

Trường	Trước khi có kế hoạch UAT, lỗi và hồi quy	Sau khi có kế hoạch UAT, lỗi và hồi quy
Facts	Người dùng mô phỏng tạo đơn bán SO-NF-260807-001; đơn có dòng hàng và số lượng.	Cùng đơn, cùng dữ liệu đầu vào, được chạy theo test case đã định danh.
Current Behavior	Người dùng báo qua chat: “không thấy số lượng đúng”. Không có bước tái hiện, dữ liệu đầu vào, kết quả mong đợi hay bằng chứng đính kèm.	Tester ghi test case, kết quả thực tế, kết quả mong đợi, ảnh chụp màn hình và trạng thái lỗi trong artifact kiểm soát.
Underlying Need	Nhóm cần biết lỗi nằm ở nhập đơn, lưu đơn, hiển thị đơn hay dữ liệu mẫu. Chat không tách được các khả năng này.	Nhóm cần tái hiện cùng điều kiện để Dev sửa đúng điểm và QA kiểm tra lại đúng phạm vi.
Options	Sửa theo mô tả chat; hoặc yêu cầu người báo lỗi tái hiện có kiểm soát.	Chỉ retest lỗi; hoặc retest lỗi kèm regression test cho chức năng bị ảnh hưởng.
Decision Criteria	Mô tả phải đủ để người khác tái hiện; sửa không được phá hành vi đã đạt.	Bằng chứng phải liên kết được test case, defect ID, bản build mô phỏng và kết quả retest.
Decision	Không chuyển phản hồi chat thành yêu cầu sửa trực tiếp. Ghi lỗi chỉ khi có bước tái hiện và kết quả quan sát được.	Sau khi sửa hiển thị số lượng, chạy lại test case lỗi và regression test tạo, sửa, xem lại đơn bán.
Authority	BA điều phối bằng chứng; QA xác nhận kết quả kiểm thử; Business Owner quyết định chấp nhận nghiệp vụ. Không có phê duyệt nào được suy ra.	Cùng ranh giới thẩm quyền. IN_REVIEW và v0.9.0 không phải baseline hay approval.
Artifact	Phản hồi chat không phải test evidence.	Kế hoạch trong /02-handbook/20-uat-planning-defects-and-regression.md; defect log và test evidence phải dùng ID canonical khi registry cấp ID.
Consequence if Wrong	Dev có thể sửa màn hình hiển thị trong khi lỗi nằm ở quy tắc tính số lượng. Lỗi gốc còn tồn tại hoặc phát sinh lỗi mới.	Nếu regression bị bỏ qua, sửa lỗi hiển thị có thể làm hỏng sửa đơn hoặc xem lại đơn; lỗi chỉ lộ sau khi người dùng chạy luồng khác.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Test case: tạo đơn SO-NF-260807-001] --> B{QA xác nhận kết quả đúng?}

    B -->|Có| G[QA chạy regression<br/>Tạo, sửa, xem lại đơn bán]
    B -->|Không| C[BA điều phối ghi defect<br/>Bước tái hiện, expected, actual, evidence<br/>Dùng ID canonical khi registry cấp ID]

    C --> D{QA xác nhận đủ bằng chứng<br/>và tái hiện được?}
    D -->|Chưa đủ| Q[BA bổ sung bằng chứng<br/>cho defect hiện tại]
    Q --> D
    D -->|Đủ| R[Dev sửa bản build mô phỏng]

    R --> E[QA retest defect]
    E --> F{QA xác nhận retest đạt?}
    F -->|Không| K[QA xác nhận lỗi cũ tái diễn<br/>Mở lại defect cũ]
    K --> R
    F -->|Có| G

    G --> H{QA xác nhận mọi kết quả đúng?}
    H -->|Có| T{Có defect đang xử lý?}
    T -->|Không| U[QA xác nhận test case và regression đạt<br/>Evidence gắn với bản build mô phỏng]
    T -->|Có| I[QA xác nhận retest đạt và liên kết<br/>test case, defect ID, build, evidence]
    I --> J[Đóng defect theo thẩm quyền<br/>và quy trình đã định]

    H -->|Không| L{Kết quả quan sát là gì?}
    L -->|Lỗi cũ tái diễn| K
    L -->|Lỗi mới| M[BA điều phối ghi defect mới<br/>Bước tái hiện, expected, actual, evidence<br/>Dùng ID canonical khi registry cấp ID]
    M --> D

    U -. trình kết quả UAT .-> O{Business Owner<br/>chấp nhận nghiệp vụ?}
    J -. trình kết quả UAT .-> O
    O -->|Có| P[Trạng thái UAT:<br/>nghiệp vụ được chấp nhận]
    O -->|Không| X[Trạng thái UAT:<br/>nghiệp vụ không được chấp nhận]

    P --> Z[Không suy ra baseline<br/>hoặc phê duyệt phát hành]
    X --> Z

Senior Lens

Khác biệt quan sát được không phải số lỗi ít hay nhiều. Trước đó, nhóm không xác định được cùng một lỗi có tái hiện được không, đã sửa đúng không, hay thay đổi mới có làm hỏng luồng cũ không. Sau đó, mỗi kết quả đi qua chuỗi bằng chứng: điều kiện kiểm thử, hành động, kết quả, lỗi, sửa, retest và regression. Chuỗi này giảm tranh cãi vì người review kiểm tra được vật chứng thay vì diễn giải lại cuộc trao đổi.

Quick Reference

Quy tắc	Áp dụng
Một lỗi phải tái hiện được	Ghi dữ liệu, bước chạy, expected result và actual result.
Retest không thay regression	Retest xác nhận lỗi đã sửa; regression tìm tác động ngoài lỗi đó.
Không suy ra phê duyệt	Kết quả UAT chỉ là bằng chứng kiểm thử cho đến khi vai trò có thẩm quyền ghi quyết định trong artifact kiểm soát.

Core

Trong Nova Foods Trading & Manufacturing — mô phỏng giáo dục, dữ liệu tổng hợp — mỗi phát biểu phải mang nhãn bằng chứng trước khi dùng để lập kế hoạch UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng), quản lý lỗi, hoặc chọn phạm vi regression test (kiểm thử hồi quy). Nhãn ngăn BA biến ý kiến thành quy tắc, biến giả định thành kết luận, hoặc biến quyết định chưa có thẩm quyền thành cấu hình ERP.

Nhãn	Định nghĩa	Bằng chứng tối thiểu	Được phép kết luận	Không được suy diễn
Fact đã xác minh	Thông tin kiểm tra được từ artifact hoặc nguồn canonical xác định	ID artifact, đường dẫn, version, trạng thái, đoạn dữ liệu hoặc URL nguồn	“Artifact ghi nhận X”	“X đã được phê duyệt” nếu artifact không ghi approval
Stakeholder input	Nhu cầu, quan sát, hoặc đề xuất do bên liên quan nêu	Vai trò, ngày ghi nhận, nội dung được diễn đạt lại chính xác, nguồn họp hoặc ticket	“Vai trò Y yêu cầu/cho biết X”	“X là business rule”
Project assumption	Điều tạm giả định để lập kế hoạch khi thiếu bằng chứng	Lý do thiếu dữ liệu, phạm vi ảnh hưởng, owner xác minh, hạn xác minh	“Kế hoạch hiện dùng X như giả định”	“Hệ thống phải làm X”
Decision	Lựa chọn giữa các phương án bởi vai trò có thẩm quyền	Phương án, tiêu chí, người quyết định, thời điểm, artifact ghi nhận	“Đã chọn X trong phạm vi artifact”	“Đã approval/baseline” khi chưa có tham chiếu đó
Verification-required claim	Phát biểu cần kiểm tra trước khi thành fact hoặc requirement	Nguồn cần kiểm, owner phù hợp, điều kiện đóng	“Cần Legal/Accounting/Business Owner xác minh X”	Khẳng định nghĩa vụ pháp lý, kế toán, hoặc vận hành

IN_REVIEW và v0.9.0 là fact đã xác minh cho artifact quản trị corpus ngày 2026-08-07. Chúng không là fact rằng requirement Nova Foods đã đúng, đã baseline, đã được người dùng chấp thuận, hay được phép dùng production. Cầu nối suy luận: metadata chỉ xác nhận trạng thái artifact; approval và baseline cần tham chiếu ghi nhận riêng.

Applied

Trường	Nội dung ghi nhận sẵn sàng cho artifact
Facts	/01-curriculum/CHAPTER_MANIFEST.md có trạng thái IN_REVIEW, version v0.9.0, ngày 2026-08-07; case Nova Foods là mô phỏng giáo dục, dùng dữ liệu tổng hợp. Luật Kế toán là nguồn chính thức, nhưng diễn giải kế toán cần vai trò kế toán có thẩm quyền.
Current Behavior	Nhóm UAT ghi lỗi: “ERP phải chặn xuất kho nếu chưa có hóa đơn.” Câu này chưa nêu nguồn, người yêu cầu, loại đơn hàng, hay thẩm quyền quyết định.
Underlying Need	Phân biệt lỗi phần mềm với thiếu quy tắc nghiệp vụ. Nếu không phân biệt, QA có thể mở defect cho hành vi chưa từng được quyết định.
Options	1. Ghi defect ngay với mức Critical. 2. Ghi clarification yêu cầu làm rõ. 3. Tạm cấu hình chặn xuất kho.
Decision Criteria	Có business rule canonical chưa; có quyết định Business Owner/Accounting Owner chưa; có bằng chứng pháp lý đã được chuyên gia xác minh chưa; hành vi hiện tại có mâu thuẫn requirement đã truy vết chưa.
Decision	Chọn phương án 2: tạo mục Verification required, không tạo defect xác nhận, không đổi cấu hình. Lý do: phát biểu hiện là stakeholder input hoặc giả định, chưa có test basis đã xác minh.
Authority	Business Owner xác nhận chính sách xuất kho; Accounting Owner xác nhận ảnh hưởng kế toán; Legal Owner xác minh diễn giải pháp lý nếu được viện dẫn; QA chỉ xác nhận kết quả test so với test basis đã kiểm soát.
Artifact	Ghi trong UAT issue log với nhãn Verification required; liên kết CANONICAL_BUSINESS_RULES và nguồn pháp lý nếu có. Không tự tạo rule ID, approval reference, hoặc baseline reference.
Consequence if Wrong	Nếu gọi là defect, đội kỹ thuật có thể sửa sai và regression test sai phạm vi. Nếu gọi là requirement đã phê duyệt, tài liệu tạo bằng chứng quản trị giả. Nếu bỏ qua, UAT không biết ai phải quyết định và lỗi lặp lại ở vòng sau.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Phát biểu và hành vi ghi nhận trong UAT] --> QA[QA chỉ đối chiếu kết quả quan sát<br/>với test basis đã kiểm soát]
    QA --> B{Requirement hoặc test basis<br/>đã kiểm soát và truy vết?}

    B -- Có --> C[QA đối chiếu hành vi với test basis]
    B -- Không --> V[Verification required]

    C --> D{Hành vi mâu thuẫn<br/>với test basis?}
    D -- Có --> E[Tạo defect đã xác nhận<br/>và truy vết test basis]
    D -- Không --> N[Không xác nhận defect<br/>Không đổi cấu hình]

    V --> U[Ghi UAT issue log<br/>Nhãn Verification required]
    U --> M[Chỉ định owner và điều kiện đóng]
    M --> BO{Business Owner đã kết luận<br/>về chính sách xuất kho?}

    BO -- Chưa --> W[Giữ Verification required<br/>Không xác nhận defect, không đổi cấu hình]
    BO -- Không hỗ trợ phát biểu --> N
    BO -- Hỗ trợ phát biểu --> Q{Có ảnh hưởng kế toán?}

    Q -- Có --> AO{Accounting Owner đã xác nhận<br/>ảnh hưởng kế toán?}
    Q -- Không --> L{Có viện dẫn pháp lý?}
    AO -- Chưa --> W
    AO -- Không hỗ trợ phát biểu --> N
    AO -- Hỗ trợ phát biểu --> L

    L -- Có --> LO{Legal Owner đã xác minh<br/>diễn giải pháp lý?}
    L -- Không --> G[Liên kết rule canonical nếu tồn tại<br/>và nguồn pháp lý nếu áp dụng]
    LO -- Chưa --> W
    LO -- Không hỗ trợ phát biểu --> N
    LO -- Hỗ trợ phát biểu --> G

    G --> Z[Không tự tạo rule ID, approval reference<br/>hoặc baseline reference]
    Z --> T{Requirement hoặc test basis đã được<br/>kiểm soát chính thức và truy vết?}
    T -- Có --> C
    T -- Chưa --> W
    T -- Không hình thành rule --> N

    QA -. Không quyết định chính sách .-> R[Business Owner quyết định nghiệp vụ<br/>Accounting Owner xác nhận ảnh hưởng kế toán<br/>Legal Owner xác minh diễn giải pháp lý]

    V -. Nếu không giữ trạng thái Verification required .-> K{Hệ quả nào?}
    K -- Gọi là defect --> X[Sửa sai và regression sai phạm vi]
    K -- Gọi là requirement đã phê duyệt --> Y[Tạo bằng chứng quản trị giả]
    K -- Bỏ qua claim --> I[Không rõ owner quyết định<br/>Issue dễ lặp lại ở vòng UAT sau]

Senior Lens

Một câu có thể chứa nhiều nhãn. Ví dụ: “Kho vận nói cần chặn xuất kho khi chưa có hóa đơn” là stakeholder input; “Luật bắt buộc chặn” là verification-required claim cho đến khi Legal Owner xác minh; “Vòng UAT này giả định chưa chặn để test luồng hiện hữu” là project assumption; chỉ khi Business Owner và Accounting Owner chọn phương án, ghi nhận thẩm quyền và artifact, câu mới có phần decision.

BA không nâng cấp nhãn bằng ngôn từ. Các cụm “đương nhiên”, “theo luật”, “người dùng bảo”, “đã thống nhất”, hoặc “hệ thống hiện làm vậy” không đủ bằng chứng. Mỗi lần đổi nhãn phải thêm cầu nối: nguồn nào chứng minh, ai có thẩm quyền, artifact nào lưu quyết định, và UAT kiểm tra điều gì.

Quick Reference

Câu hỏi kiểm tra	Nếu “không”	Nhãn an toàn
Có artifact hoặc nguồn chính thức kiểm tra được?	Không gọi là fact	Stakeholder input, assumption, hoặc verification-required claim
Có người quyết định đúng thẩm quyền và ghi nhận lựa chọn?	Không gọi là decision	Verification required
Có approval hoặc baseline reference được ghi rõ?	Không nói “đã phê duyệt” hoặc “đã baseline”	IN_REVIEW
Claim liên quan pháp lý, kế toán, thuế, riêng tư, an toàn thực phẩm?	Chưa có owner chuyên môn xác minh	Verification required

3. V? tr? trong Lifecycle

Core

UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) không bắt đầu khi đội kiểm thử mở hệ thống. UAT được chuẩn bị từ Discovery, vì mục tiêu kiểm thử phải bắt nguồn từ nhu cầu nghiệp vụ đã làm rõ. Với Nova Foods Trading & Manufacturing là case mô phỏng, dữ liệu tổng hợp, chuỗi lifecycle tạo “test basis” — cơ sở để thiết kế và đánh giá kiểm thử — qua từng cổng vào và cổng ra.

Giai đoạn	Mục đích với UAT, defect và regression	Cổng vào chính xác	Cổng ra chính xác
Discovery	Nhận diện vấn đề, mục tiêu và nhóm bị ảnh hưởng; chưa gọi ý kiến là requirement đã chốt	Có stakeholder input và phạm vi vấn đề mô phỏng	Có problem statement, mục tiêu đo được hoặc câu hỏi cần xác minh
Analysis	Chuyển nhu cầu thành requirement, business rule, dữ liệu, ngoại lệ và acceptance criteria	Problem statement đủ ngữ cảnh; claim pháp lý, kế toán, riêng tư, an toàn thực phẩm chưa xác minh phải mang nhãn Verification required	Acceptance criteria liên kết requirement; assumption và điểm cần xác minh được ghi rõ
Delivery	Cấu hình hoặc phát triển giải pháp theo requirement đã đủ để xây dựng	Có requirement và acceptance criteria làm test basis; thay đổi ngoài phạm vi phải quay lại Analysis	Build sẵn sàng kiểm thử nội bộ; thay đổi đã ghi nhận để đánh giá regression
Testing	Xác minh kỹ thuật và chức năng trước UAT; phân loại defect và kiểm tra sửa lỗi	Có môi trường, dữ liệu tổng hợp, test basis và build được xác định	Defect blocking UAT đã được xử lý hoặc có quyết định ghi nhận đúng thẩm quyền; phạm vi UAT xác định được
Release	Đưa thay đổi đã qua tiêu chí phát hành vào phạm vi sử dụng đã chọn	Có kết quả UAT, danh sách defect còn lại và đánh giá rủi ro theo artifact kiểm soát	Phiên bản phát hành, phạm vi và điều kiện theo dõi sau phát hành được ghi nhận
Operations	Theo dõi hành vi thực tế, sự cố và yêu cầu thay đổi mới; không tự diễn giải sự cố thành requirement	Có tín hiệu vận hành, incident hoặc phản hồi được ghi nhận	Issue được đóng bằng bằng chứng, hoặc quay về Discovery/Analysis thành nhu cầu thay đổi mới

Cổng không phải buổi họp mang tính nghi thức. Cổng là điều kiện quyết định artifact nào đủ tin cậy để giai đoạn sau sử dụng. Ví dụ, nếu acceptance criteria chưa nêu cách xử lý đơn hàng có số lượng giao thiếu, UAT không có điều kiện quan sát để kết luận đạt hay không đạt. Bằng chứng là test case chỉ có thể so sánh kết quả thực tế với kết quả mong đợi đã được mô tả.

Source mermaid — có thể chỉnh sửa

flowchart TB
    D[Discovery<br/>Nhận diện vấn đề, mục tiêu<br/>và nhóm bị ảnh hưởng]
    D --> P{Discovery exit đủ?<br/>Problem statement đủ ngữ cảnh;<br/>có mục tiêu đo được hoặc câu hỏi cần xác minh}
    P -- Không --> D
    P -- Có --> A[Analysis<br/>Làm rõ requirement, business rule,<br/>dữ liệu, ngoại lệ và acceptance criteria]

    A --> Q{Test basis đầy đủ?<br/>Requirement và acceptance criteria liên kết;<br/>assumption, claim cần xác minh được ghi rõ}
    Q -- Không --> A
    Q -- Có --> B[Delivery<br/>Tạo build hoặc cấu hình;<br/>ghi nhận thay đổi để đánh giá regression]

    B --> E{Testing entry đủ?<br/>Có môi trường, dữ liệu tổng hợp,<br/>test basis và build được xác định}
    E -- Thiếu test basis --> A
    E -- Thiếu build --> B
    E -- Thiếu môi trường hoặc dữ liệu --> TP[Chuẩn bị môi trường<br/>và dữ liệu tổng hợp]
    TP --> E
    E -- Đủ --> T[Testing<br/>Xác minh kỹ thuật, chức năng<br/>và phân loại defect]

    T --> X{Testing exit đủ UAT?<br/>Defect blocking đã được xử lý hoặc có quyết định<br/>đúng thẩm quyền; phạm vi UAT xác định được}
    X -- Có --> U[UAT<br/>Thực thi acceptance criteria]
    X -- Không --> H{Cần xử lý gì?}
    H -- Sửa defect --> F[Delivery<br/>Sửa defect và ghi nhận thay đổi]
    F --> G[Kiểm tra sửa lỗi<br/>và regression]
    G --> T
    H -- Cần quyết định --> K[Quyết định được ghi nhận<br/>đúng thẩm quyền]
    K --> X

    U --> RI{Release entry đủ?<br/>Có kết quả UAT, danh sách defect còn lại<br/>và đánh giá rủi ro theo artifact kiểm soát}
    RI -- Không --> M{Thiếu ở đâu?}
    M -- Requirement hoặc acceptance criteria --> A
    M -- Build hoặc defect --> F
    M -- Kết quả UAT --> U
    M -- Artifact hoặc quyết định --> C[Hoàn tất artifact kiểm soát<br/>và ghi nhận quyết định liên quan]
    C --> RI

    RI -- Có --> R[Release<br/>Phát hành trong phạm vi đã chọn]
    R --> RO{Release exit đủ?<br/>Phiên bản, phạm vi và điều kiện<br/>theo dõi sau phát hành đã ghi nhận}
    RO -- Không --> RC[Hoàn tất hồ sơ phát hành<br/>và điều kiện theo dõi]
    RC --> RO
    RO -- Có --> O[Operations<br/>Theo dõi hành vi thực tế,<br/>sự cố và phản hồi]

    O --> I{Issue được đóng<br/>bằng bằng chứng?}
    I -- Có --> Z[Issue đã đóng]
    I -- Không --> N{Có nhu cầu<br/>thay đổi mới?}
    N -- Không --> O
    N -- Có, cần làm rõ --> D
    N -- Có, problem statement đủ ngữ cảnh --> A

Applied

Facts: Nova Foods mô phỏng có yêu cầu cho luồng bán hàng SO-NF-014: khi đơn giao thiếu, người dùng cần thấy số lượng đặt, số lượng giao và số lượng còn lại. Dữ liệu ví dụ tổng hợp: đơn SO-SIM-260807-01 đặt 100 thùng, giao 92 thùng, còn lại 8 thùng.

Current Behavior: Discovery chỉ ghi nhận phản hồi từ Kho rằng giao thiếu gây khó đối chiếu. Analysis chưa có acceptance criteria quy định hệ thống hiển thị, chặn hay cho phép hoàn tất đơn. Vì thiếu kết quả mong đợi, Testing không thể tạo test case pass/fail hợp lệ.

Underlying Need: UAT cần kiểm tra quyết định nghiệp vụ đã được biểu đạt thành điều kiện quan sát được, không kiểm tra suy đoán của tester. Điều này cần thiết vì cùng một fact “giao 92 trên 100” có thể hợp lệ với giao từng phần hoặc không hợp lệ với chính sách giao đủ.

Options:

Phương án	Nội dung	Tác động lifecycle
1	Chuyển thẳng sang UAT với câu hỏi mở	UAT thành buổi khám phá; không có tiêu chí kết luận
2	Quay về Analysis, bổ sung acceptance criteria và trạng thái đơn	Tạo test basis trước Delivery/Testing
3	Delivery tự chọn hành vi mặc định	Tạo decision không có căn cứ thẩm quyền trong artifact

Decision Criteria: Chọn phương án chỉ khi có kết quả mong đợi kiểm thử được, giữ được liên kết từ SO-NF-014 đến test case, không biến assumption thành business rule, và không tự kết luận nghĩa vụ kế toán hoặc pháp lý.

Decision: Chọn phương án 2. Analysis phải bổ sung acceptance criteria tối thiểu: với đơn đặt 100 thùng, giao 92 thùng, hệ thống hiển thị số lượng còn lại 8 thùng và trạng thái đơn theo rule được ghi nhận. Việc cho phép xuất hóa đơn, hoàn tất đơn hoặc chặn giao tiếp phải giữ nhãn Verification required nếu chưa có xác minh của vai trò chuyên môn phù hợp.

Authority: BA có thể ghi nhận khoảng trống test basis và chặn chuyển UAT theo tiêu chí chất lượng artifact. BA không có thẩm quyền tự chọn chính sách giao thiếu, diễn giải kế toán, hoặc xác nhận quy định pháp lý.

Artifact: Cập nhật requirement và acceptance criteria của SO-NF-014; tạo liên kết tới test case UAT sau khi acceptance criteria đủ. Trạng thái corpus vẫn IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh.

Consequence if Wrong: Nếu đưa phương án 1 hoặc 3 vào UAT, tester có thể gọi cùng một kết quả là pass hoặc fail tùy cách hiểu. Defect sau đó không phân biệt được lỗi build với requirement thiếu, làm regression kiểm tra sai phạm vi.

Senior Lens

Defect và regression có vị trí khác nhau trong lifecycle. Defect là chênh lệch giữa kết quả thực tế và test basis đã xác định; không có test basis thì chưa đủ chứng cứ gọi là defect. Regression testing, kiểm thử hồi quy, kiểm tra phần đã hoạt động sau thay đổi, bắt đầu khi Delivery thay đổi build hoặc sửa defect. Phạm vi regression phải dựa trên thành phần, rule, dữ liệu và luồng bị ảnh hưởng đã biết; không dùng danh sách kiểm thử ngẫu nhiên.

Không được dùng cổng Release để “hợp thức hóa” requirement thiếu từ Analysis. Release chỉ đánh giá bằng chứng đã có: kết quả UAT, defect còn lại, rủi ro và quyết định được ghi nhận. Nếu acceptance criteria thay đổi trong UAT, thay đổi đó quay lại Analysis; UAT chỉ tiếp tục sau khi test basis mới đủ và tác động regression được đánh giá.

Quick Reference

Cổng	Câu hỏi đóng cổng	Không đạt thì làm gì
Discovery sang Analysis	Đã xác định vấn đề và ngữ cảnh cần phân tích?	Làm rõ stakeholder input, không viết test case
Analysis sang Delivery	Requirement và acceptance criteria có thể tạo kết quả mong đợi không?	Bổ sung test basis
Delivery sang Testing	Build và thay đổi có được xác định để kiểm tra không?	Không mở vòng kiểm thử
Testing sang UAT	Dữ liệu tổng hợp, môi trường, test basis và trạng thái defect đủ không?	Sửa build hoặc làm rõ Analysis
UAT sang Release	Có kết quả đối chiếu acceptance criteria và rủi ro được ghi nhận không?	Không coi UAT là hoàn tất
Operations sang Discovery	Có tín hiệu thay đổi mới thay vì lỗi đã có test basis không?	Ghi nhận issue, phân loại trước khi đổi requirement

Core

UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) nhận bàn giao qua vai trò, không qua lời nói. Nova Foods Trading & Manufacturing là case mô phỏng, dữ liệu tổng hợp. Mỗi handoff phải có artifact, người gửi, người nhận, điều kiện nhận và nơi escalation. Evidence: CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES đều IN_REVIEW, v0.9.0, ngày 2026-08-07; vì vậy không vai trò nào được gọi nội dung là baseline, approved hay production-ready.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Analysis<br/>BA]
    DL[Delivery<br/>Delivery Lead]
    AR[Architect]
    T[Testing<br/>QA Lead]
    U[UAT<br/>Business Owner delegate]
    R[Release<br/>Release Manager]
    O[Operations<br/>Operations Lead]

    A -->|Requirement, acceptance criteria,<br/>traceability link<br/>Accepted: complete and traceable| DL
    A -->|Requirement, acceptance criteria,<br/>traceability link<br/>Accepted: complete and traceable| AR
    DL -->|Build candidate, release note,<br/>known limitation<br/>Accepted: traced scope covered;<br/>limitations stated| T
    T -->|Test evidence, defect record,<br/>UAT scenario<br/>Accepted: evidence and defects recorded| U
    U -->|UAT defect disposition,<br/>acceptance decision record<br/>Accepted: disposition recorded;<br/>within delegated scope| R
    R -->|Release decision record,<br/>deployment note, support handoff<br/>Accepted: handoff complete| O

    A -.Escalation: integration, data,<br/>or security conflict.-> AR
    DL -.Escalation: build lacks<br/>traced scope.-> A
    T -.Escalation: acceptance criteria<br/>unclear.-> A
    T -.Escalation: business dispute.-> BO[Business Owner]
    U -.Escalation: unresolved risk.-> BO
    U -.Escalation: unresolved risk.-> QL[QA Lead]
    U -.Escalation: unresolved risk.-> AR
    BO -.Explicit delegation scope.-> U
    R -.Escalation: operational incident.-> O
    R -.Escalation: sensitive data<br/>when needed.-> S[Security]
    R -.Escalation: sensitive data<br/>when needed.-> L[Legal Owner]

    BAL[Authority limit:<br/>does not decide architecture] -.-> A
    DLL[Authority limit:<br/>does not confirm business acceptance] -.-> DL
    QAL[Authority limit:<br/>does not accept on behalf of business] -.-> T
    UL[Authority limit:<br/>delegate decides only within<br/>Business Owner delegated scope] -.-> U
    RL[Authority limit:<br/>does not interpret legal, accounting,<br/>or food-safety obligations] -.-> R

    classDef limit fill:#fff,stroke:#666,stroke-dasharray: 4 3;
    class BAL,DLL,QAL,UL,RL limit;

Điểm bàn giao	Upstream owner	Downstream owner	Artifact tối thiểu	Giới hạn thẩm quyền	Escalation
Phân tích sang Delivery	BA	Delivery Lead, Architect	Requirement, acceptance criteria, traceability link	BA làm rõ nhu cầu và truy vết; không quyết kiến trúc	Mâu thuẫn tích hợp, dữ liệu, bảo mật sang Architect
Delivery sang Testing	Delivery Lead	QA Lead	Build candidate, release note, known limitation	Delivery Lead không tự xác nhận business acceptance	Build thiếu phạm vi đã truy vết sang BA và Delivery Lead
Testing sang UAT	QA Lead	Business Owner delegate	Test evidence, defect record, UAT scenario	QA Lead xác nhận kết quả kiểm thử theo test basis; không nhận thay nghiệp vụ	Acceptance criteria mơ hồ sang BA; tranh chấp nghiệp vụ sang Business Owner
UAT sang Release	Business Owner delegate	Release Manager	UAT defect disposition, acceptance decision record	Delegate chỉ quyết trong phạm vi được Business Owner giao rõ; không tự chấp nhận rủi ro kỹ thuật	Rủi ro chưa xử lý sang Business Owner, QA Lead, Architect
Release sang Operations	Release Manager	Operations Lead	Release decision record, deployment note, support handoff	Release Manager không diễn giải nghĩa vụ pháp lý, kế toán, an toàn thực phẩm	Sự cố vận hành sang Operations Lead; dữ liệu nhạy cảm sang Security và Legal Owner khi cần

Applied

Facts: UAT mô phỏng phát hiện màn hình tạo phiếu xuất kho cho phép lưu khi LotNumber trống. Test evidence ghi DEF-UAT-021; liên kết requirement và business rule chưa đủ để xác định lô có bắt buộc cho mọi mặt hàng hay chỉ nhóm hàng cần truy xuất.

Current Behavior: QA Lead chuyển DEF-UAT-021 cho BA và Delivery Lead. Delivery Lead có thể sửa kiểm tra trường, nhưng không được tự quyết phạm vi nghiệp vụ của LotNumber.

Underlying Need: Xác định owner nào giải thích quy tắc, owner nào quyết sửa, và điều kiện nào buộc dừng release. Reasoning: lỗi giao diện là kỹ thuật; tính bắt buộc của lô là quy tắc nghiệp vụ, có thể liên quan truy xuất thực phẩm. Hai loại quyết định thuộc thẩm quyền khác nhau.

Mục	Nội dung
Options	1. Chặn release toàn bộ. 2. Sửa bắt buộc LotNumber cho mọi mặt hàng. 3. Xác minh phạm vi rule rồi sửa theo nhóm hàng.
Decision Criteria	Traceability tới CANONICAL_BUSINESS_RULES; tác động dữ liệu; test evidence; rủi ro vận hành; ý kiến Business Owner; xác minh Legal Owner hoặc domain owner nếu diễn giải liên quan pháp lý.
Decision	Chọn Option 3. Gắn nhãn Verification required cho phạm vi rule. Không suy diễn nghĩa vụ pháp lý từ case mô phỏng.
Authority	Business Owner quyết nhu cầu nghiệp vụ. Architect quyết cách áp dụng rule trong thiết kế. QA Lead quyết đủ bằng chứng test. Release Manager quyết tiến trình release theo risk record, không thay các quyết định trên.
Artifact	DEF-UAT-021, requirement traceability record, rule clarification record, retest evidence, release decision record.
Consequence if Wrong	Option 2 có thể chặn xuất kho không cần số lô. Option 1 có thể trì hoãn không cần thiết. Release khi chưa rõ rule có thể tạo dữ liệu không truy vết được.

Senior Lens

BA là người giữ đường đi của quyết định, không là người sở hữu mọi quyết định. Khi defect chỉ sai code so với acceptance criteria rõ, Delivery Lead sửa và QA Lead retest. Khi defect lộ acceptance criteria thiếu, BA cập nhật phân tích dưới kiểm soát thay đổi; Business Owner quyết ý nghĩa nghiệp vụ. Khi vấn đề chạm kiến trúc, bảo mật, kế toán, pháp lý hoặc an toàn thực phẩm, BA lập gói evidence và escalation đúng owner. Không dùng trạng thái IN_REVIEW của artifact để vượt giới hạn thẩm quyền.

Quick Reference

Tín hiệu	Hành động
Không có artifact bàn giao	Không nhận handoff; yêu cầu record tối thiểu
Requirement và defect mâu thuẫn	BA đối chiếu traceability; không tự đổi rule
Business Owner delegate vượt phạm vi giao quyền	Escalate Business Owner
Defect ảnh hưởng bảo mật hoặc dữ liệu cá nhân	Escalate Security và Legal Owner; giữ nhãn Verification required
Defect chạm hạch toán, thuế hoặc chứng từ	Escalate Accounting Owner và Legal Owner
Test pass nhưng business rule chưa rõ	Không gọi UAT accepted; tạo clarification record

Core

Bản đồ vòng đời giúp thấy chuỗi UAT, quản lý lỗi và kiểm thử hồi quy không phải việc riêng giai đoạn Testing. UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) cần bằng chứng từ yêu cầu, tiêu chí chấp nhận, dữ liệu và bản dựng. Defect (lỗi) cần được phân loại, sửa, kiểm tra lại. Regression testing (kiểm thử hồi quy) kiểm tra thay đổi không làm hỏng chức năng đã chạy đúng. Nova Foods Trading & Manufacturing là case mô phỏng; mọi ID, dữ liệu và quyết định dưới đây là dữ liệu tổng hợp.

Source mermaid — có thể chỉnh sửa

flowchart TD
    DISC["Discovery: nhu cầu và rủi ro"] --> ANALYSIS["Analysis: yêu cầu, quy tắc, tiêu chí chấp nhận"]
    ANALYSIS --> DELIVERY["Delivery: cấu hình, phát triển, build"]
    DELIVERY --> TEST["Testing: chuẩn bị và thực hiện UAT"]
    TEST --> UATOK{"UAT đạt tiêu chí chấp nhận?"}

    UATOK -->|"Không"| CLASSIFY["Phân loại và ghi nhận defect"]
    CLASSIFY --> FIX["Sửa defect"]
    FIX --> RETEST["Kiểm tra lại defect"]
    RETEST --> UATOK

    UATOK -->|"Có"| REG["Kiểm thử thay đổi không làm hỏng chức năng đang chạy đúng"]
    REG --> REGOK{"Hồi quy đạt?"}
    REGOK -->|"Không"| CLASSIFY
    REGOK -->|"Có"| RELEASE["Release"]
    RELEASE --> OPS["Operations: theo dõi sự cố và thay đổi"]

    DISC -.->|"Tín hiệu phạm vi UAT"| TEST
    ANALYSIS -.->|"Yêu cầu, tiêu chí chấp nhận, dữ liệu kiểm thử"| TEST
    DELIVERY -.->|"Bản dựng"| TEST
    UATOK -.->|"Kết quả UAT"| RELEASE
    REGOK -.->|"Kết quả hồi quy"| RELEASE
    OPS -.->|"Sự cố vận hành, xu hướng defect, yêu cầu thay đổi"| ANALYSIS

Sơ đồ dùng flowchart, không phải BPMN. Mũi tên liền chỉ dòng công việc chính. Mũi tên nét đứt chỉ bằng chứng hoặc phản hồi cần chuyển tiếp. Lý do có vòng Operations về Analysis: sự cố vận hành hoặc yêu cầu thay đổi tạo đầu vào mới; không được tự coi đây là phê duyệt thay đổi hay bằng chứng production.

Applied

Trường	Nội dung mô phỏng Nova Foods
Facts	Build NF-ERP-UAT-BUILD-014 sửa lỗi tính tổng số lượng dòng đơn bán hàng. Test lại đạt trên đơn SO-SYN-2408-017.
Current Behavior	Nhóm chỉ retest lỗi gốc; không chạy kiểm thử hồi quy cho màn hình tạo đơn, sửa đơn và API đồng bộ tồn kho.
Underlying Need	Xác định phạm vi hồi quy trước Release vì sửa hàm tính tổng có thể ảnh hưởng nhiều điểm gọi. Bằng chứng: cùng quy tắc tính được dùng ở ba luồng đã nêu.
Options	(1) Chỉ retest lỗi gốc. (2) Chạy hồi quy toàn bộ ERP. (3) Chạy hồi quy theo ảnh hưởng đã truy vết.
Decision Criteria	Mức ảnh hưởng đã biết; rủi ro dữ liệu; khả năng thực thi trong cửa sổ UAT; bằng chứng traceability từ requirement đến test case.
Decision	Chọn (3): lập tập regression gồm ba luồng bị ảnh hưởng. Không suy rộng sang toàn bộ ERP khi chưa có bằng chứng phụ thuộc.
Authority	QA Lead quyết định phạm vi kiểm thử theo test basis. Business Owner xác nhận kết quả UAT nghiệp vụ. Release authority quyết định phát hành. BA duy trì liên kết truy vết, không tự cấp quyền release.
Artifact	Cập nhật test execution record, defect record và traceability liên quan trong artifact kiểm soát IN_REVIEW, v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Bỏ sót luồng sửa đơn có thể làm số lượng tồn kho đồng bộ sai sau phát hành; chạy toàn bộ ERP không cần thiết có thể làm trễ cửa sổ release mà không tăng bằng chứng tương xứng.

Senior Lens

Dùng sơ đồ này để hỏi đúng câu trước mỗi handoff: “Bằng chứng nào đi cùng công việc?” Không chuyển trạng thái từ Testing sang Release chỉ vì defect được đánh dấu đã sửa. Cần tách ba bằng chứng: retest xác nhận lỗi gốc hết, regression xác nhận vùng bị ảnh hưởng vẫn đúng, UAT xác nhận người dùng chấp nhận theo tiêu chí đã có. Nếu thiếu một loại bằng chứng, sơ đồ chỉ ra điểm quay lại: thiếu expected result quay về Analysis; thiếu build hợp lệ quay về Delivery; phát hiện sự cố sau release tạo đầu vào cho Operations rồi Analysis.

Quick Reference

Ký hiệu trên sơ đồ	Nghĩa	Không có nghĩa
Discovery đến Analysis	Nhu cầu được làm rõ thành đầu vào kiểm thử	Yêu cầu đã được phê duyệt
Analysis đến Testing	Test basis có traceability	BA tự xác nhận chất lượng phần mềm
Delivery đến Testing	Có build để kiểm tra	Build được phép release
Testing đến Release	Có kết quả UAT, defect, regression để đánh giá	Release đã được chấp thuận
Operations đến Analysis	Vận hành tạo bằng chứng cho thay đổi tiếp theo	Incident tự động trở thành requirement

4. Input c?n thi?t

Core

UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) cần đầu vào trước khi viết test case. Người mới không cần biết lập trình: cần biết hệ thống phải hỗ trợ việc gì, dữ liệu nào đi qua, quy tắc nào chi phối, và bằng chứng nào chứng minh các thông tin đó có nguồn. Không có đầu vào truy vết được, “kết quả mong đợi” chỉ là suy đoán.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi tên, dữ liệu và tình huống là dữ liệu tổng hợp. Corpus đang ở IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Các giá trị này là ngữ cảnh quản trị, không xác nhận cấu hình ERP, quy trình thật, baseline hay approval.

Bằng chứng là vật chứa thông tin có thể kiểm tra lại, như catalog quy tắc, từ điển dữ liệu, registry ID, hoặc yêu cầu đã được ghi trong artifact kiểm soát. Artifact nguồn là tệp canonical giữ bằng chứng đó. BA không đổi tên, không tạo bản sao làm nguồn mới, không thay ID bằng nhãn tự đặt.

Kiến thức cần có	Người mới cần hiểu	Artifact nguồn canonical	Canonical ID cần giữ nguyên	Dùng cho UAT
Cấu trúc chapter và ranh giới học liệu	Chapter nói gì, không nói gì	/01-curriculum/CHAPTER_MANIFEST.md	CHAPTER_MANIFEST	Xác định phạm vi tài liệu kiểm thử
Quy tắc nghiệp vụ	Điều kiện hệ thống phải xử lý nhất quán	/01-curriculum/CANONICAL_BUSINESS_RULES.md	CANONICAL_BUSINESS_RULES	Tạo expected result theo rule
Ý nghĩa dữ liệu logic	Trường dữ liệu là gì, dùng ra sao	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	CANONICAL_DATA_DICTIONARY	Chọn dữ liệu test và kiểm tra kết quả
Định danh truy vết	Mỗi đối tượng cần mã ổn định để liên kết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	TRACEABILITY_ID_REGISTRY	Nối requirement, rule, test, defect
Nguồn nghiên cứu và giới hạn dùng nguồn	Nguồn nào là primary source, nguồn nói được đến đâu	/00-research/00_SOURCE_MAP.md	00_SOURCE_MAP	Không diễn giải chuẩn, luật, hoặc nguồn ngoài phạm vi
Cấu trúc curriculum	Lifecycle và dependency giữa các chủ đề	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	01_CURRICULUM_ARCHITECTURE	Xác định test basis phải đến từ giai đoạn trước
Danh mục template dự kiến	Template nào thuộc corpus, không suy diễn template thành artifact hoàn tất	/01-curriculum/TEMPLATE_MANIFEST.md	TEMPLATE_MANIFEST	Liên kết đúng template khi artifact tồn tại

ID persistent, hay định danh bền vững, là chuỗi không đổi khi tên hiển thị, vị trí mô tả, hoặc người đọc thay đổi. Ví dụ CANONICAL_DATA_DICTIONARY vẫn phải giữ nguyên trong traceability dù người viết gọi tài liệu đó là “từ điển dữ liệu”. Lý do: liên kết bằng tên tự do dễ đứt; liên kết bằng ID canonical cho phép kiểm tra nguồn gốc.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A["Artifact nguồn canonical"] --> B["Bằng chứng: nhu cầu nghiệp vụ, quy tắc, dữ liệu logic, phạm vi và giới hạn nguồn"]
    A --> C["Canonical ID"]
    B --> D["Test basis UAT"]
    D --> E["Expected result UAT"]
    D --> F["Test case"]
    C -. "liên kết requirement/rule" .-> B
    C -. "liên kết" .-> F
    F --> G["Kết quả thực thi"]
    E --> H{"So sánh kết quả thực thi<br/>với expected result"}
    G --> H
    H -->|"Đạt"| I["Bằng chứng chấp nhận"]
    H -->|"Không đạt"| J["Defect"]
    C -. "liên kết kết quả và defect để truy vết" .-> G
    C -. "liên kết" .-> J

Applied

Mục	Nova Foods mô phỏng, dữ liệu tổng hợp
Facts	Người kiểm thử cần kiểm tra luồng tạo đơn bán hàng và ảnh hưởng đến tồn kho, nhưng chưa được cung cấp một test case hoàn chỉnh.
Current Behavior	Corpus có các artifact canonical về rule, dữ liệu và ID; tất cả ở IN_REVIEW, v0.9.0, ngày 2026-08-07.
Underlying Need	Tạo test basis có thể truy ngược về nguồn, thay vì tự đoán trường dữ liệu, rule, hoặc mã tham chiếu.
Options	(1) Viết test từ ghi nhớ của người kiểm thử. (2) Dùng bản sao tệp hoặc tên tài liệu tự đặt. (3) Dùng artifact canonical và giữ nguyên canonical ID.
Decision Criteria	Có thể truy ngược nguồn; không đổi ID; không biến nội dung mô phỏng thành quy định vận hành; không suy diễn approval.
Decision	Chọn phương án (3). Test basis chỉ tham chiếu /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md bằng đúng ID canonical.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và traceability; không có quyền xác nhận rule Nova Foods cho vận hành, legal, accounting, security, QA sign-off hay release.
Artifact	CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY; trạng thái IN_REVIEW, phiên bản v0.9.0.
Consequence if Wrong	Test có thể dùng sai trường dữ liệu, expected result không có nguồn, defect không nối được về rule, hoặc nội dung mô phỏng bị hiểu sai thành quyết định ERP thực tế.

Senior Lens

Tách “biết” khỏi “tin”. Người kiểm thử có thể biết một quy trình từ trao đổi miệng, nhưng chỉ artifact nguồn kiểm soát mới tạo bằng chứng truy vết trong corpus. Khi thiếu rule hoặc định nghĩa dữ liệu, BA ghi nhận khoảng trống liên kết đến artifact canonical; không tự điền rule để làm test chạy được.

Không dùng ID để ngụ ý thẩm quyền. TRACEABILITY_ID_REGISTRY chứng minh mã được quản trị trong corpus, không chứng minh nội dung gắn với mã đã được baseline, phê duyệt, hợp pháp, hoặc sẵn sàng production.

Quick Reference

Cần kiểm tra trước khi dùng làm input	Đúng	Sai
Tên tệp	Dùng đúng đường dẫn canonical	Dùng bản xuất, bản sao, tên rút gọn
Artifact ID	Giữ nguyên CANONICAL_BUSINESS_RULES	Tự đổi thành BUSINESS_RULES_NOVA
Trạng thái	Ghi IN_REVIEW	Gọi là approved hoặc baselined
Dữ liệu Nova Foods	Ghi mô phỏng, tổng hợp	Gọi là dữ liệu vận hành thật
Bằng chứng	Liên kết artifact nguồn	Dựa vào trí nhớ hoặc suy đoán

Core

Đầu vào UAT chỉ dùng khi BA biết nguồn nào nói gì, ai chịu trách nhiệm và còn đủ mới để kiểm thử. Phân loại nguồn là nhãn cho biết mức thẩm quyền: canonical là nguồn chuẩn được kiểm soát; primary là nguồn gốc do tổ chức ban hành; working là bản làm việc, chỉ tham khảo; Verification required là thông tin chưa đủ chứng cứ để dùng làm test basis.

Kiểm tra chất lượng từng đầu vào theo năm điểm:

Điểm kiểm tra	Câu hỏi	Đạt khi	Không đạt khi
Định danh	Có Artifact ID, đường dẫn, version không?	ID và filename khớp nguồn canonical	Chỉ có ảnh chụp, email, tên rút gọn
Nguồn gốc	Ai phát hành, thuộc loại nguồn nào?	Issuer và source classification ghi rõ	Không xác định được người phát hành
Tính mới	Nội dung còn phù hợp mốc UAT không?	Last updated hoặc access date không muộn hơn 2026-08-07; thay đổi sau mốc được ghi nhận	Không có ngày, hoặc có phiên bản mới chưa đối chiếu
Thẩm quyền	Owner có quyền xác nhận loại nội dung này không?	Owner đúng phạm vi: QA cho test evidence, Business Owner cho nghiệp vụ, Legal/Accounting cho nghĩa vụ chuyên môn	BA tự biến ý kiến thành quy tắc bắt buộc
Khả năng kiểm thử	Có thể chuyển thành điều kiện quan sát và kết quả mong đợi không?	Nêu được dữ liệu, hành động, kết quả, nguồn tham chiếu	Câu chữ mơ hồ, mâu thuẫn, thiếu điều kiện

Freshness là độ mới của đầu vào so với thời điểm lập kế hoạch UAT. Freshness không có nghĩa nội dung đúng; nó chỉ giảm rủi ro dùng bản cũ. Ví dụ, v0.9.0 ngày 2026-08-07 còn mới theo mốc corpus, nhưng vẫn IN_REVIEW, không phải BASELINED hay APPROVED.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Nhận đầu vào] --> B{Có ID, filename, version khớp nguồn canonical?}
    B -- Không --> S[STOP — PLAN REWORK REQUIRED]
    B -- Có --> C{Nguồn nhất quán và Owner rõ?}
    C -- Không hoặc mâu thuẫn --> S
    C -- Có --> D{Owner đúng phạm vi nội dung?}
    D -- Không --> S
    D -- Có --> E{Còn mới tại 2026-08-07?}
    E -- Không hoặc không chứng minh được --> V[Gắn Verification required]
    V --> S
    E -- Có --> F{Có bản mới cần đối chiếu?}
    F -- Có --> G[Đối chiếu bản mới]
    G --> H{Đối chiếu hoàn tất, không còn mâu thuẫn?}
    H -- Không --> S
    H -- Có --> I{Yêu cầu pháp lý, kế toán hoặc an toàn thực phẩm?}
    F -- Không --> I
    I -- Có --> J{Đã xác minh bởi Legal, Accounting hoặc chủ thể chuyên môn an toàn thực phẩm?}
    J -- Không --> S
    J -- Có --> K{Có dữ liệu, hành động, kết quả mong đợi và nguồn tham chiếu?}
    I -- Không --> K
    K -- Không --> S
    K -- Có --> L[Được dùng làm UAT test basis có truy vết]

Điều kiện dừng là STOP — PLAN REWORK REQUIRED khi thiếu ID canonical, nguồn mâu thuẫn, Owner vượt thẩm quyền, bản mới chưa đối chiếu, hoặc một yêu cầu pháp lý, kế toán, an toàn thực phẩm bị viết thành nghĩa vụ UAT mà chưa có xác minh chuyên môn. Dừng kế hoạch không phải dừng dự án; mục tiêu là ngăn test sai nguồn chân lý.

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp. BA nhận CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY, đều IN_REVIEW, v0.9.0, ngày 2026-08-07, theo Asia/Ho_Chi_Minh.

Current Behavior: Nhóm UAT dự định viết test từ ghi chú họp không định danh và từ catalog canonical đang review.

Underlying Need: Cần phân biệt tài liệu nào được dùng làm nền kiểm thử, tài liệu nào chỉ nêu câu hỏi cần xác minh.

Options: (1) Dùng mọi tài liệu nhận được; (2) chỉ dùng nguồn canonical có metadata đầy đủ; (3) dùng canonical làm test basis, gắn ghi chú chưa xác minh là Verification required.

Decision Criteria: Giữ traceability; không suy diễn approval; không biến nội dung review thành quy tắc vận hành; vẫn ghi nhận khoảng trống để đúng người xử lý.

Decision: Chọn phương án 3. CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY là nguồn canonical quy hoạch, chưa phải bằng chứng phê duyệt nghiệp vụ. Ghi chú họp không ID là nguồn working, không dùng một mình để chốt expected result.

Authority: Principal IT Business Analyst / Technical Curriculum Author quản trị ID, version và liên kết artifact. Business Owner xác nhận ý nghĩa nghiệp vụ. QA Owner xác nhận bằng chứng kiểm thử. Legal, Accounting hoặc Food-safety Owner xác minh nội dung chuyên môn thuộc phạm vi họ.

Artifact: UAT input register phải ghi source classification, freshness, owner, trạng thái kiểm tra và stop condition cho từng nguồn.

Consequence if Wrong: Test có thể “pass” theo ghi chú cũ nhưng sai quy tắc đã cập nhật; hoặc test lỗi pháp lý/kế toán dựa trên diễn giải không có thẩm quyền. Kết quả đó không đủ tin cậy để quyết định release.

Senior Lens

Không dùng nhãn “primary source” để thay thế “canonical source”. URL ISO, ISTQB hoặc văn bản pháp luật là primary source từ tổ chức phát hành; chúng không tự trở thành quy tắc Nova Foods. CANONICAL_BUSINESS_RULES là canonical trong corpus, nhưng tại IN_REVIEW vẫn không chứng minh Business Owner đã xác nhận nội dung.

Cầu nối suy luận phải hiện rõ: nguồn nói gì, phạm vi nguồn cho phép gì, ai phải xác minh phần còn lại. Ví dụ, Luật Kế toán tại URL chính thức là nguồn pháp lý primary; nếu UAT cần expected result liên quan hạch toán, BA ghi Verification required — Accounting Owner, vì nguồn seed không cấp diễn giải kế toán cho Nova Foods mô phỏng.

Quick Reference

Trường input register	Giá trị mẫu tổng hợp	Kiểm soát
Input ID	UAT-IN-001	ID duy nhất trong register
Artifact ID	TRACEABILITY_ID_REGISTRY	Giữ nguyên canonical ID
Filename	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Không thay bằng bản sao
Source classification	Canonical planning artifact	Không gọi là approved requirement
Status / Version	IN_REVIEW / v0.9.0	Không suy diễn baseline
Freshness date	2026-08-07	Đối chiếu theo Asia/Ho_Chi_Minh
Accountable Owner	Principal IT Business Analyst / Technical Curriculum Author	Chỉ quản trị artifact
Verification state	Verification required nếu cần xác nhận nghiệp vụ	Gán đúng Owner chuyên môn
Stop condition	Thiếu chứng cứ cho expected result	STOP — PLAN REWORK REQUIRED

Core

Bảng dưới là tập đầu vào UAT cho Nova Foods Trading & Manufacturing, case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Mỗi hàng phải giữ nguyên Artifact ID và đường dẫn canonical. IN_REVIEW nghĩa là còn xem xét; không phải baseline, phê duyệt, hay quyền chạy production.

Input cần cho UAT	Artifact ID / nguồn canonical	Phân loại nguồn	Giá trị mô phỏng dùng khi lập kế hoạch	Owner ghi nhận	Freshness tại 2026-08-07	Trạng thái xác minh	Mục chưa giải quyết
Phạm vi chapter và chuỗi học	CHAPTER_MANIFEST /01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Chapter UAT là /02-handbook/20-uat-planning-defects-and-regression.md; Status IN_REVIEW; Version v0.9.0	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có metadata	Chưa có baseline reference
Kiến trúc curriculum	01_CURRICULUM_ARCHITECTURE /01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Controlled planning artifact	Locale vi-VN; timezone Asia/Ho_Chi_Minh; tiền tệ mô phỏng VND	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có metadata	Không suy diễn thành cấu hình ERP thật
Registry liên kết	TRACEABILITY_ID_REGISTRY /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	Chỉ dùng ID đã đăng ký; liên kết phải giữ đúng chuỗi ID	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có metadata	Verification required: chưa thấy ID test case, defect, test cycle được cung cấp trong lô này
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES /01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	Là nguồn dự kiến cho business rule làm test basis	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có metadata quản trị	Verification required: chưa có nội dung rule cụ thể để viết expected result
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Controlled planning artifact	Là nguồn dự kiến cho field, kiểu dữ liệu, giá trị hợp lệ	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có metadata quản trị	Verification required: chưa có định nghĩa entity, field, khóa dữ liệu
Kế hoạch template	TEMPLATE_MANIFEST /01-curriculum/TEMPLATE_MANIFEST.md	Controlled planning artifact	Template UAT/defect chỉ là kế hoạch nếu chưa có tệp được tạo	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07	Có metadata quản trị	Verification required: chưa có filename template UAT hoặc defect canonical
Thuật ngữ kiểm thử	ISTQB CTFL Syllabus v4.0.1 https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf	Primary testing syllabus	Dùng thuật ngữ test basis, test case, expected result, defect theo nguồn kiểm thử	ISTQB	Nguồn truy cập 2026-08-07	Nguồn xác minh	Không thay thế requirement Nova Foods
Quy tắc traceability thực phẩm	Luật An toàn thực phẩm 55/2010/QH12 https://vanban.chinhphu.vn/?docid=96032&pageid=27160	Official legal source	Chỉ tạo ngữ cảnh cần truy vết/thu hồi; không tự tạo nghĩa vụ ERP chi tiết	Quốc hội Việt Nam; Legal/Domain Owner xác minh áp dụng	Nguồn truy cập 2026-08-07	Nguồn xác minh	Verification required: Legal Owner và Food Safety Domain Owner xác nhận yêu cầu áp dụng
Dữ liệu chạy UAT	Không có artifact canonical được cung cấp	Chưa phân loại	Bộ dữ liệu giả định: kho WH-HCM-01, mặt hàng FG-NF-001, số lượng 100, giá trị 2500000 VND	Chưa xác định	Không có mốc freshness	Không đủ bằng chứng	UNRESOLVED: cần dataset canonical, masking rule và owner dữ liệu
Bằng chứng chạy và defect	Không có artifact canonical được cung cấp	Chưa phân loại	Không ghi nhận test execution, screenshot, log, defect hay retest result	Chưa xác định	Không có mốc freshness	Không đủ bằng chứng	UNRESOLVED: không được tuyên bố pass, fail, defect closure hoặc UAT sign-off

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Input: artifact canonical và dữ liệu giả định] --> B[Kiểm tra ID, đường dẫn, status, version]
    B --> C{Dùng yêu cầu truy vết làm test basis?}
    C -- Có --> D{Legal Owner và Food Safety Domain Owner đã xác nhận áp dụng?}
    D -- Chưa --> V[Verification required: xác minh yêu cầu truy vết]
    D -- Rồi --> E{Đã xác minh business rule, field và expected result từ nguồn canonical?}
    C -- Không --> E
    E -- Chưa --> V
    E -- Rồi --> F{Dataset canonical, masking rule và owner dữ liệu đã có?}
    F -- Chưa --> U[UNRESOLVED: thiếu dữ liệu đầu vào đã xác minh]
    F -- Rồi --> G[Lập test case và expected result]
    V --> X[Bị chặn: không chạy UAT, không kết luận pass/fail]
    U --> X
    G --> H[Chỉ là kế hoạch: không là quyền chạy UAT]
    H --> I[Không kết luận pass/fail, defect closure hoặc UAT sign-off]

Applied

Trường	Nội dung
Facts	Corpus có CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY, đều IN_REVIEW, v0.9.0, ngày 2026-08-07.
Current Behavior	Chưa có test case ID, defect ID, dataset canonical, execution evidence hay approval reference trong đầu vào được cung cấp.
Underlying Need	UAT cần test basis: requirement hoặc rule, expected result, dữ liệu synthetic và bằng chứng chạy. Thiếu một phần thì không thể phân biệt lỗi hệ thống với lỗi dữ liệu hoặc kỳ vọng chưa xác định.
Options	Dùng dữ liệu giả định để minh họa planning; hoặc dừng trước test execution đến khi artifact canonical xuất hiện.
Decision Criteria	Không đổi ID canonical; không biến giả định thành rule; không tuyên bố approval; không dùng dữ liệu thật.
Decision	Dùng bảng trên cho planning; gắn Verification required và UNRESOLVED cho mọi khoảng trống. Không chạy hay kết luận UAT.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì traceability. Business Owner, QA Owner, Data Owner, Legal Owner và Food Safety Domain Owner xác nhận phần thuộc thẩm quyền.
Artifact	/02-handbook/20-uat-planning-defects-and-regression.md, section 04-inputs; tham chiếu các artifact canonical trong bảng.
Consequence if Wrong	Test case có thể kiểm tra sai rule, dùng dữ liệu không kiểm soát, đóng defect sai, hoặc bị hiểu nhầm là bằng chứng tuân thủ hay phê duyệt.

Senior Lens

Input “có tài liệu” chưa đủ. Input dùng được phải trả lời được: nguồn nào, ID nào, phiên bản nào, owner nào, dữ liệu nào và ai xác nhận khoảng trống. Nếu CANONICAL_BUSINESS_RULES chưa cung cấp rule cụ thể, BA không được tự viết expected result như thể đó là quy tắc Nova Foods. Nếu dataset chưa có owner và masking rule, BA không được đưa dữ liệu cá nhân, dữ liệu tài chính thật hay export production vào UAT.

Quick Reference

Nhãn	Nghĩa vận hành
IN_REVIEW	Đang xem xét có kiểm soát; không phải approved hoặc baselined
Verification required	Có nguồn hoặc giả định, nhưng cần vai trò có thẩm quyền xác nhận trước khi dùng làm test basis
UNRESOLVED	Chưa có artifact hoặc bằng chứng đủ; không chạy test và không kết luận
Synthetic data	Dữ liệu tự tạo cho học liệu, không đại diện dữ liệu Nova Foods thật

5. Step-by-step BA Activities

Core

UAT (User Acceptance Testing) là kiểm thử chấp nhận bởi người đại diện nghiệp vụ. BA không quyết định hệ thống “đạt”; BA biến nhu cầu, rule và acceptance criteria thành test basis truy vết được, giữ bằng chứng, rồi chuyển quyết định cho đúng authority. Nova Foods là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là synthetic data.

Applied

Facts: /02-handbook/20-uat-planning-defects-and-regression.md đang IN_REVIEW, v0.9.0, ngày 2026-08-07. CHAPTER_MANIFEST, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY là nguồn canonical cấp kế hoạch; không tự chứng minh rule UAT cụ thể đã được xác nhận.

Current Behavior: Input có thể thiếu rule, owner, test data hoặc acceptance criteria đã xác minh. Nếu BA tự điền expected result, UAT kiểm tra giả định thay vì nhu cầu có thẩm quyền.

Underlying Need: Tạo luồng UAT kiểm soát được từ chuẩn bị đến handoff; mỗi kết quả phải truy ngược về nguồn, người chịu thẩm quyền và bằng chứng.

#	Actor	Action và object	Evidence produced	Decision rule	Quality gate	Escalation route
1	BA	Lập inventory test basis từ requirement, acceptance criteria, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và traceability ID hiện có. Gắn mỗi mục Ready, Verification required hoặc UNRESOLVED.	Danh sách test basis có nguồn, version, owner, trạng thái.	Chỉ mục Ready mới được lập test case. Mục thiếu nguồn hoặc owner là UNRESOLVED.	Mỗi expected result có ít nhất một nguồn canonical hoặc nhãn Verification required.	Business Owner cho nhu cầu nghiệp vụ; Data Owner cho dữ liệu; Legal, Accounting hoặc Food Safety Domain Owner cho nội dung thuộc thẩm quyền.
2	BA	Xác định phạm vi UAT: process, vai trò người dùng, chức năng, integration, dữ liệu và ngoài phạm vi. Không suy diễn cấu hình ERP.	UAT scope draft, danh sách assumptions và exclusions.	Scope chỉ chứa capability có test basis. Assumption không biến thành rule.	Không có mục scope nào thiếu traceability hoặc bị gọi là approved.	Business Owner xử lý ưu tiên nghiệp vụ; Architect xử lý boundary kỹ thuật và integration.
3	BA cùng QA Owner	Chuyển từng test basis Ready thành test case: precondition, synthetic test data, bước chạy, expected result, actual result, evidence link và defect link khi lỗi.	Test case draft và traceability matrix.	Một test case kiểm tra một outcome quan sát được. Expected result không được viết từ suy đoán BA.	Test case có thể chạy độc lập bởi tester được chỉ định; dữ liệu không chứa dữ liệu cá nhân hoặc production.	QA Owner xử lý khả năng kiểm thử, coverage và cách ghi bằng chứng; Data Owner xử lý dataset.
4	BA	Chuẩn bị synthetic data theo CANONICAL_DATA_DICTIONARY: giá trị hợp lệ, biên, sai định dạng và dữ liệu trạng thái cần thiết. Ghi rõ nguồn tạo, mục đích và hạn chế.	Data preparation log, dataset reference, masking confirmation nếu áp dụng.	Dữ liệu chỉ phục vụ outcome đã định nghĩa. Không dùng export production.	Mỗi giá trị dùng trong test case có mô tả logic và không lộ dữ liệu thật.	Data Owner khi thiếu trường, phân loại dữ liệu hoặc quy tắc che giấu; Security Owner khi có rủi ro truy cập.
5	UAT Tester	Chạy test case đúng precondition và ghi actual result, thời điểm Asia/Ho_Chi_Minh, ảnh màn hình hoặc log synthetic. Không sửa expected result khi chạy.	Test execution record: Pass, Fail, Blocked hoặc Not Run.	Pass khi actual result khớp expected result. Fail khi khác. Blocked khi môi trường, quyền hoặc dependency ngăn chạy.	Evidence cho thấy test case ID, dữ liệu synthetic, bước và kết quả; không chỉ ghi nhận bằng lời.	QA Owner xử lý lỗi thực thi test; Architect hoặc đội kỹ thuật xử lý môi trường, quyền và integration.
6	BA cùng UAT Tester	Triage mỗi Fail: xác nhận test basis, tái hiện lỗi, phân loại defect hay sai test case, ghi impact nghiệp vụ và traceability.	Defect record hoặc test-case correction record, gồm evidence và liên kết test basis.	Chỉ tạo defect khi expected result có nguồn Ready. Nếu nguồn chưa xác minh, giữ Verification required, không kết luận lỗi hệ thống.	Defect record phân biệt rõ observed behavior, expected result, dữ liệu, bước tái hiện và impact.	Business Owner xác nhận impact nghiệp vụ; QA Owner xác nhận phân loại; Architect xử lý nguyên nhân kỹ thuật; domain owner xác nhận rule tranh chấp.
7	BA cùng QA Owner	Chọn regression test sau khi có change hoặc defect fix: lấy test case chạm trực tiếp chức năng sửa, rule liên quan, integration và luồng bị ảnh hưởng.	Regression selection record với lý do chọn từng test case.	Chọn theo traceability và impact, không chọn ngẫu nhiên. Mục thiếu impact analysis là UNRESOLVED.	Mỗi test regression liên kết change hoặc defect record và test basis gốc.	Architect xác nhận phạm vi kỹ thuật bị ảnh hưởng; Business Owner xác nhận rủi ro nghiệp vụ.
8	BA	Tổng hợp review pack: coverage, trạng thái chạy, defect theo mức impact, blocked item, unresolved assumption, regression result và quyết định cần authority.	UAT review pack, decision log và open-items register.	BA chỉ báo cáo evidence; không tuyên bố release readiness, approval hoặc compliance.	Số liệu khớp execution record; mọi open item có owner và escalation route.	QA Owner cho chất lượng kiểm thử; Business Owner cho chấp nhận nghiệp vụ; các owner chuyên môn cho phần thuộc thẩm quyền.
9	BA	Handoff có kiểm soát cho QA Owner, Business Owner và delivery owner: bàn giao link artifact, trạng thái, unresolved item, evidence location và quyết định còn chờ.	Handoff record ghi người nhận, thời điểm và artifact reference.	Handoff hoàn tất khi người nhận truy cập được evidence; không đồng nghĩa approval hay baseline.	Không có defect, blocked test hoặc assumption bị che giấu trong handoff.	Principal IT Business Analyst / Technical Curriculum Author xử lý đứt traceability; authority tương ứng xử lý quyết định nội dung.

Thành phần quyết định	Nội dung Nova Foods mô phỏng
Options	Chạy UAT với expected result do BA tự suy diễn; hoặc chỉ chạy test case có test basis Ready.
Decision Criteria	Traceability đủ, owner đúng thẩm quyền, synthetic data kiểm soát được, evidence tái kiểm được, assumption không bị biến thành rule.
Decision	Chỉ chạy và kết luận Pass hoặc Fail với test case có test basis Ready. Mục còn lại ghi Verification required hoặc UNRESOLVED.
Authority	Business Owner, QA Owner, Data Owner, Architect, Legal Owner, Accounting Owner và Food Safety Domain Owner xác nhận phần thuộc thẩm quyền; BA duy trì gói bằng chứng và truy vết.
Artifact	UAT scope draft, test case draft, test execution record, defect record, regression selection record, UAT review pack và handoff record trong phạm vi /02-handbook/20-uat-planning-defects-and-regression.md.
Consequence if Wrong	UAT có thể xác nhận sai outcome, che giấu defect, dùng dữ liệu không an toàn, hoặc bị hiểu nhầm là approval, baseline hay bằng chứng tuân thủ.

Senior Lens

Cầu nối suy luận: expected result quyết định Pass hay Fail; expected result thiếu nguồn làm kết quả thiếu nền tảng; vì vậy BA phải chặn kết luận thay vì “điền cho đủ”. Blocked là trạng thái bằng chứng thiếu điều kiện chạy, không phải Fail. Verification required là trạng thái nguồn chưa đủ authority, không phải chấp nhận tạm.

Quick Reference

Trạng thái	Hành động BA
Ready	Lập hoặc chạy test case.
Verification required	Giữ truy vết, gửi đúng owner xác minh, không kết luận defect.
UNRESOLVED	Không chạy hoặc không đóng test; ghi rõ khoảng trống và escalation route.
Blocked	Ghi điều kiện chặn, evidence và owner xử lý; chạy lại sau khi điều kiện được khôi phục.

Core

Quy trình UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) biến yêu cầu nghiệp vụ thành bằng chứng để Business Owner quyết định mức sẵn sàng nghiệp vụ. BA không tự kết luận chất lượng hay phê duyệt phát hành. BA tổ chức đầu vào, bảo toàn truy vết, ghi nhận quyết định và chuyển đúng vấn đề cho đúng thẩm quyền. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp.

Bước	Actor	Hành động trên đối tượng	Bằng chứng tạo ra	Quy tắc quyết định	Quality gate	Tuyến escalation
1. Chuẩn bị test basis	BA	Đối chiếu requirement, business rule, acceptance criteria, luồng nghiệp vụ và dữ liệu tham chiếu trong các artifact canonical.	Danh sách test basis có nguồn, phiên bản v0.9.0, trạng thái IN_REVIEW, liên kết tới /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md.	Chỉ đưa vào UAT nội dung có nguồn xác định. Nội dung thiếu acceptance criteria không được suy diễn thành test condition.	Mỗi test basis có nguồn, owner nghiệp vụ dự kiến và phạm vi rõ. Không có baseline hay approval ngầm định.	Mâu thuẫn rule chuyển Business Owner; thiếu hoặc mơ hồ dữ liệu chuyển Data Owner; vấn đề pháp lý, kế toán, an toàn thực phẩm chuyển owner chuyên môn tương ứng.
2. Lập điều kiện test	BA cùng UAT Lead	Chuyển test basis thành test condition: điều kiện đầu vào, thao tác, kết quả mong đợi, dữ liệu tổng hợp, vai trò người chạy test.	UAT test condition register, ghi rõ phạm vi module ERP mô phỏng, môi trường, dữ liệu và người chịu trách nhiệm chạy.	Một test condition chỉ kiểm tra một kết quả nghiệp vụ có thể quan sát. Kết quả mong đợi phải truy được về test basis.	Không dùng dữ liệu cá nhân hay dữ liệu vận hành thật. Giá trị tiền tệ dùng VND, ngày theo Asia/Ho_Chi_Minh.	Điều kiện không kiểm thử được chuyển BA làm rõ với Business Owner; cần thay đổi tích hợp chuyển Architect và QA Lead.
3. Kiểm tra sẵn sàng UAT	UAT Lead, BA, QA Lead	Kiểm tra quyền truy cập, môi trường, dữ liệu tổng hợp, bản build, luồng tích hợp và người tham gia trước khi chạy.	UAT readiness checklist, danh sách blocker và thời điểm kiểm tra theo Asia/Ho_Chi_Minh.	Không bắt đầu test case bị chặn bởi thiếu môi trường, quyền, dữ liệu hoặc build không xác định.	Mỗi người chạy test đăng nhập được bằng vai trò mô phỏng; dữ liệu test khôi phục được; build có định danh phát hành do kỹ thuật cung cấp.	Lỗi môi trường chuyển Technical Lead; quyền sai chuyển Security/Access Owner; dữ liệu sai chuyển Data Owner.
4. Thực thi và ghi nhận	UAT Tester	Chạy từng test condition, ghi đầu vào thực tế, bước thực hiện, kết quả quan sát, ảnh chụp hoặc log không chứa dữ liệu nhạy cảm.	Test execution record: Pass, Fail, Blocked hoặc Not Run; bằng chứng đính kèm; thời điểm chạy; người chạy.	Pass khi kết quả quan sát khớp hoàn toàn kết quả mong đợi. Fail khi khác biệt tái lập được. Blocked khi không thể kiểm tra do trở ngại ngoài test condition.	Record có đủ kết quả, bằng chứng và liên kết test basis. BA không đổi Fail thành Pass để đạt tiến độ.	Fail chức năng chuyển QA Lead và Technical Lead; nghi ngờ sai rule chuyển Business Owner; dấu hiệu lộ dữ liệu hoặc truy cập trái quyền chuyển Security Owner ngay.
5. Phân loại và triage defect	BA, QA Lead, Technical Lead, Business Owner	Phân biệt defect với change request, lỗi dữ liệu, lỗi môi trường và thiếu yêu cầu. Đánh giá ảnh hưởng nghiệp vụ bằng bằng chứng test execution.	Defect triage record: mô tả tái lập, phạm vi ảnh hưởng, liên kết test basis, phân loại, owner xử lý và quyết định triage.	Là defect khi hệ thống khác kết quả mong đợi đã truy vết. Là change request khi nhu cầu mới hoặc thay đổi kết quả mong đợi.	Không gán nguyên nhân kỹ thuật khi chưa có xác nhận Technical Lead. Không gán mức ưu tiên chỉ theo ý kiến một người.	Tranh chấp mức ảnh hưởng chuyển Business Owner và QA Lead; ảnh hưởng kiến trúc hoặc API chuyển Architect; ảnh hưởng pháp lý chuyển Legal Owner.
6. Xác nhận sửa và regression	QA Lead, UAT Tester, BA	Sau khi kỹ thuật cung cấp build sửa lỗi, chạy lại test condition lỗi và các test condition liên quan theo phạm vi ảnh hưởng đã xác định. Regression là kiểm thử lại chức năng đã từng đúng để phát hiện tác động từ thay đổi.	Retest record, regression scope và kết quả Pass/Fail/Blocked mới.	Chỉ đóng defect khi retest đạt và không có regression fail trong phạm vi đã thống nhất. Nếu scope tác động chưa rõ, không tuyên bố regression hoàn tất.	Build sửa lỗi, test evidence và liên kết defect nhất quán. Test lại dùng dữ liệu tổng hợp tương đương dữ liệu ban đầu.	Scope không rõ chuyển Technical Lead hoặc Architect; regression fail chuyển lại triage; blocker kéo dài chuyển UAT Lead và Business Owner để quyết định lịch trình.
7. Tổng hợp review và handoff có kiểm soát	BA	Tổng hợp phạm vi đã chạy, chưa chạy, blocker, defect mở, rủi ro và giới hạn bằng chứng; chuyển gói review cho vai trò có thẩm quyền.	UAT summary và handoff package, liên kết test execution, defect triage, retest và regression records.	BA chỉ báo cáo trạng thái bằng chứng. Quyết định chấp nhận nghiệp vụ thuộc Business Owner; quyết định chất lượng test thuộc QA Lead; quyết định phát hành thuộc thẩm quyền được chỉ định.	Báo cáo nêu rõ IN_REVIEW, v0.9.0, ngày 2026-08-07; không dùng từ “đã phê duyệt”, “đã baseline” hoặc “sẵn sàng production” khi chưa có tham chiếu kiểm soát.	Defect mở mức ảnh hưởng cao chuyển Business Owner, QA Lead và Technical Lead; rủi ro bảo mật chuyển Security Owner; nội dung pháp lý hoặc kế toán chuyển owner chuyên môn.

Applied

Nova Foods Trading & Manufacturing là case 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ệ VND. Bảng dưới là bản thực thi UAT (User Acceptance Testing — kiểm thử chấp nhận người dùng) cho luồng tạo đơn bán hàng, kiểm tra tồn kho và phát hành yêu cầu giao hàng. Mục tiêu là tạo bằng chứng để Business Owner quyết định chấp nhận phạm vi đã kiểm thử; không phải xác nhận tuân thủ pháp lý, kế toán hay production.

Facts	Current Behavior	Underlying Need	Options	Decision Criteria	Decision	Authority	Artifact	Consequence if Wrong
Đơn mô phỏng SO-SIM-260807-01; khách hàng mô phỏng; mặt hàng tổng hợp; tổng giá trị 12.500.000 VND.	ERP tạo đơn, giữ tồn kho, sinh yêu cầu giao hàng khi tồn khả dụng.	Chứng minh luồng bán hàng không cho phép giao vượt tồn khả dụng và giữ truy vết kết quả UAT.	Chạy happy path; chạy happy path và trường hợp thiếu tồn; bỏ kiểm tra thiếu tồn.	Bao phủ yêu cầu, dữ liệu có thể lặp lại, kết quả phân loại rõ, không dùng dữ liệu thật.	Chạy happy path và thiếu tồn; ghi bằng chứng từng kết quả.	UAT Tester ghi nhận; Business Owner xác nhận nghiệp vụ; QA Lead quản lý trạng thái lỗi; Architect xử lý nghi vấn tích hợp. Không có approval được suy diễn từ bảng này.	/02-handbook/20-uat-planning-defects-and-regression.md, log thực thi UAT và bằng chứng màn hình mô phỏng.	Bỏ trường hợp thiếu tồn có thể che lỗi giao vượt tồn; quyết định chấp nhận phạm vi mất cơ sở kiểm chứng.

Bước	Actor	Action	Object	Evidence produced	Decision rule	Quality gate	Escalation route
1	BA	Đối chiếu phạm vi UAT với yêu cầu, quy tắc và dữ liệu test đã được cung cấp.	Luồng đơn bán hàng mô phỏng.	Danh sách điều kiện kiểm thử và liên kết nguồn.	Không có nguồn truy vết thì không đặt kết quả là Pass.	Mỗi điều kiện có đầu vào, kết quả mong đợi, nguồn tham chiếu.	Thiếu hoặc mâu thuẫn rule: Business Owner; mâu thuẫn dữ liệu: Data Owner.
2	UAT Tester	Tạo đơn SO-SIM-260807-01 với tồn khả dụng đủ cho số lượng đặt.	Đơn bán hàng và tồn kho mô phỏng.	Ảnh màn hình, thời điểm chạy, kết quả tạo đơn.	Pass khi đơn được tạo và trạng thái tồn phản ánh lượng đã giữ theo hành vi đã xác định.	Không dùng dữ liệu cá nhân, khách hàng thật, giá thật.	Lỗi màn hình hoặc xử lý: QA Lead; nghi vấn cấu hình: Architect.
3	UAT Tester	Xác nhận yêu cầu giao hàng được sinh từ đơn hợp lệ.	Yêu cầu giao hàng mô phỏng.	Mã tham chiếu giao hàng hiển thị trong bằng chứng.	Pass khi liên kết đơn–giao hàng truy vết được hai chiều trong phạm vi test.	Không có bản ghi trùng, không mất liên kết.	Liên kết sai: QA Lead; nghi vấn tích hợp: Architect.
4	UAT Tester	Tạo tình huống số lượng đặt vượt tồn khả dụng.	Đơn bán hàng thiếu tồn mô phỏng.	Thông báo hệ thống hoặc trạng thái chặn, ảnh màn hình.	Pass khi hệ thống chặn, cảnh báo hoặc xử lý đúng rule nguồn; nếu rule chưa rõ, kết quả là Blocked, không tự suy luận.	Thông báo có thể hiểu, dữ liệu không bị ghi sai.	Rule chưa rõ: Business Owner; lỗi kỹ thuật: QA Lead.
5	BA	So sánh actual result với expected result, phân loại Pass, Fail hoặc Blocked.	Bằng chứng UAT của bước 2–4.	UAT execution record, danh sách defect hoặc blocker.	Fail khi actual result khác expected result có nguồn; Blocked khi môi trường, quyền, dữ liệu hoặc rule thiếu.	Mỗi Fail có bước tái hiện, dữ liệu tổng hợp, ảnh hưởng và bằng chứng.	Defect: QA Lead; blocker môi trường: Delivery Lead; tranh chấp nghiệp vụ: Business Owner.
6	BA	Rà soát tính đầy đủ trước handoff có kiểm soát.	Gói UAT mô phỏng.	Bản tổng hợp Pass/Fail/Blocked và danh sách điểm mở.	Chỉ handoff khi mỗi kết quả có bằng chứng và route xử lý; không gọi phạm vi “accepted” khi còn Fail hoặc Blocked chưa có quyết định thẩm quyền.	Traceability không đứt từ điều kiện đến bằng chứng và phân loại.	Quyết định chấp nhận: Business Owner; chất lượng test: QA Lead.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[BA đối chiếu phạm vi, rule, dữ liệu và nguồn truy vết] --> B{Nguồn và dữ liệu đủ, không mâu thuẫn?}

    B -->|Không rõ rule| C[BA ghi Blocked: rule thiếu hoặc mâu thuẫn, kèm bằng chứng]
    B -->|Mâu thuẫn dữ liệu| D[BA ghi Blocked: dữ liệu test mâu thuẫn, kèm bằng chứng]
    B -->|Có| G[UAT Tester tạo đơn đủ tồn]

    C --> E[Business Owner làm rõ rule]
    E --> EA{Rule đã rõ?}
    EA -->|Có| A
    EA -->|Chưa rõ| EB[BA cập nhật điểm mở Blocked và route xử lý]
    EB --> W[BA tổng hợp Pass, Fail, Blocked và điểm mở]

    D --> F[Data Owner làm rõ dữ liệu]
    F --> FA{Dữ liệu test đã rõ?}
    FA -->|Có| A
    FA -->|Chưa rõ| FB[BA cập nhật điểm mở Blocked và route xử lý]
    FB --> W

    G --> H{Đơn tạo và tồn giữ đúng expected result có nguồn?}
    H -->|Có| K[UAT Tester xác nhận yêu cầu giao hàng]
    H -->|Không| I[BA ghi Fail điều kiện tạo đơn hoặc giữ tồn, kèm bằng chứng]
    H -->|Nghi vấn cấu hình| J[Architect xử lý nghi vấn cấu hình]
    H -->|Môi trường hoặc quyền chặn| T[BA ghi Blocked: môi trường hoặc quyền, kèm bằng chứng]

    J --> JA{Cấu hình đã rõ hoặc xử lý?}
    JA -->|Có| J1[UAT Tester chạy lại điều kiện tạo đơn hoặc giữ tồn]
    JA -->|Chưa rõ hoặc chưa xử lý| JB[BA cập nhật điểm mở Blocked: nghi vấn cấu hình, kèm bằng chứng]
    J1 --> H
    JB --> W

    K --> L{Đơn và giao hàng liên kết hai chiều, không trùng, không mất liên kết?}
    L -->|Có| O[BA ghi Pass điều kiện tạo đơn, giữ tồn và giao hàng, kèm bằng chứng]
    L -->|Không| M[BA ghi Fail điều kiện giao hàng, kèm bằng chứng]
    L -->|Nghi vấn tích hợp| N[Architect xử lý nghi vấn tích hợp]
    L -->|Môi trường hoặc quyền chặn| T

    N --> NA{Tích hợp đã rõ hoặc xử lý?}
    NA -->|Có| N1[UAT Tester chạy lại điều kiện liên kết giao hàng]
    NA -->|Chưa rõ hoặc chưa xử lý| NB[BA cập nhật điểm mở Blocked: nghi vấn tích hợp, kèm bằng chứng]
    N1 --> L
    NB --> W

    O --> P[UAT Tester chạy trường hợp thiếu tồn]
    P --> Q{Hệ thống chặn, cảnh báo hoặc xử lý đúng rule nguồn?}
    Q -->|Có| R[BA ghi Pass điều kiện thiếu tồn, kèm bằng chứng]
    Q -->|Không| S[BA ghi Fail điều kiện thiếu tồn, kèm bằng chứng]
    Q -->|Rule thiếu| C
    Q -->|Môi trường hoặc quyền chặn| T

    I --> U[QA Lead quản lý trạng thái defect]
    M --> U
    S --> U

    U --> AA{Defect sẵn sàng retest?}
    AA -->|Tạo đơn hoặc giữ tồn| G
    AA -->|Liên kết giao hàng| K
    AA -->|Thiếu tồn| P
    AA -->|Chưa sẵn sàng| AC[BA cập nhật điểm mở defect và bằng chứng]
    AC --> W

    T --> V[Delivery Lead xử lý blocker môi trường hoặc quyền]
    V --> AB{Blocker đã được xử lý?}
    AB -->|Có, retest tạo đơn hoặc giữ tồn| G
    AB -->|Có, retest liên kết giao hàng| K
    AB -->|Có, retest thiếu tồn| P
    AB -->|Chưa xử lý| AD[BA cập nhật điểm mở Blocked và route xử lý]
    AD --> W

    R --> W

    W --> X{Mỗi kết quả đủ bằng chứng và mỗi điểm mở có route xử lý?}
    X -->|Có| Y{Business Owner quyết định phạm vi?}
    X -->|Không| Z{Loại điểm mở?}

    Y -->|Chấp nhận| ZA[Handoff có kiểm soát: phạm vi được chấp nhận]
    Y -->|Không chấp nhận| ZB[Handoff có kiểm soát: phạm vi không được chấp nhận]

    Z -->|Defect| U
    Z -->|Blocker môi trường hoặc quyền| V
    Z -->|Rule thiếu hoặc mâu thuẫn| E
    Z -->|Dữ liệu test mâu thuẫn| F

Bằng chứng dẫn đến phân loại: ảnh màn hình và dữ liệu chạy chứng minh actual result; nguồn truy vết xác định expected result; so sánh hai phần mới cho phép Pass hoặc Fail. Không có rule nguồn thì BA ghi Blocked, vì suy đoán rule sẽ biến UAT thành quyết định nghiệp vụ không thuộc thẩm quyền BA.

6. Output thu ???c

Core

Output UAT là artifact có kiểm soát tạo mới hoặc cập nhật sau khi BA lập kế hoạch, ghi nhận lỗi và xác định phạm vi regression. Artifact không phải bằng chứng phê duyệt, baseline, tuân thủ hay sẵn sàng production. Nova Foods là case mô phỏng giáo dục; toàn bộ dữ liệu tổng hợp.

Canonical ID	Artifact	Tệp kiểm soát	Owner	Status	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
UAT_PLAN_NF_ERP	UAT Plan	/02-handbook/20-uat-planning-defects-and-regression.md	BA	IN_REVIEW	Mục tiêu UAT, phạm vi, test basis, vai trò, môi trường mô phỏng, dữ liệu tổng hợp, entry criteria, exit criteria, rủi ro, route escalation	Ghi version, ngày 2026-08-07, người sửa, mục sửa, lý do, artifact bị ảnh hưởng
UAT_CASE_CATALOG_NF_ERP	UAT Test Case Catalog	/03-templates/UAT_TEST_CASE_CATALOG.md	BA; QA Lead rà soát chất lượng test	IN_REVIEW	Test case ID, precondition, dữ liệu, bước chạy, expected result, nguồn truy vết, bằng chứng cần thu	Mỗi sửa expected result phải nêu rule hoặc requirement nguồn; không sửa im lặng
UAT_EXECUTION_LOG_NF_ERP	UAT Execution Log	/03-templates/UAT_EXECUTION_LOG.md	UAT Tester	IN_REVIEW	Test run ID, test case ID, người chạy, thời điểm Asia/Ho_Chi_Minh, actual result, Pass/Fail/Blocked, link bằng chứng	Không ghi đè kết quả cũ; tạo dòng chạy mới khi chạy lại
DEFECT_LOG_NF_ERP	Defect Log	/03-templates/DEFECT_LOG.md	QA Lead	IN_REVIEW	Defect ID, tiêu đề, bước tái hiện, expected result, actual result, severity, priority, ảnh hưởng, bằng chứng, owner xử lý	Mỗi đổi trạng thái, severity, priority hoặc phạm vi phải có ngày, người đổi, lý do
REGRESSION_SCOPE_NF_ERP	Regression Scope	/03-templates/REGRESSION_SCOPE.md	BA; QA Lead xác định kiểm thử	IN_REVIEW	Thay đổi nguồn, thành phần bị ảnh hưởng, test case chạy lại, rủi ro không chạy lại, dependency	Mỗi mục thêm hoặc bỏ phải chỉ rõ defect, change request hoặc dependency làm bằng chứng

Canonical ID tồn tại để một dòng UAT tham chiếu đúng artifact. Ví dụ UAT-EXEC-001 phải liên kết UAT-TC-001, không liên kết bằng tên tự do như “test tồn kho”. Tên tự do gây đứt traceability vì hai người có thể hiểu khác nhau.

Applied

Thành phần	Nova Foods mô phỏng, dữ liệu tổng hợp
Facts	UAT kiểm tra đơn bán SO-SIM-00018 có mặt hàng RM-SIM-001 với tồn khả dụng 10 kg. Người dùng nhập số lượng 12 kg.
Current Behavior	Hệ thống mô phỏng vẫn cho lưu đơn với số lượng 12 kg.
Underlying Need	Kết quả UAT phải phân biệt lỗi phần mềm với rule nghiệp vụ chưa được xác nhận.
Options	Ghi Pass; ghi Fail; ghi Blocked.
Decision Criteria	Expected result có nguồn truy vết thì so sánh actual result để chọn Pass hoặc Fail. Không có nguồn thì không suy đoán rule.
Decision	Ghi Blocked trong UAT_EXECUTION_LOG_NF_ERP; tạo điểm cần xác nhận cho Business Owner.
Authority	BA duy trì traceability; UAT Tester ghi kết quả chạy; Business Owner xác nhận rule nghiệp vụ; QA Lead quản lý defect nếu có nguồn xác định Fail.
Artifact	UAT-EXEC-001 tham chiếu UAT-TC-001, SO-SIM-00018, RM-SIM-001; REG-001 ghi rủi ro regression nếu rule tồn kho được xác nhận sau này.
Consequence if Wrong	Ghi Fail khi rule chưa có nguồn biến giả định của BA thành quyết định nghiệp vụ. Ghi Pass che giấu hành vi cần xác minh.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[BA: duy trì traceability cho UAT-TC-001 và expected result] --> B[UAT Tester: UAT-EXEC-001 ghi actual result]
    B --> C{Expected result có nguồn truy vết?}
    C -->|Có, khớp actual| D[UAT Tester: UAT_EXECUTION_LOG_NF_ERP ghi Pass]
    C -->|Có, khác actual| E[UAT Tester: UAT_EXECUTION_LOG_NF_ERP ghi Fail]
    E --> F[QA Lead: quản lý DEFECT_LOG_NF_ERP]
    C -->|Không có nguồn| G[UAT Tester: UAT_EXECUTION_LOG_NF_ERP ghi Blocked]
    G --> H[Business Owner: xác nhận rule nghiệp vụ]
    H --> I[BA: cập nhật nguồn expected result]
    I --> J{Actual khớp rule đã xác nhận?}
    J -->|Có| D
    J -->|Không| E
    H --> K{Rule tồn kho được xác nhận?}
    K -->|Có| L[REG-001: ghi rủi ro regression]

Senior Lens

Owner giữ artifact, không tự có quyền quyết định nội dung ngoài thẩm quyền. BA sở hữu tính đầy đủ của kế hoạch và liên kết nguồn; QA Lead sở hữu quản lý defect; UAT Tester sở hữu tính trung thực của kết quả chạy; Business Owner sở hữu xác nhận rule nghiệp vụ. Tách quyền này ngăn một người vừa tạo expected result, vừa tự xác nhận kết quả, vừa đóng vấn đề.

Mỗi artifact dùng IN_REVIEW, version v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Không dùng APPROVED, BASELINED, production-ready hoặc cụm từ hàm ý đã được người dùng chấp thuận khi chưa có tham chiếu kiểm soát ghi nhận.

Quick Reference

Quy tắc	Áp dụng
Một ID, một đối tượng	Không tái dùng ID defect, test case, test run hoặc regression item.
Một thay đổi, một dòng lịch sử	Ghi ai sửa, sửa gì, vì sao, khi nào.
Không có nguồn, không kết luận rule	Dùng Blocked, route tới thẩm quyền phù hợp.
Actual result không thay expected result	Giữ cả hai để reviewer kiểm tra chênh lệch.
Artifact mô phỏng không thành quyết định thật	Nova Foods và dữ liệu đều tổng hợp, chỉ phục vụ học liệu.

Core

Đầu ra UAT phải biến hoạt động kiểm thử chấp nhận người dùng thành vật chứng có thể đọc lại. UAT (User Acceptance Testing) kiểm tra hệ thống có đáp ứng nhu cầu sử dụng đã mô tả hay không; không tự xác nhận triển khai production. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Test case UAT đã chạy] --> B[UAT execution record]
    B --> C{Kết quả UAT}
    C -->|Pass| D[Pass ghi trong UAT execution record]
    C -->|Blocked| E[Blocked ghi trong UAT execution record]
    C -->|Fail| F[Tạo mới hoặc cập nhật]
    F --> G[Defect record]
    G --> P[Defect status history]

    X[Thay đổi cần đánh giá regression] --> H{Có chạy regression?}
    H -->|Không| N[Không chạy regression]
    H -->|Có| I[Chạy regression]
    G -.->|Defect ID khi có| I
    I --> J[Regression result]
    J --> K{Kết quả regression}
    K -->|Pass| L[Pass ghi trong Regression result]
    K -->|Blocked| M[Blocked ghi trong Regression result]
    K -->|Fail| Q[Tạo mới hoặc cập nhật]
    Q --> G

    B -.->|tham chiếu evidence| O[Evidence reference]
    G -.->|tham chiếu evidence| O
    J -.->|tham chiếu evidence| O

Thành phần anatomy	UAT execution record	Defect record	Regression result
Mục đích	Ghi lần chạy một test case và kết quả quan sát.	Ghi sai lệch giữa kết quả mong đợi và kết quả thực tế.	Ghi lần chạy lại test liên quan sau thay đổi.
Định danh liên kết	Test case ID, requirement/rule ID, execution ID.	Defect ID, execution ID, test case ID.	Regression run ID, test case ID, defect ID khi có.
Bối cảnh chạy	Môi trường mô phỏng, dữ liệu tổng hợp, người chạy, thời điểm Asia/Ho_Chi_Minh.	Môi trường, bản build hoặc cấu hình được quan sát, dữ liệu tái hiện.	Môi trường, phạm vi test chạy lại, thay đổi kích hoạt regression.
Kết quả cần ghi	Expected result, actual result, Pass/Fail/Blocked, evidence reference.	Steps to reproduce, expected result, actual result, severity, business impact, evidence reference.	Expected result, actual result, Pass/Fail/Blocked, evidence reference, liên kết defect.
Liên kết truy vết	Không tự tạo requirement mới; tham chiếu artifact nguồn.	Không thay quy tắc nghiệp vụ; chỉ nêu sai lệch cần xem xét.	Không tự đóng defect; chỉ cung cấp kết quả chạy lại.

Applied

Facts: Nova Foods là case mô phỏng giáo dục. Luồng cần kiểm tra: nhân viên kho xác nhận xuất 120 thùng sản phẩm tổng hợp NF-MILK-01 cho đơn bán mô phỏng SO-SIM-260807-001.

Current Behavior: Trong lần chạy UAT-EXE-SIM-001, hệ thống mô phỏng giảm tồn kho từ 500 xuống 400 thùng dù số lượng xuất là 120 thùng.

Underlying Need: Người dùng cần ghi nhận chênh lệch đủ rõ để QA reviewer và Business Owner xem xét mà không phải đoán dữ liệu, thao tác hay kết quả.

Output mô phỏng	ID làm việc mô phỏng	Nội dung đã điền đầy đủ
UAT execution record	UAT-EXE-SIM-001	Test case: UAT-TC-SIM-001; dữ liệu: SO-SIM-260807-001, NF-MILK-01, tồn trước xuất 500 thùng, lượng xuất 120 thùng; expected result: tồn sau xuất 380 thùng; actual result: tồn sau xuất 400 thùng; kết quả: FAIL; evidence: ảnh chụp màn hình mô phỏng EVD-SIM-001; thời điểm: 2026-08-07 10:15 Asia/Ho_Chi_Minh.
Defect record	DEF-SIM-001	Nguồn: UAT-EXE-SIM-001; bước tái hiện: tạo đơn SO-SIM-260807-001, xác nhận xuất 120 thùng NF-MILK-01, mở tồn kho; expected result: 380 thùng; actual result: 400 thùng; sai lệch: thiếu giảm 20 thùng; severity đề xuất: High, vì tồn kho hiển thị sai có thể làm sai quyết định cấp hàng; evidence: EVD-SIM-001; trạng thái ghi nhận: IN_REVIEW.
Regression result	REG-SIM-001	Kích hoạt: thay đổi được báo cáo liên quan DEF-SIM-001; test case chạy lại: UAT-TC-SIM-001; dữ liệu: tồn trước xuất 500 thùng, xuất 120 thùng; expected result: 380 thùng; actual result: 380 thùng; kết quả: PASS; evidence: EVD-SIM-002; thời điểm: 2026-08-07 15:40 Asia/Ho_Chi_Minh; defect vẫn tham chiếu DEF-SIM-001, không suy ra trạng thái đóng.

Options: (1) chỉ ghi “tồn kho sai”; (2) ghi đủ số liệu trước/sau, thao tác, expected result, actual result và evidence reference.

Decision Criteria: Reviewer phải tái hiện được lỗi; chênh lệch phải đo được; mỗi kết quả phải liên kết test case; không dùng dữ liệu thật; không suy diễn phê duyệt.

Decision: Chọn phương án 2. Bằng chứng: số 500, 120, 380 và 400 cho phép xác định sai lệch 20 thùng; câu “tồn kho sai” không đủ tái hiện hoặc đánh giá ảnh hưởng.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì cấu trúc học liệu. Severity, quyết định sửa, đóng defect, baseline và production thuộc vai trò thẩm quyền phù hợp; chưa có xác nhận nào trong ví dụ.

Artifact: Các ID UAT-EXE-SIM-001, DEF-SIM-001, REG-SIM-001, EVD-SIM-001, EVD-SIM-002 chỉ là mã minh họa dữ liệu tổng hợp trong section này. Nguồn quản trị canonical hiện có: TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.

Consequence if Wrong: Thiếu expected result làm reviewer không biết hệ thống sai hay tester hiểu sai. Thiếu actual result và evidence làm lỗi không tái hiện được. Gắn PASS cho regression rồi tự đóng defect làm sai ranh giới thẩm quyền.

Senior Lens

Output tốt ghi sự kiện quan sát được, không ghi kết luận chưa có thẩm quyền. “Tồn sau xuất là 400, expected là 380” là quan sát kiểm chứng được. “Hệ thống vi phạm quy định kế toán” là kết luận chuyên môn, cần Accounting Owner hoặc Legal Owner xác minh. Với dữ liệu thực phẩm, truy xuất lô và recall cần domain-owner cùng legal verification; ví dụ này không tạo nghĩa vụ pháp lý hay quy tắc vận hành Nova Foods.

Quick Reference

Kiểm tra completeness	Đạt khi
Số liệu	Có dữ liệu trước thao tác, dữ liệu thao tác, expected result, actual result.
Tái hiện	Có bước thao tác, môi trường và evidence reference.
Truy vết	Execution liên kết test case; defect liên kết execution; regression liên kết test case và defect khi phát sinh từ defect.
Ranh giới	Ghi IN_REVIEW; không ghi approved, baselined, production-ready hoặc đã đóng nếu không có bằng chứng thẩm quyền.

Core

Quality gate là cổng kiểm tra chất lượng trước khi artifact được chuyển sang downstream review, nghĩa là xem xét bởi vai trò kế tiếp. Gate chỉ xác nhận artifact đủ thông tin để review; không xác nhận APPROVED, BASELINED, compliant, production-ready hoặc được người dùng chấp thuận.

Mỗi output UAT phải đạt toàn bộ điều kiện sau trước khi được gắn Ready for downstream review:

Điều kiện gate	Bằng chứng bắt buộc	Lý do
Định danh giữ nguyên	Canonical ID, tên tệp controlled, liên kết artifact nguồn không bị đổi	Reviewer cần truy ngược đúng nguồn chân lý.
Metadata đủ	Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh, vi-VN, VND khi có giá trị tiền	Metadata xác định ngữ cảnh review và ngăn diễn giải sai thành production.
Nội dung kiểm thử đủ dùng	Phạm vi, điều kiện vào, bước test, kết quả mong đợi, kết quả thực tế nếu đã chạy, bằng chứng hoặc vị trí bằng chứng	QA hoặc Business Reviewer cần kiểm tra được logic mà không tự đoán.
Traceability đủ	Liên kết tới requirement, business rule, data definition hoặc defect liên quan bằng ID canonical đã có	UAT output chỉ đáng tin khi biết nó kiểm tra điều gì.
Dữ liệu an toàn	Chỉ dữ liệu tổng hợp Nova Foods mô phỏng; không có dữ liệu cá nhân, khách hàng, nhà cung cấp hay vận hành thật	Corpus bị giới hạn dữ liệu synthetic.
Lịch sử thay đổi đủ	Dòng thay đổi ghi version, ngày, người ghi nhận, nội dung đổi, lý do đổi	Reviewer phân biệt nội dung hiện hành với nội dung cũ.
Ngoại lệ được lộ rõ	Mọi điểm chưa xác minh ghi Verification required hoặc project assumption	Không được biến giả định thành quy tắc, nghĩa vụ pháp lý hay kết luận nghiệp vụ.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[UAT output soạn xong] --> B{Canonical ID giữ nguyên,<br/>tên tệp controlled và liên kết artifact nguồn?}
    B -- Không --> C[Trả về sửa artifact]
    B -- Có --> D{Metadata đủ: IN_REVIEW, v0.9.0,<br/>ngày 2026-08-07, Asia/Ho_Chi_Minh,<br/>vi-VN, VND khi có tiền?}
    D -- Không --> C
    D -- Có --> E{Traceability đủ: liên kết bằng canonical ID<br/>tới requirement, business rule,<br/>data definition hoặc defect liên quan?}
    E -- Không --> C
    E -- Có --> F{Lịch sử thay đổi đủ: version, ngày,<br/>người ghi nhận, nội dung đổi<br/>và lý do đổi?}
    F -- Không --> C
    F -- Có --> G{Nội dung kiểm thử đủ dùng:<br/>phạm vi, điều kiện vào, bước test,<br/>kết quả mong đợi, kết quả thực tế nếu đã chạy,<br/>bằng chứng hoặc vị trí bằng chứng?}
    G -- Không --> C
    G -- Có --> H{Chỉ dùng dữ liệu tổng hợp Nova Foods;<br/>không có dữ liệu cá nhân, khách hàng,<br/>nhà cung cấp hoặc vận hành thật?}
    H -- Không --> C
    H -- Có --> I{Mọi điểm chưa xác minh mang nhãn<br/>Verification required hoặc project assumption?}
    I -- Không --> C
    I -- Có --> J[Ready for downstream review]
    J --> K[QA / Business Reviewer thực hiện downstream review]
    J -. Không xác nhận approval,<br/>baseline, compliance, production-ready<br/>hay chấp thuận người dùng .-> L[Giới hạn quality gate]

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; dữ liệu đều synthetic. Output được chuẩn bị để review gồm UAT test evidence và defect record cho luồng tạo đơn bán hàng ERP.

Current Behavior: Người viết có test case, ảnh chụp màn hình và mô tả lỗi, nhưng ảnh không ghi test case ID, defect không liên kết rule, lịch sử thay đổi trống. Artifact chưa qua gate vì reviewer không thể chứng minh lỗi thuộc yêu cầu nào.

Underlying Need: Downstream reviewer cần tái tạo kết luận: dữ liệu nào được dùng, bước nào đã chạy, kết quả nào lệch, và nội dung nào cần xác minh thêm.

Thành phần gate	Giá trị điền cho Nova Foods mô phỏng	Kết quả
Status	IN_REVIEW	Đúng trạng thái review, không phải approval.
Version	v0.9.0	Khớp frozen contract.
Ngày và múi giờ	2026-08-07, Asia/Ho_Chi_Minh	Có ngữ cảnh thời gian.
Locale và tiền tệ	vi-VN, VND	Phù hợp case study.
Dữ liệu test	Khách hàng CUST-SYN-001; đơn SO-SYN-001; giá trị 1250000 VND	Synthetic data.
Traceability	Liên kết đúng ID canonical trong artifact nguồn; nếu ID chưa được registry xác nhận, ghi Verification required	Không tự tạo ID.
Change history	v0.9.0 \| 2026-08-07 \| Principal IT Business Analyst / Technical Curriculum Author \| Khởi tạo bằng chứng UAT mô phỏng \| Phục vụ downstream review	Có lịch sử kiểm tra được.
Gate result	Ready for downstream review	Chỉ đủ điều kiện chuyển review.

Options: (1) Chuyển artifact thiếu traceability để reviewer tự tìm; (2) chặn chuyển review đến khi bổ sung liên kết nguồn; (3) gắn nhãn approved để bỏ qua thiếu sót. Option 2 được chọn vì evidence cho thấy thiếu liên kết làm reviewer phải suy diễn; option 3 vi phạm trạng thái IN_REVIEW.

Decision Criteria: Không đổi canonical ID; không dùng dữ liệu thật; reviewer kiểm tra được từ output về nguồn; không tạo tuyên bố ngoài thẩm quyền.

Decision: Chỉ chuyển downstream review khi tất cả hàng gate đạt. Điểm chưa xác minh giữ nhãn Verification required, không bị che bằng diễn giải.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì artifact và gate record. Vai trò này không có quyền phê duyệt business rule, legal/compliance sign-off, baseline hoặc production use.

Artifact: /02-handbook/20-uat-planning-defects-and-regression.md, status IN_REVIEW, version v0.9.0. Liên kết nguồn giữ đúng canonical filename và source classification từ artifact upstream.

Consequence if Wrong: Artifact thiếu evidence có thể khiến defect bị phân loại sai, regression kiểm tra nhầm phạm vi, hoặc giả định bị hiểu nhầm thành quy tắc Nova Foods thật.

Senior Lens

Gate tốt kiểm tra khả năng review, không kiểm tra đúng nghiệp vụ cuối cùng. Hai việc khác nhau: BA kiểm tra output có đủ cấu trúc, evidence và traceability; Business Owner, QA, Architect, Legal Owner hoặc Accounting Owner chỉ kết luận trong phạm vi thẩm quyền riêng khi có review phù hợp.

Không nâng trạng thái vì artifact “trông hoàn chỉnh”. Evidence phải khớp từng trường gate. Ví dụ, ảnh màn hình có thể chứng minh kết quả thực tế nhưng không thay thế test step; test step có thể chứng minh cách chạy nhưng không thay thế liên kết requirement; lịch sử thay đổi có thể chứng minh quản trị nhưng không thay thế đánh giá nghiệp vụ.

Quick Reference

Nhãn được phép sau gate	Ý nghĩa
Ready for downstream review	Đủ thông tin để vai trò kế tiếp review.
IN_REVIEW	Đang được xem xét có kiểm soát.
Verification required	Có điểm cần vai trò hoặc nguồn có thẩm quyền xác minh.

Nhãn không được suy ra từ gate	Lý do
APPROVED	Cần quyết định được ghi nhận từ thẩm quyền phù hợp.
BASELINED	Cần baseline reference minh bạch.
Production-ready	Cần kiểm soát delivery, vận hành, bảo mật và thẩm quyền riêng.

7. Who consumes those outputs?

Core

Đầu ra UAT gồm kế hoạch UAT, bộ test case, defect log, gói regression và ma trận traceability. Mỗi đầu ra là vật trung gian để vai trò khác làm việc tiếp, không phải bằng chứng phê duyệt. Nova Foods là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp.

Vai trò nhận	Đầu ra dùng	Cách dùng trong công việc	Ranh giới
Developer	Defect log, test case lỗi, regression pack	Tái hiện lỗi, sửa mã hoặc cấu hình mô phỏng, xác định vùng cần regression	Không tự đổi business rule từ mô tả lỗi
QA	UAT plan, test case, defect log, traceability	Kiểm tra phạm vi UAT, thiết kế hoặc chạy regression, đối chiếu lỗi với yêu cầu	Không tự xác nhận nhu cầu nghiệp vụ cuối cùng
Architect	Defect log liên quan tích hợp, traceability, regression pack	Đánh giá ảnh hưởng interface, dữ liệu, hiệu năng, quyền truy cập và kiến trúc	Không tự quyết định ưu tiên nghiệp vụ
PM/Product Owner	UAT plan, defect summary, traceability	Theo dõi phạm vi, rủi ro tiến độ, thứ tự xử lý và tác động release	Không thay Business Owner xác nhận quy tắc nghiệp vụ
Business Owner	Test case nghiệp vụ, kết quả UAT, defect log	Đối chiếu hành vi hệ thống với quy trình và kết quả nghiệp vụ mô phỏng	Không thay QA xác nhận đầy đủ kỹ thuật regression
Operations	UAT plan, test case vận hành, defect log	Chuẩn bị thao tác, dữ liệu mẫu, quyền mô phỏng và kiểm tra tính khả dụng vận hành	Không tự thay đổi kiến trúc hoặc rule
Specialist owner	Test case và defect thuộc chuyên môn	Review lĩnh vực như kế toán, an toàn thực phẩm, dữ liệu cá nhân hoặc kho vận	Kết luận chỉ trong phạm vi chuyên môn được giao

Applied

Facts: Nova Foods mô phỏng có test case UAT-TC-SO-014 tạo đơn bán hàng, defect DEF-SO-027 ghi nhận tổng tiền đơn hàng sai khi áp dụng mức chiết khấu dữ liệu tổng hợp.

Current Behavior: UAT tester nhập đơn SO-SIM-014, chiết khấu 5%, tổng tiền hiển thị không khớp phép tính trong test case. Defect log liên kết DEF-SO-027 với UAT-TC-SO-014.

Underlying Need: Developer cần tái hiện lỗi để sửa; QA cần biết chức năng nào phải regression; Business Owner cần hiểu lỗi có làm sai kết quả nghiệp vụ mô phỏng hay không; PM/Product Owner cần thấy tác động đến kế hoạch UAT.

Options:
1. Chỉ gửi ảnh màn hình lỗi cho Developer.
2. Gửi DEF-SO-027 kèm bước tái hiện, dữ liệu tổng hợp, kết quả mong đợi, kết quả thực tế và liên kết UAT-TC-SO-014.
3. Đóng defect vì tester đã ghi nhận lỗi.

Decision Criteria: Đầu ra phải cho phép vai trò nhận thực hiện phần việc của mình mà không tự suy đoán requirement, dữ liệu đầu vào hoặc phạm vi regression.

Decision: Dùng phương án 2. Developer dùng defect để sửa; QA lấy liên kết test case để xác định regression; PM/Product Owner dùng trạng thái defect để điều phối; Business Owner dùng kết quả mong đợi đã ghi trong test case để review tác động nghiệp vụ.

Authority: Đây là phân luồng tiêu thụ output trong tài liệu IN_REVIEW, không phải phê duyệt defect, quyết định release hoặc xác nhận quy tắc Nova Foods thật.

Artifact: /02-handbook/20-uat-planning-defects-and-regression.md, status IN_REVIEW, version v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh.

Consequence if Wrong: Developer có thể sửa sai vùng mã; QA có thể regression thiếu; Business Owner có thể nhận kết quả không phản ánh nhu cầu; PM/Product Owner có thể đánh giá sai rủi ro delivery.

Source mermaid — có thể chỉnh sửa

flowchart TB
    OUT["DEF-SO-027<br/>liên kết UAT-TC-SO-014"]
    DEV[Developer]
    QA[QA]
    PM[PM/Product Owner]
    BO[Business Owner]
    BOUNDARY["IN_REVIEW: phân luồng output<br/>Không phê duyệt defect, quyết định release<br/>hoặc xác nhận quy tắc Nova Foods thật"]

    OUT -->|"Bước tái hiện; dữ liệu tổng hợp;<br/>kết quả mong đợi; kết quả thực tế"| DEV
    OUT -->|"Liên kết UAT-TC-SO-014<br/>để xác định phạm vi regression"| QA
    OUT -->|"Trạng thái defect;<br/>tác động đến kế hoạch UAT"| PM
    OUT -->|"Kết quả mong đợi trong test case;<br/>sai lệch tổng tiền cần review"| BO

    OUT -.-> BOUNDARY

Senior Lens

Không gửi cùng một output với giả định mọi người dùng giống nhau. Developer cần dữ liệu tái hiện; QA cần test basis và phạm vi regression; Architect cần điểm chạm kỹ thuật; Business Owner cần hành vi nghiệp vụ. Cùng một DEF-SO-027 nhưng mỗi vai trò đọc trường khác vì quyết định tiếp theo khác nhau.

Traceability nối output với nguồn trước đó. Ví dụ, defect liên kết test case; test case liên kết requirement hoặc business rule; liên kết này giúp QA biết test nào chạy lại và giúp Business Owner biết hành vi nào bị ảnh hưởng. Liên kết không tự chứng minh requirement đúng hoặc defect đã được chấp thuận.

Quick Reference

Output	Consumer chính	Consumer phụ	Mục đích tiêu thụ
UAT plan	QA, PM/Product Owner, Operations	Business Owner	Điều phối phạm vi, lịch và điều kiện chạy UAT
Test case	QA, Business Owner, Operations	Developer, specialist owner	Kiểm tra hành vi mong đợi
Defect log	Developer, QA, PM/Product Owner	Architect, Business Owner	Sửa lỗi, theo dõi trạng thái, đánh giá tác động
Regression pack	QA, Developer	Architect	Kiểm tra vùng bị ảnh hưởng sau sửa
Traceability matrix	QA, PM/Product Owner	Architect, Business Owner	Nối requirement, test case, defect và phạm vi ảnh hưởng

Core

Đầu ra UAT gồm kế hoạch UAT, ca kiểm thử, nhật ký lỗi, bằng chứng kiểm thử và phạm vi hồi quy. Mỗi đầu ra chỉ hỗ trợ quyết định khi có liên kết từ yêu cầu, quy tắc nghiệp vụ, dữ liệu tổng hợp Nova Foods và kết quả thực thi. IN_REVIEW tại v0.9.0, ngày 2026-08-07, không phải phê duyệt, baseline hay quyền triển khai.

Người dùng đầu ra	Có thể quyết định	Bằng chứng cần xem	Phải escalation khi
Developer	Sửa mã, từ chối lỗi không tái hiện được, đánh giá tác động hồi quy kỹ thuật	Bước tái hiện, kết quả mong đợi, kết quả thực tế, ảnh/chứng cứ, môi trường, dữ liệu tổng hợp, liên kết yêu cầu	Kết quả mong đợi mâu thuẫn quy tắc nghiệp vụ; lỗi liên quan dữ liệu cá nhân, phân quyền, tích hợp hoặc thay đổi schema
QA	Phân loại lỗi, ưu tiên kiểm thử lại, chọn phạm vi hồi quy, kết luận ca kiểm thử Pass/Fail/Blocked	Test basis, acceptance criteria, nhật ký thực thi, bằng chứng Pass/Fail, version build, dữ liệu kiểm thử	Không có test basis; lỗi Blocker; tiêu chí chấp nhận mơ hồ; môi trường UAT không ổn định
Architect	Đánh giá tác động kiến trúc, tích hợp, hiệu năng, bảo mật; chấp nhận hoặc yêu cầu thiết kế lại kỹ thuật	Luồng tích hợp, hợp đồng API, log lỗi, sơ đồ thành phần, tác động dữ liệu và quyền truy cập	Thay đổi phá vỡ interface; rủi ro bảo mật; mất toàn vẹn dữ liệu; quyết định vượt phạm vi một module
PM/Product Owner	Sắp thứ tự sửa lỗi, cân bằng phạm vi, thời gian và rủi ro phát hành	Severity, business impact, phạm vi hồi quy, trạng thái Blocked, dependency release	Có tranh chấp ưu tiên; thay đổi phạm vi; rủi ro lịch phát hành; thiếu người có thẩm quyền quyết định
Business Owner	Xác nhận diễn giải nhu cầu nghiệp vụ và mức chấp nhận tác động nghiệp vụ	Yêu cầu nguồn, quy tắc nghiệp vụ, kịch bản UAT, dữ liệu tổng hợp, hậu quả vận hành nếu sai	Quy tắc ảnh hưởng giá bán, chiết khấu, phê duyệt, kế toán, thuế hoặc cam kết khách hàng
Operations	Đánh giá khả năng vận hành, hỗ trợ, xử lý sự cố và tính liên tục	Runbook, luồng ngoại lệ, quyền vận hành, cảnh báo, bằng chứng khôi phục dữ liệu	Không có cách xử lý lỗi vận hành; thiếu quyền; lỗi gây gián đoạn kho, giao hàng hoặc sản xuất mô phỏng
Specialist owner	Xác nhận chuyên môn miền như kế toán, pháp lý, an toàn thực phẩm, bảo mật hoặc dữ liệu	Quy tắc bị ảnh hưởng, nguồn chính thức, phân loại dữ liệu, tác động nghiệp vụ	Cần diễn giải luật, kế toán, thuế, an toàn thực phẩm hoặc kiểm soát dữ liệu cá nhân; BA không tự kết luận

Source mermaid — có thể chỉnh sửa

flowchart TD
    A["Đầu ra UAT IN_REVIEW v0.9.0 ngày 2026-08-07"] --> B["Trạng thái không tạo quyền phê duyệt, baseline hoặc triển khai"]
    B --> R{"Vai trò nhận đầu ra"}

    R --> DEV["Developer: quyết định sửa mã hoặc từ chối lỗi; xem bước tái hiện, kết quả mong đợi, kết quả thực tế, chứng cứ, môi trường, dữ liệu và yêu cầu"]
    R --> QA["QA: phân loại, kiểm thử lại, chọn hồi quy và kết luận Pass, Fail hoặc Blocked; xem test basis, tiêu chí chấp nhận, nhật ký, chứng cứ, build và dữ liệu"]
    R --> ARCH["Architect: đánh giá kiến trúc, tích hợp, hiệu năng và bảo mật; xem luồng tích hợp, hợp đồng API, log, thành phần, dữ liệu và quyền"]
    R --> PM["PM hoặc Product Owner: ưu tiên sửa lỗi và cân bằng phạm vi, thời gian, rủi ro; xem severity, tác động nghiệp vụ, hồi quy, Blocked và dependency release"]
    R --> BO["Business Owner: xác nhận nhu cầu và mức chấp nhận tác động; xem yêu cầu, quy tắc nghiệp vụ, kịch bản UAT, dữ liệu và hậu quả vận hành"]
    R --> OPS["Operations: đánh giá vận hành, hỗ trợ và liên tục; xem runbook, luồng ngoại lệ, quyền, cảnh báo và chứng cứ khôi phục"]
    R --> SPEC["Specialist owner: xác nhận chuyên môn; xem quy tắc, nguồn chính thức, phân loại dữ liệu và tác động nghiệp vụ"]

    DEV --> E{"Chứng cứ theo vai trò có đủ cho quyết định đang xét?"}
    QA --> E
    ARCH --> E
    PM --> E
    BO --> E
    OPS --> E
    SPEC --> E

    E -->|"Không"| ADD["Bổ sung chứng cứ, test basis và liên kết còn thiếu"]
    E -->|"Có"| G{"Quyết định còn trong thẩm quyền và không chạm ngưỡng escalation?"}

    G -->|"Có"| D["Vai trò nhận đầu ra quyết định trong thẩm quyền"]
    G -->|"Không"| T["Phân loại mọi lý do escalation áp dụng"]
    ADD --> T

    T --> BR["Quy tắc nghiệp vụ, giá, chiết khấu, phê duyệt hoặc cam kết khách hàng"]
    T --> AR["Kiến trúc, tích hợp, interface, schema hoặc toàn vẹn dữ liệu"]
    T --> SP["Bảo mật, dữ liệu cá nhân, pháp lý, kế toán, thuế hoặc an toàn thực phẩm"]
    T --> PR["Blocker, tranh chấp ưu tiên, thay đổi phạm vi hoặc rủi ro lịch phát hành"]
    T --> OP["Quyền vận hành, khôi phục hoặc gián đoạn vận hành"]
    T --> MI["Thiếu chứng cứ, test basis hoặc tiêu chí chấp nhận rõ ràng"]

    BR --> OBO["Business Owner kết luận phần nghiệp vụ"]
    AR --> OARCH["Architect kết luận phần kỹ thuật"]
    SP --> OSPEC["Specialist owner kết luận phần chuyên môn"]
    PR --> OPM["PM hoặc Product Owner kết luận ưu tiên, phạm vi và rủi ro phát hành"]
    OP --> OOPS["Operations kết luận khả năng vận hành"]
    MI --> WAIT["Blocked đến khi bổ sung đủ chứng cứ và xác định đúng owner"]

    OBO --> S["Tổng hợp kết luận, chứng cứ và phạm vi hồi quy"]
    OARCH --> S
    OSPEC --> S
    OPM --> S
    OOPS --> S
    WAIT --> S

    S --> G
    D --> N["Kết quả vẫn không tự tạo phê duyệt, baseline hoặc quyền triển khai"]

Applied

Facts: Nova Foods là case mô phỏng, dữ liệu tổng hợp. Ca UAT đặt đơn bán SO-NF-SYN-001 thất bại khi áp dụng chiết khấu; kết quả thực tế là tổng tiền âm -50.000 VND.

Current Behavior: QA ghi Fail, đính kèm bước tái hiện, ảnh kết quả, dữ liệu đầu vào tổng hợp và build đang kiểm thử. Developer có thể sửa công thức, nhưng không được tự quyết mức chiết khấu hợp lệ.

Underlying Need: Phân biệt lỗi tính toán với quy tắc nghiệp vụ chưa rõ. Số tiền âm là bằng chứng kết quả bất thường; nó chưa chứng minh quy tắc đúng phải là gì.

Options: Developer chặn tổng âm; QA đánh dấu Blocked chờ làm rõ; Business Owner xác định giới hạn chiết khấu; PM/Product Owner ưu tiên sửa sau khi có quyết định nghiệp vụ.

Decision Criteria: Chọn phương án chỉ khi có yêu cầu hoặc quy tắc nghiệp vụ truy vết được, tác động báo cáo/kế toán được đánh giá bởi owner phù hợp, và ca hồi quy bao phủ trường hợp biên.

Decision: QA giữ trạng thái Fail cho hành vi hiện tại và tạo escalation về quy tắc chiết khấu. Không đổi expected result bằng suy đoán.

Authority: Business Owner quyết định ý nghĩa nghiệp vụ; Accounting Owner phải xác minh nếu tổng tiền ảnh hưởng hạch toán; Developer quyết định cách sửa sau khi quy tắc được làm rõ.

Artifact: Ghi liên kết từ nhật ký lỗi tới ca UAT, bằng chứng thực thi, yêu cầu nguồn và phạm vi hồi quy trong /02-handbook/20-uat-planning-defects-and-regression.md.

Consequence if Wrong: Developer tự chặn giá trị âm có thể che giấu lỗi công thức hoặc tạo quy tắc không được phép. Báo cáo doanh thu mô phỏng và kiểm thử hồi quy sau đó dựa trên hành vi sai.

Senior Lens

Escalation không phải chuyển trách nhiệm. BA đóng gói vấn đề để người có thẩm quyền quyết định: điều gì quan sát được, nguồn nào mâu thuẫn, lựa chọn nào tồn tại, tác động nào chưa xác minh. Không gắn nhãn compliance, hợp lệ kế toán hay hợp lệ pháp lý nếu chưa có specialist owner xác minh.

Quick Reference

Hiểu nhầm bàn giao	Câu hỏi làm rõ chính xác
“QA đã Fail nên Developer phải sửa theo cách QA đề xuất.”	“Expected result này truy vết tới yêu cầu hoặc quy tắc nghiệp vụ nào?”
“Lỗi nhỏ nên không cần hồi quy.”	“Thành phần, luồng dữ liệu và ca kiểm thử nào dùng cùng công thức hoặc interface đã sửa?”
“PM/Product Owner quyết định mọi thứ.”	“Quyết định này có ảnh hưởng diễn giải kế toán, pháp lý, bảo mật hoặc vận hành cần owner chuyên môn không?”
“Bằng chứng ảnh chụp là đủ.”	“Có bước tái hiện, dữ liệu tổng hợp, build, môi trường và kết quả mong đợi để tái hiện độc lập không?”

Core

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Handoff là bàn giao đầu ra giữa vai trò. Hiểu lầm xảy ra khi bên nhận biến giả định, câu mô tả, hoặc kết quả test thành quyết định đã được xác nhận. Bằng chứng nối suy luận phải còn nguyên: nguồn canonical, ID truy vết, phiên bản, trạng thái IN_REVIEW, người có thẩm quyền, và câu hỏi chưa đóng. IN_REVIEW tại v0.9.0 ngày 2026-08-07 không là baseline, không là approval.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[BA bàn giao artifact<br/>IN_REVIEW v0.9.0 · 2026-08-07<br/>Không là baseline hoặc approval]
    A --> B{Đủ bằng chứng handoff?<br/>Nguồn canonical · ID truy vết · phiên bản · trạng thái · người có thẩm quyền · câu hỏi chưa đóng}
    B -->|Không hoặc mâu thuẫn| C[Hỏi làm rõ bằng câu hỏi cụ thể]
    B -->|Đủ| D{Bên nhận hiểu phạm vi artifact?}
    D -->|Không| C
    D -->|Có| E{Câu hỏi chưa đóng<br/>có ảnh hưởng phạm vi?}
    E -->|Không| F[Thực hiện phần việc<br/>theo artifact IN_REVIEW]
    F --> G[Kết quả không là baseline,<br/>approval, hoặc quyết định đã xác nhận]
    E -->|Có| C
    C --> H[BA ghi nhận câu hỏi, câu trả lời<br/>và bằng chứng cập nhật trong traceability]
    H --> I{Cần người có thẩm quyền<br/>xác nhận?}
    I -->|Có| J[Escalate tới người có thẩm quyền]
    J --> K[Người có thẩm quyền xử lý<br/>câu hỏi chưa đóng]
    K --> L[Ghi nhận quyết định, trạng thái<br/>và bằng chứng trong traceability]
    I -->|Không| M[Cập nhật artifact khi cần<br/>phiên bản, trạng thái và traceability]
    L --> M
    M --> N[BA bàn giao lại artifact<br/>với bằng chứng cập nhật]
    N --> B

Applied

Trường	Nội dung
Facts	QA nhận test case dùng mã lô tổng hợp LOT-SYN-260807-01. Developer hiểu đây là format ERP bắt buộc. Artifact nguồn còn IN_REVIEW; không có baseline reference hoặc approval reference.
Current Behavior	Developer chuẩn bị hard-code format mã lô. QA chuẩn bị kiểm tra theo format đó.
Underlying Need	Phân biệt dữ liệu test minh họa với business rule có thẩm quyền. Evidence: trạng thái artifact chỉ là IN_REVIEW; dữ liệu Nova Foods là synthetic. Suy ra format chưa đủ căn cứ thành rule triển khai.
Options	Giữ format như test data; tạo rule mới; hỏi Business Owner và specialist owner để xác nhận nghiệp vụ.
Decision Criteria	Có BR- canonical đã được ghi nhận; có nguồn nghiệp vụ; có owner đúng thẩm quyền; có trạng thái và quyết định truy vết được.
Decision	Không hard-code. Gắn LOT-SYN-260807-01 là dữ liệu test tổng hợp, chờ làm rõ rule.
Authority	Business Owner quyết định nhu cầu nghiệp vụ; specialist owner xác nhận truy xuất lô; Architect đánh giá tác động thiết kế. BA không tự chuyển ví dụ thành rule.
Artifact	Ghi câu hỏi trong defect hoặc clarification log, liên kết /01-curriculum/CANONICAL_BUSINESS_RULES.md, TRACEABILITY_ID_REGISTRY, và artifact test đang dùng.
Consequence if Wrong	Hệ thống khóa format sai; dữ liệu vận hành sau này không nhập được; regression test xác nhận sai hành vi; chi phí sửa tăng vì rule bị nhúng vào code và test.

Senior Lens

Hiểu lầm bàn giao	Dấu hiệu	Câu hỏi làm rõ chính xác	Escalate khi
“Passed” nghĩa là sẵn sàng phát hành	QA gửi kết quả pass nhưng phạm vi regression không ghi rõ	“Kết quả Passed này bao phủ test case nào, môi trường nào, dữ liệu tổng hợp nào, và còn defect mở nào?”	Kết quả bị dùng làm quyết định release hoặc chấp nhận rủi ro.
Defect là lỗi code	Defect chỉ có ảnh màn hình, không có expected behavior	“Expected behavior được suy ra từ artifact canonical nào, ID nào, phiên bản nào, và trạng thái nguồn là gì?”	Expected behavior mâu thuẫn rule, acceptance criteria, hoặc data dictionary.
API field tồn tại nghĩa là được phép dùng	Developer thấy field trong OpenAPI nhưng không rõ ownership	“Field này có mục đích nghiệp vụ nào, ai là data owner, giá trị rỗng có hợp lệ không, và consumer nào phụ thuộc?”	Field liên quan dữ liệu cá nhân, bảo mật, tích hợp, hoặc thay đổi contract API.
Quy tắc test là quy tắc nghiệp vụ	QA dùng giá trị test cố định làm điều kiện bắt buộc	“Giá trị này là test data, project assumption, hay business rule? Nếu là rule, tham chiếu canonical là gì?”	Không có nguồn canonical hoặc cần Business Owner xác nhận.
Architect đã “đồng ý” vì có mặt họp	Biên bản không ghi quyết định, phạm vi, hoặc owner	“Có decision record nào nêu phương án, tác động, người quyết định và trạng thái không?”	Quyết định ảnh hưởng kiến trúc, bảo mật, tích hợp, hiệu năng, hoặc dữ liệu.
Operations sẽ tự xử lý ngoại lệ	UAT nêu “xử lý thủ công” nhưng không có quy trình	“Ai thực hiện, trong thời hạn nào, dùng màn hình hay báo cáo nào, và bằng chứng hoàn tất được lưu ở đâu?”	Ngoại lệ gây mất dữ liệu, sai tồn kho, sai sổ sách, hoặc rủi ro truy xuất thực phẩm.

Quick Reference

Dùng câu hỏi theo thứ tự: đầu ra nào, nguồn nào, trạng thái nào, ai quyết định, hậu quả nào nếu hiểu sai. Không hỏi “có ổn không?” vì câu đó không tạo bằng chứng kiểm tra được.

• “Đây là requirement, project assumption, test data, hay defect observation?”
• “Nguồn canonical và ID truy vết của expected behavior là gì?”
• “IN_REVIEW có giới hạn sử dụng nào trong handoff này?”
• “Ai có thẩm quyền quyết định khi hai artifact mâu thuẫn?”
• “Nếu chưa có quyết định, developer và QA phải dừng phần nào, tiếp tục phần nào?”
• “Cần escalation đến Business Owner, Architect, Operations hay specialist owner; lý do thuộc phạm vi nào?”

8. Detailed Worked Example

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Trạng thái corpus: IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Case này chưa là quyết định vận hành, baseline, approval, cấu hình ERP thật, hay kết luận pháp lý.

Kịch bản: nhân viên kho tạo phiếu xuất bán cho khách hàng, hệ thống ERP phải giữ truy xuất lô hàng thực phẩm. UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) kiểm tra hành vi hiện có khi tồn kho cùng mã hàng nhưng khác lô.

Thành phần	Giá trị mô phỏng	Phân loại nguồn
Scenario ID	UAT-SCN-NF-001	Định danh kịch bản học liệu
Defect observation ID	DEF-NF-001	Quan sát lỗi mô phỏng
Sales order	SO-NF-260807-001	Test data
Delivery order	DO-NF-260807-001	Test data
Customer	CUS-NF-001 — Siêu thị Bình Minh	Test data
Warehouse	WH-HCM-01 — Kho thành phẩm TP.HCM	Project assumption
Item	FG-SAUCE-500 — Nước chấm Nova 500 ml	Test data
Đơn vị tính	CHAI	Test data
Số lượng yêu cầu	120 CHAI	Test data
Người tạo phiếu	UAT.WH01	Test account mô phỏng
Thời điểm thao tác	2026-08-07 09:15:00 Asia/Ho_Chi_Minh	Test execution data

Facts (sự kiện quan sát được): tồn kho khả dụng của FG-SAUCE-500 tại WH-HCM-01 là 150 CHAI, nhưng nằm trong hai lô riêng. Tổng tồn kho đủ cho đơn 120 CHAI; dữ liệu lô không thể bị thay bằng tổng số lượng vì mỗi lô có ngày hết hạn khác nhau.

Lot ID	Item ID	Tồn khả dụng	Ngày sản xuất	Ngày hết hạn	Trạng thái kho
LOT-NF-250701-A	FG-SAUCE-500	80 CHAI	2026-07-01	2027-07-01	AVAILABLE
LOT-NF-250715-B	FG-SAUCE-500	70 CHAI	2026-07-15	2027-07-15	AVAILABLE

Payload nhập mô phỏng từ màn hình tạo phiếu xuất chỉ chứa mã hàng và số lượng. Nó không chứa lotId; đây là bằng chứng trực tiếp rằng người dùng không thể chỉ định lô tại bước nhập.

{
  "deliveryOrderId": "DO-NF-260807-001",
  "salesOrderId": "SO-NF-260807-001",
  "warehouseId": "WH-HCM-01",
  "customerId": "CUS-NF-001",
  "lines": [
    {
      "itemId": "FG-SAUCE-500",
      "quantity": 120,
      "uom": "CHAI"
    }
  ]
}

Current Behavior (hành vi hiện tại): sau khi UAT.WH01 bấm xác nhận xuất, ERP tự ghi 120 CHAI vào lô có lotId thấp nhất là LOT-NF-250701-A. Hệ thống vẫn chuyển DO-NF-260807-001 sang POSTED dù lô này chỉ có 80 CHAI. Màn hình không báo thiếu 40 CHAI, không tách dòng sang LOT-NF-250715-B, và không tạo bản ghi phân bổ lô thứ hai.

Bước	Thao tác hoặc trạng thái quan sát	Bằng chứng	Kết quả
1	Nhập 120 CHAI cho FG-SAUCE-500	Payload có một dòng hàng	Hợp lệ ở mức tổng tồn
2	Hệ thống kiểm tra tổng tồn 150 CHAI	80 + 70 = 150	Cho phép tiếp tục
3	Hệ thống chọn lô đầu tiên	Dòng xuất ghi LOT-NF-250701-A	Không xét giới hạn 80 CHAI của lô
4	Xác nhận xuất	DO-NF-260807-001 có trạng thái POSTED	Ghi xuất 120 CHAI từ một lô
5	Đối chiếu tồn lô	80 - 120 = -40 CHAI	Tồn lô âm, thiếu truy vết 40 CHAI

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[UAT.WH01 nhập FG-SAUCE-500: 120 CHAI]
    A --> B[Payload không có lotId]
    B --> C[Người dùng không thể chọn lô]
    C --> D[ERP tính tổng tồn: 150 CHAI]
    D --> E{Tổng tồn đủ?}
    E -- Có, quan sát được --> F[ERP tự chọn LOT-NF-250701-A<br/>Tồn lô: 80 CHAI]
    E -- Không, chưa kiểm chứng --> X[Hành vi chưa kiểm chứng]
    F --> G[Không kiểm tra tồn đủ theo lô đã chọn]
    G --> H[ERP ghi xuất 120 CHAI từ LOT-NF-250701-A]
    H --> I[DO-NF-260807-001: POSTED]
    I --> J[Tồn LOT-NF-250701-A:<br/>80 - 120 = -40 CHAI]
    I --> K[Không báo thiếu 40 CHAI]
    I --> L[Không tách 40 CHAI sang LOT-NF-250715-B]
    I --> M[Không có bản ghi phân bổ lô thứ hai]
    J --> N[40 CHAI thiếu truy xuất lô]
    M --> N

Ranh giới kết luận hiện tại: DEF-NF-001 mới là defect observation, không tự chứng minh quy tắc phân bổ lô mong muốn. Bằng chứng chỉ cho thấy hệ thống kiểm tra tổng tồn nhưng không kiểm tra đủ tồn theo lô đã chọn. Nhu cầu nền, phương án, tiêu chí quyết định, quyết định có thẩm quyền, artifact đầu ra và hậu quả nếu quyết định sai thuộc các phần tiếp theo.

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing dùng dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Case kiểm tra UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) xử lý đơn bán hàng có lô sản phẩm bị giữ chất lượng.

Bước quyết định	Nội dung hoàn chỉnh	Bằng chứng và cầu nối suy luận
Facts	Đơn SO-NF-20260807-001 có dòng hàng SKU-NF-SUA-01, số lượng 120 thùng, đơn giá 185.000 VND, kho WH-HCM-01. Lô LOT-NF-260801-A còn 120 thùng nhưng trạng thái chất lượng là QUALITY_HOLD. Người dùng bán hàng USR-SALES-001 tạo đơn lúc 2026-08-07T09:15:00+07:00.	Tồn kho vật lý có đủ số lượng, nhưng trạng thái lô không cho biết lô được phép giao. BA không được suy diễn rằng “có tồn” đồng nghĩa “được bán”.
Current Behavior	ERP hiện cho phép xác nhận đơn và tự giữ toàn bộ 120 thùng từ LOT-NF-260801-A dù lô là QUALITY_HOLD. Kho chỉ thấy cảnh báo khi tạo phiếu xuất.	Luồng kiểm thử cho thấy kiểm soát diễn ra sau khi đơn đã được xác nhận. Khi đó Sales đã cam kết giao hàng, còn Warehouse phải chặn thực hiện.
Underlying Need	Hệ thống phải chặn cam kết hàng từ lô không được phép xuất ngay lúc xác nhận đơn; vẫn cho phép lưu đơn nháp để Sales theo dõi nhu cầu khách.	Cần tách “ghi nhận nhu cầu” khỏi “cam kết giao”. Chặn ở xác nhận giảm đơn hứa sai; vẫn lưu nháp tránh mất dữ liệu nhập.
Options	O1: chỉ hiện cảnh báo, vẫn cho xác nhận. O2: chặn xác nhận nếu bất kỳ phân bổ lô nào có trạng thái khác RELEASED. O3: tự đổi lô sang lô khác đủ hàng và RELEASED.	O1 không ngăn cam kết sai. O3 thay đổi phân bổ hàng mà chưa có quy tắc ưu tiên lô và quyền thay thế được xác nhận. O2 kiểm soát đúng điểm tạo cam kết, ít giả định nhất.
Decision Criteria	C1 ngăn xác nhận đơn dùng lô không xuất được; C2 không xóa đơn nháp; C3 không tự thay thế lô; C4 trả lỗi đủ để người dùng sửa; C5 không diễn giải đây là yêu cầu pháp lý hay xác nhận tuân thủ.	Tiêu chí bám rủi ro nghiệp vụ quan sát được. Không thêm logic phân bổ tự động khi chưa có nguồn rule canonical đã được xác nhận.
Decision	Khuyến nghị BA: chọn O2. Khi người dùng bấm xác nhận, ERP kiểm tra mọi lô đã phân bổ. Có ít nhất một lô có quality_status != RELEASED thì đơn giữ DRAFT, không tạo cam kết tồn kho, trả lỗi ERR-LOT-NOT-RELEASED.	O2 đạt C1 đến C5. Đây là khuyến nghị trong artifact IN_REVIEW, không phải quyết định đã được phê duyệt hoặc baseline.
Authority	Business Owner xác nhận tác động quy trình bán hàng; Quality Owner xác nhận tập trạng thái lô được phép xuất; Solution Architect xác nhận điểm kiểm tra và hành vi API; QA Lead xác nhận test basis. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận truy vết.	Quyền chọn trạng thái chất lượng và quyền thay đổi hành vi ERP không thuộc BA curriculum owner. Tại v0.9.0, chưa có approval reference.
Artifact	Ghi case vào /02-handbook/20-uat-planning-defects-and-regression.md, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07. Test payload và expected result bên dưới là dữ liệu kiểm thử tổng hợp.	Artifact tạo bằng chứng tái lập được cho UAT và defect triage, nhưng không tạo production rule.
Consequence if Wrong	Nếu chọn O1, Sales có thể cam kết hàng đang bị giữ chất lượng. Nếu chọn O3, hệ thống có thể đổi sang lô khác trái ưu tiên kho hoặc cam kết khách. Nếu chặn cả lưu nháp, người dùng mất khả năng ghi nhận nhu cầu.	Mỗi lỗi sai đến từ đặt kiểm soát quá muộn, tự động hóa vượt thẩm quyền, hoặc chặn dữ liệu không cần chặn.

Quy tắc kiểm thử được đề xuất, chưa được ủy quyền:

IF sales_order.action = CONFIRM
AND EXISTS allocation WHERE allocation.quality_status != RELEASED
THEN sales_order.status = DRAFT
AND inventory_commitment = 0
AND error_code = ERR-LOT-NOT-RELEASED

Payload UAT tổng hợp:

{
  "sales_order_id": "SO-NF-20260807-001",
  "action": "CONFIRM",
  "warehouse_id": "WH-HCM-01",
  "lines": [
    {
      "line_no": 1,
      "item_id": "SKU-NF-SUA-01",
      "quantity": 120,
      "uom": "THUNG",
      "unit_price_vnd": 185000,
      "allocations": [
        {
          "lot_id": "LOT-NF-260801-A",
          "quantity": 120,
          "quality_status": "QUALITY_HOLD"
        }
      ]
    }
  ]
}

Kết quả mong đợi:

{
  "sales_order_id": "SO-NF-20260807-001",
  "status": "DRAFT",
  "inventory_commitment": 0,
  "error": {
    "code": "ERR-LOT-NOT-RELEASED",
    "message": "Không thể xác nhận đơn: lô LOT-NF-260801-A chưa ở trạng thái RELEASED."
  }
}

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Sales tạo đơn nháp] --> B[Phân bổ lô LOT-NF-260801-A]
    B --> C[Người dùng bấm xác nhận đơn]
    C --> D{Mọi lô đã phân bổ có<br/>quality_status = RELEASED?}
    D -- Có --> E[Xác nhận đơn<br/>Tạo cam kết tồn kho]
    D -- Không --> F[Giữ đơn DRAFT<br/>Không tạo cam kết tồn kho<br/>Trả ERR-LOT-NOT-RELEASED]

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp, tiền tệ VND, thời gian Asia/Ho_Chi_Minh. Phạm vi UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) kiểm tra luồng giữ đơn bán khi khách vượt hạn mức tín dụng.

Loại	ID	Giá trị đầy đủ	Nguồn/phân loại
Khách hàng	CUS-NF-00128	Công ty TNHH Thực phẩm An Phú, hạn mức tín dụng 500000000 VND	Dữ liệu mô phỏng
Đơn bán	SO-NF-20260807-0042	Ngày đơn 2026-08-07; tổng phải thu mới 180000000 VND	Dữ liệu mô phỏng
Công nợ mở	AR-NF-20260731-0091	Công nợ chưa thanh toán 380000000 VND	Dữ liệu mô phỏng
Người dùng UAT	USR-NF-UAT-SALES-01	sales.uat01@novasim.example; vai trò Sales Order Clerk	Dữ liệu mô phỏng
Người duyệt tín dụng	USR-NF-UAT-CREDIT-01	credit.uat01@novasim.example; vai trò Credit Controller	Dữ liệu mô phỏng
Kịch bản UAT	UAT-SC-CR-001	Tạo đơn làm tổng phơi nhiễm vượt hạn mức; hệ thống phải giữ đơn	Artifact UAT dự kiến
Defect	DEF-NF-UAT-001	Đơn vượt hạn mức nhưng vẫn xác nhận được	Artifact defect dự kiến
Regression test	REG-CR-001	Xác nhận kiểm tra hạn mức còn hoạt động sau sửa lỗi	Artifact regression dự kiến

Quy tắc nghiệp vụ đề xuất để kiểm thử là BR-CR-001: Tổng phơi nhiễm = công nợ mở + tổng phải thu của đơn đang tạo. Khi tổng phơi nhiễm lớn hơn hạn mức tín dụng, ERP phải đặt trạng thái đơn là ON_HOLD_CREDIT; vai trò Sales Order Clerk không được xác nhận đơn; chỉ Credit Controller được giải phóng giữ đơn sau quyết định tín dụng. Đây là quy tắc mô phỏng dự kiến, không phải quy tắc đã được Business Owner phê duyệt.

Bước	Thao tác UAT	Dữ liệu	Kết quả mong đợi
1	Đăng nhập USR-NF-UAT-SALES-01	Vai trò Sales Order Clerk	Có quyền tạo đơn, không có quyền giải phóng giữ tín dụng
2	Tạo SO-NF-20260807-0042 cho CUS-NF-00128	180000000 VND	ERP lấy hạn mức 500000000 VND và công nợ mở 380000000 VND
3	Tính tổng phơi nhiễm	380000000 + 180000000 = 560000000 VND	Vượt hạn mức 60000000 VND
4	Lưu đơn	560000000 > 500000000	Trạng thái ON_HOLD_CREDIT; không tạo xác nhận bán hàng
5	Thử xác nhận đơn bằng Sales Order Clerk	SO-NF-20260807-0042	Bị chặn; hiển thị mã CR_LIMIT_EXCEEDED
6	Đăng nhập USR-NF-UAT-CREDIT-01 và giải phóng giữ	Lý do mô phỏng CREDIT_OVERRIDE_UAT	Chỉ sau thao tác này đơn mới chuyển RELEASED_FOR_CONFIRMATION

Payload kiểm thử API mô phỏng, dùng cho bằng chứng kỹ thuật nếu ERP có HTTP API:

{
  "salesOrderId": "SO-NF-20260807-0042",
  "customerId": "CUS-NF-00128",
  "currency": "VND",
  "openReceivableAmount": 380000000,
  "orderReceivableAmount": 180000000,
  "creditLimitAmount": 500000000,
  "exposureAmount": 560000000,
  "creditHoldAmount": 60000000,
  "status": "ON_HOLD_CREDIT",
  "errorCode": "CR_LIMIT_EXCEEDED"
}

Source mermaid — có thể chỉnh sửa

stateDiagram-v2
    [*] --> DRAFT
    DRAFT --> ON_HOLD_CREDIT: exposure > limit
    DRAFT --> READY_FOR_CONFIRMATION: exposure <= limit
    ON_HOLD_CREDIT --> RELEASED_FOR_CONFIRMATION: Credit Controller release
    RELEASED_FOR_CONFIRMATION --> CONFIRMED: Sales Order Clerk confirm
    READY_FOR_CONFIRMATION --> CONFIRMED: Sales Order Clerk confirm
    ON_HOLD_CREDIT: CR_LIMIT_EXCEEDED
    ON_HOLD_CREDIT: Sales Order Clerk blocked

Phương án	Mô tả	Kết quả đánh giá
OPT-CR-001	Chặn mọi đơn khi vượt hạn mức; không có ngoại lệ	Giảm rủi ro tín dụng, nhưng không hỗ trợ quyết định ngoại lệ có kiểm soát
OPT-CR-002	Giữ đơn; chỉ Credit Controller được giải phóng	Đáp ứng phân tách trách nhiệm, giữ dấu vết quyết định, phù hợp kịch bản UAT
OPT-CR-003	Cảnh báo nhưng cho Sales Order Clerk xác nhận	Không đạt tiêu chí kiểm soát vì người tạo đơn tự vượt kiểm soát

Tiêu chí quyết định	OPT-CR-001	OPT-CR-002	OPT-CR-003
Ngăn xác nhận vượt hạn mức	Đạt	Đạt	Không đạt
Có ngoại lệ được kiểm soát	Không đạt	Đạt	Không đạt
Phân tách trách nhiệm	Đạt	Đạt	Không đạt
Có thể truy vết UAT và defect	Đạt	Đạt	Đạt
Khuyến nghị BA	Không chọn	Chọn	Không chọn

Khuyến nghị: chọn OPT-CR-002, ghi vào /02-handbook/20-uat-planning-defects-and-regression.md cùng UAT-SC-CR-001, DEF-NF-UAT-001 và REG-CR-001.

Quyết định được thẩm quyền phê chuẩn: chưa có. Status corpus là IN_REVIEW, Version v0.9.0, ngày 2026-08-07; không có baseline hoặc approval reference. Business Owner và Credit Owner phải xác nhận BR-CR-001; QA Owner phải xác nhận kết quả UAT; Architect phải xác nhận cơ chế quyền nếu chuyển sang thiết kế ERP.

Nếu chọn sai OPT-CR-003, nhân viên bán hàng có thể xác nhận đơn khi tổng phơi nhiễm 560000000 VND vượt hạn mức 500000000 VND. Hậu quả mô phỏng: tăng rủi ro công nợ, mất kiểm soát ngoại lệ, và bằng chứng UAT không chứng minh được phân tách quyền.

9. Related Concepts & Dependencies

Core

Phụ thuộc là quan hệ một artifact cần thông tin kiểm soát từ artifact khác để giữ cùng nghĩa. Nguồn chân lý chuẩn (canonical source of truth) là nơi duy nhất được quyền định nghĩa giá trị đó. Chapter UAT không chép lại định nghĩa quy tắc, trường dữ liệu, ID hoặc cấu trúc template. Chapter chỉ ghi liên kết đến artifact canonical.

Nova Foods Trading & Manufacturing là case study mô phỏng; mọi tên, ID và dữ liệu là tổng hợp. Corpus đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND. Các trạng thái này không tạo baseline, approval hoặc quyền dùng production.

Source mermaid — có thể chỉnh sửa

flowchart TB
    SM["00_SOURCE_MAP<br/>Nguồn và ranh giới dùng nguồn"]
    CA["01_CURRICULUM_ARCHITECTURE<br/>Kiến trúc curriculum"]
    CM["CHAPTER_MANIFEST<br/>Chapter, đường dẫn, phạm vi"]
    TM["TEMPLATE_MANIFEST<br/>Danh mục template"]
    IR["TRACEABILITY_ID_REGISTRY<br/>ID persistent"]
    BR["CANONICAL_BUSINESS_RULES<br/>Quy tắc nghiệp vụ"]
    DD["CANONICAL_DATA_DICTIONARY<br/>Định nghĩa dữ liệu logic"]
    UAT["02-handbook/20-uat-planning-defects-and-regression.md<br/>Core"]

    SM --> CA
    CA --> CM
    CM --> UAT
    TM --> UAT
    IR --> UAT
    BR --> UAT
    DD --> UAT

CHAPTER_MANIFEST là nguồn chuẩn cho chapter và filename. TEMPLATE_MANIFEST là nguồn chuẩn cho template có kế hoạch. TRACEABILITY_ID_REGISTRY là nguồn chuẩn cho định danh persistent, nghĩa là ID giữ nguyên qua sửa nội dung để liên kết không đứt. CANONICAL_BUSINESS_RULES là nguồn chuẩn cho business rule. CANONICAL_DATA_DICTIONARY là nguồn chuẩn cho tên, nghĩa và ràng buộc dữ liệu logic. Chapter này không thay các nguồn đó.

Applied

Facts: Kịch bản UAT tín dụng dùng BR-CR-001, UAT-SC-CR-001, DEF-NF-UAT-001 và REG-CR-001. BR-CR-001 liên quan hạn mức tín dụng 500000000 VND; ví dụ đơn làm tổng phơi nhiễm thành 560000000 VND. Đây là dữ liệu mô phỏng.

Current Behavior: Chapter UAT cần chỉ người học cách tìm đúng nguồn của rule, scenario, defect và regression. Nếu chép giá trị hạn mức vào nhiều chapter, một sửa đổi có thể tạo nhiều giá trị mâu thuẫn.

Underlying Need: Người thực hiện UAT cần biết artifact nào định nghĩa nội dung, artifact nào chỉ tiêu thụ nội dung. Bằng chứng là CANONICAL_BUSINESS_RULES tự xác định là catalog canonical cho business rule, còn TRACEABILITY_ID_REGISTRY tự xác định là registry canonical cho ID.

Options:

Phương án	Cách làm	Đánh giá
OPT-DEP-001	Chép rule, ID và định nghĩa dữ liệu vào chapter UAT	Sai nguồn chân lý; dễ lệch khi sửa
OPT-DEP-002	Ghi ID nguyên dạng, đường dẫn canonical và mục đích liên kết	Giữ một nơi định nghĩa; phù hợp
OPT-DEP-003	Đổi ID thành tên mô tả dễ đọc trong từng chapter	Làm mất liên kết persistent; không chọn

Decision Criteria: Liên kết phải giữ đúng ID; filename phải đúng manifest; chapter không tạo rule mới; người đọc phải tìm được artifact chủ quản; bản sao không được trở thành nguồn thay thế.

Decision: Chọn OPT-DEP-002. Trong UAT, ghi BR-CR-001 nguyên dạng và dẫn đến /01-curriculum/CANONICAL_BUSINESS_RULES.md. Không lặp nội dung rule như một định nghĩa độc lập. Ghi UAT-SC-CR-001, DEF-NF-UAT-001, REG-CR-001 theo registry khi cần liên kết artifact.

Authority: Principal IT Business Analyst / Technical Curriculum Author giữ tính toàn vẹn metadata và liên kết corpus. Business Owner xác nhận nghiệp vụ; QA Owner xác nhận bằng chứng UAT; Architect xác nhận thiết kế quyền hoặc tích hợp. Không có approval được ghi nhận.

Artifact: /02-handbook/20-uat-planning-defects-and-regression.md tham chiếu các nguồn sau.

Loại phụ thuộc	Upstream canonical artifact	Nội dung chapter được phép dùng	Downstream consumer
Cấu trúc chapter	/01-curriculum/CHAPTER_MANIFEST.md	Tên chapter, filename, phạm vi section	Handbook UAT, QA review
Template	/01-curriculum/TEMPLATE_MANIFEST.md	Template ID, mục đích, trạng thái kế hoạch	UAT planner, defect reporter
ID persistent	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Chuỗi ID nguyên dạng, quy tắc đăng ký	UAT scenario, defect, regression record
Business rule	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Tham chiếu BR-CR-001, không tự định nghĩa lại	UAT execution, defect triage
Dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên trường và nghĩa dữ liệu đã đăng ký	Test-data preparation, API/data review
Nguồn học liệu	/00-research/00_SOURCE_MAP.md	Phân loại nguồn và ranh giới dùng nguồn	Curriculum, handbook authoring

Consequence if Wrong: Nếu chapter tạo bản sao BR-CR-001 với hạn mức khác catalog canonical, tester có thể chạy UAT theo 500000000 VND còn defect triage dùng giá trị khác. Defect khi đó không chứng minh lỗi ERP hay lỗi test basis. Nếu đổi DEF-NF-UAT-001 thành tên tự do, liên kết từ scenario, defect và regression có thể không còn truy được cùng một đối tượng.

Senior Lens

Không dùng chapter như registry. Registry trả lời “ID này có tồn tại, thuộc loại nào, dùng ở đâu”. Catalog rule trả lời “quy tắc này nghĩa gì”. Data dictionary trả lời “trường dữ liệu này nghĩa gì”. Template manifest trả lời “template nào được lập kế hoạch”. Chapter UAT trả lời “dùng các artifact đó thế nào trong lập kế hoạch, ghi nhận defect và regression”.

Quy tắc viết liên kết: giữ nguyên ID và filename; thêm mô tả ngắn cho người mới; không đổi ID để dịch tiếng Việt; không tạo ID thay thế; không dùng bản xuất PDF, bản sao hoặc trích đoạn làm canonical source. Khi nguồn canonical chưa có entry cần thiết, ghi nhận khoảng trống trong artifact quản trị phù hợp; không tự bù bằng rule hoặc ID mới trong chapter.

Quick Reference

Cần biết	Xem artifact canonical
Chapter này có đúng đường dẫn và phạm vi không	/01-curriculum/CHAPTER_MANIFEST.md
ID có hợp lệ và persistent không	/01-curriculum/TRACEABILITY_ID_REGISTRY.md
Rule tín dụng BR-CR-001 nghĩa gì	/01-curriculum/CANONICAL_BUSINESS_RULES.md
Trường hoặc dữ liệu test nghĩa gì	/01-curriculum/CANONICAL_DATA_DICTIONARY.md
Template UAT, defect, regression được lập kế hoạch thế nào	/01-curriculum/TEMPLATE_MANIFEST.md
Nguồn chuẩn được phép dùng ra sao	/00-research/00_SOURCE_MAP.md

Core

Ma trận truy vết (traceability matrix) nối mỗi nhu cầu với bằng chứng kiểm thử. Nó không sao chép nội dung nguồn; nó chỉ giữ liên kết tới ID canonical trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu là tổng hợp.

Liên kết	Nguồn canonical	Đích dùng trong UAT	Bằng chứng cần có	Quy tắc kiểm tra
NEED	Nhu cầu nghiệp vụ đã đăng ký	Phạm vi kịch bản UAT	ID NEED còn hiệu lực trong registry	Không tạo test chỉ từ ý kiến miệng
REQ	Requirement đã đăng ký	Test basis, điều kiện pass/fail	ID REQ liên kết ít nhất một TC	REQ không có TC là khoảng trống kiểm thử
BR	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Quy tắc kỳ vọng khi chạy UAT	ID BR canonical, trạng thái nguồn	Không chép câu rule vào defect log
AC	Acceptance Criteria, tiêu chí chấp nhận	Kết quả mong đợi của test case	ID AC gắn với REQ phù hợp	Pass không được ghi nếu chưa đối chiếu AC
DATA	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Dữ liệu test, trường, kiểu dữ liệu	ID DATA, giá trị synthetic, ràng buộc logic	Không dùng dữ liệu cá nhân hay dữ liệu production
API	Đặc tả API canonical nếu đã đăng ký	Kiểm tra tích hợp, mã phản hồi, payload	ID API, phiên bản endpoint	Không suy diễn hợp đồng API từ giao diện
TC	Test case trong bộ UAT	Bằng chứng thực thi	ID TC, kết quả, người thực hiện, thời điểm Asia/Ho_Chi_Minh	Một TC phải nêu test basis rõ

Source mermaid — có thể chỉnh sửa

flowchart TB
    NEED[NEED: nhu cầu] --> REQ[REQ: yêu cầu]
    REQ --> AC[AC: tiêu chí chấp nhận]
    REQ --> BR[BR: quy tắc nghiệp vụ<br/>nếu phù hợp]
    REQ --> DATA[DATA: dữ liệu logic<br/>nếu phù hợp]
    REQ --> API[API: hợp đồng tích hợp<br/>nếu đã đăng ký]

    REQ --> CHECK{Có ít nhất một<br/>TC?}
    CHECK -->|Không| GAP[Khoảng trống kiểm thử<br/>REQ chưa có TC]
    GAP --> FIX[Bổ sung hoặc liên kết TC<br/>trước UAT]
    FIX --> CHECK
    GAP --> NOPASS[Không ghi Pass<br/>khi chưa có TC]

    CHECK -->|Có| TC[TC: test case UAT]
    AC --> TC
    BR --> TC
    DATA --> TC
    API --> TC

    TC --> EXEC[Thực thi UAT<br/>đối chiếu test basis áp dụng:<br/>AC, BR, DATA, API]
    EXEC --> EVIDENCE[Bằng chứng kết quả<br/>TC ID · kết quả thực tế · Pass hoặc Fail<br/>điều kiện pass/fail · bằng chứng thực thi<br/>người thực hiện · thời điểm Asia/Ho_Chi_Minh]

Applied

Trường	Nội dung
Facts	UAT cần chứng minh chức năng tạo đơn bán hàng xử lý đúng dữ liệu khách hàng, quy tắc nghiệp vụ và tích hợp tồn kho mô phỏng.
Current Behavior	Test case chỉ ghi “tạo đơn thành công”, không chỉ ra nhu cầu, requirement, rule, tiêu chí chấp nhận hay dữ liệu nguồn.
Underlying Need	QA và Business Owner cần biết test đang xác minh điều gì; vì tên màn hình không chứng minh hệ thống đáp ứng nhu cầu.
Options	1. Ghi mô tả tự do trong TC. 2. Gắn các ID canonical NEED, REQ, BR, AC, DATA, API khi có áp dụng.
Decision Criteria	Liên kết phải truy ngược được tới nguồn canonical; không tạo ID mới trong handbook; không biến giả định thành rule vận hành.
Decision	Chọn phương án 2. Mỗi TC ghi các ID áp dụng và đường dẫn artifact nguồn, không sao chép định nghĩa canonical.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết. Business Owner, QA, Architect, Data Owner xác nhận phần thuộc thẩm quyền khi được phân công.
Artifact	/02-handbook/20-uat-planning-defects-and-regression.md tham chiếu /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	Defect có thể bị gán sai requirement; regression bỏ sót rule; test pass nhưng tích hợp hoặc dữ liệu vẫn sai.

Mẫu dòng liên kết dùng trong UAT:

TC	NEED	REQ	BR	AC	DATA	API	Kết quả
ID TC canonical từ registry	ID NEED áp dụng	ID REQ áp dụng	ID BR áp dụng hoặc Không áp dụng	ID AC áp dụng	ID DATA áp dụng	ID API áp dụng hoặc Không áp dụng	PASS, FAIL, BLOCKED

Không áp dụng chỉ hợp lệ khi test basis không chứa loại liên kết đó. Ô trống không phải bằng chứng; ô trống làm mất khả năng truy ngược.

Senior Lens

REQ đổi im lặng có thể làm AC cũ vẫn xanh nhưng không còn kiểm tra yêu cầu mới. BR đổi im lặng có thể làm cùng test data cho kết quả khác mà đội UAT nhầm là lỗi phần mềm. DATA đổi kiểu, độ dài hoặc ràng buộc có thể làm test pass trên giao diện nhưng fail ở tích hợp. API đổi endpoint, field bắt buộc hoặc mã phản hồi có thể làm test end-to-end sai dù từng màn hình vẫn hoạt động.

Quy tắc: khi ID nguồn đổi phiên bản, người quản trị truy vết rà mọi TC tham chiếu ID đó, đánh dấu cần xem xét và chỉ cập nhật kết quả sau khi chạy lại test phù hợp. Không sửa lịch sử kết quả cũ để khớp nguồn mới.

Quick Reference

Câu hỏi	Kiểm tra
Test này phục vụ nhu cầu nào?	NEED
Hệ thống phải làm gì?	REQ
Điều kiện nghiệp vụ nào chi phối?	BR
Khi nào được coi là đạt?	AC
Dữ liệu nào làm bằng chứng?	DATA
Tích hợp nào bị tác động?	API
Test nào chứng minh kết quả?	TC

Core

Lan truyền thay đổi là chuỗi tác động khi nguồn phụ thuộc đổi. Một phụ thuộc có thể là quy tắc nghiệp vụ, định nghĩa dữ liệu, hợp đồng API, yêu cầu, tiêu chí chấp nhận hoặc test case. Khi nguồn canonical đổi, artifact nhận tham chiếu phải được đánh giá lại; không sao chép nội dung nguồn sang UAT plan rồi sửa riêng.

Ví dụ: CANONICAL_DATA_DICTIONARY đổi ý nghĩa trường trạng thái lô hàng. REQ dùng trường này, AC kiểm tra hiển thị, API truyền giá trị, TC kiểm tra kết quả. Nếu chỉ sửa API mà không rà AC và TC, UAT có thể báo “Pass” cho hành vi cũ hoặc chặn lỗi thật.

Source mermaid — có thể chỉnh sửa

flowchart TB
    SRC["Nguồn canonical đổi"] --> CR["Ghi nhận thay đổi có kiểm soát<br/>version · phạm vi tác động · người chịu trách nhiệm · kết quả rà soát"]
    CR --> IA["Phân tích tác động"]

    IA --> REQ["Rà soát REQ / BR / AC"]
    IA --> DATA["Rà soát DATA / API"]
    IA --> TC["Rà soát test basis / TC"]

    REQ --> SUMMARY["Tổng hợp kết quả rà soát"]
    DATA --> SUMMARY
    TC --> SUMMARY

    SUMMARY --> ANY{"Có artifact bị ảnh hưởng?"}
    ANY -- "Có" --> UPDATE["Cập nhật artifact bị ảnh hưởng"]
    UPDATE --> CONFIRM["Xác nhận artifact và liên kết trace đã cập nhật"]
    CONFIRM --> UAT["Thực thi UAT lại"]
    UAT --> EV_UAT["Bằng chứng kết quả và defect"]

    ANY -- "Không" --> NO_IMPACT["Ghi nhận không bị ảnh hưởng"]
    NO_IMPACT --> EV_REVIEW["Bằng chứng kết quả rà soát"]

    UAT_PLAN["UAT plan chỉ tham chiếu<br/>nguồn canonical"] -.-> SRC

Thay đổi im lặng là sửa nội dung, giá trị, ý nghĩa, giao diện, API hoặc liên kết mà không ghi nhận version, phạm vi tác động, người chịu trách nhiệm và kết quả rà soát. Nó phá traceability vì liên kết vẫn tồn tại về mặt chữ, nhưng không còn cùng ý nghĩa.

Applied

Mục	Nội dung
Facts	Nova Foods là case study mô phỏng, chỉ dùng dữ liệu tổng hợp. CANONICAL_DATA_DICTIONARY thay đổi tập giá trị hợp lệ của trường trạng thái lô trong luồng nhận hàng.
Current Behavior	UAT plan và TC đã kiểm tra tập giá trị cũ; API contract và màn hình có thể nhận hoặc hiển thị khác nhau.
Underlying Need	Bảo đảm bằng chứng UAT kiểm tra đúng phiên bản ý nghĩa dữ liệu hiện hành, không kiểm tra bản sao cũ.
Options	(1) Sửa riêng TC; (2) sửa UAT plan và TC; (3) ghi nhận thay đổi tại nguồn canonical, phân tích toàn bộ liên kết rồi cập nhật artifact bị ảnh hưởng.
Decision Criteria	Giữ một nguồn chân lý; xác định đủ tác động REQ, BR, AC, DATA/API và TC; không tự suy diễn quyết định nghiệp vụ hoặc kiến trúc.
Decision	Chọn phương án 3. Dùng /01-curriculum/TRACEABILITY_ID_REGISTRY.md để xác định liên kết; giữ định nghĩa dữ liệu tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì traceability. Business Owner, Architect, QA hoặc Data Owner xác nhận phần thuộc thẩm quyền tương ứng. Không có approval ngầm định.
Artifact	Ghi thay đổi và tác động trong artifact kiểm soát liên quan; UAT plan chỉ tham chiếu ID và phiên bản nguồn, không chép lại định nghĩa canonical.
Consequence if Wrong	TC có thể Pass sai; defect bị phân loại sai; dữ liệu tích hợp lệch nghĩa; regression bỏ sót luồng cũ bị phá; bằng chứng UAT không chứng minh được phạm vi đã kiểm tra.

Senior Lens

Không phải mọi thay đổi đều cần chạy toàn bộ regression. BA phân loại tác động trước: semantic change là đổi ý nghĩa; structural change là đổi tên, kiểu, bắt buộc hay tập giá trị; behavioral change là đổi xử lý; interface change là đổi request, response, xác thực hoặc mã lỗi API. Semantic và behavioral change thường tác động AC cùng TC. Structural và interface change thường tác động DATA/API cùng TC tích hợp.

Dấu hiệu phụ thuộc đổi im lặng: ID liên kết còn nguyên nhưng version nguồn khác; TC dùng tên trường không còn trong data dictionary; AC mô tả kết quả khác BR; API payload nhận giá trị không được nguồn dữ liệu công nhận; defect được đóng nhưng không có test evidence theo version nguồn. Mỗi dấu hiệu là lý do mở phân tích tác động, không phải bằng chứng để tự sửa rule.

Quick Reference

Quy tắc	Cách áp dụng
Một định nghĩa, một nguồn	Quy tắc ở CANONICAL_BUSINESS_RULES; dữ liệu ở CANONICAL_DATA_DICTIONARY; ID ở TRACEABILITY_ID_REGISTRY.
Không sửa đứt liên kết	Giữ ID canonical; cập nhật trạng thái liên kết và version tham chiếu.
Không có tác động đã đánh giá, không chạy UAT	UAT phải biết test basis nào đổi và TC nào cần chạy lại.
Không có thẩm quyền, không kết luận	Gắn Verification required khi thay đổi chạm pháp lý, kế toán, bảo mật, kiến trúc hoặc vận hành.
Không có approval ngầm định	IN_REVIEW, version v0.9.0, ngày 2026-08-07 không phải baseline hay phê duyệt.

10. Common Mistakes & Anti-patterns

Core

UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) thất bại khi nhóm coi đây là buổi “bấm thử” thay vì kiểm tra có bằng chứng rằng hệ thống đáp ứng test basis đã xác định. Với Nova Foods mô phỏng, mọi ví dụ dưới đây dùng dữ liệu tổng hợp, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không tạo phê duyệt ngầm định.

Sai lầm	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Viết TC theo màn hình, không theo AC hoặc BR	TC ghi “bấm Lưu thành công”; không có expected result nghiệp vụ	Người viết chưa xác định test basis	Liên kết từng TC tới AC, BR hoặc rule dữ liệu canonical trước khi chạy
Dùng dữ liệu UAT không kiểm soát	Người test tự nhập mã hàng, giá, ngày bất kỳ	Không có data set và precondition	Ghi rõ test data tổng hợp, trạng thái dữ liệu đầu vào, người chuẩn bị và thời điểm
Đóng defect bằng lời nói	Defect có trạng thái “đã sửa” nhưng thiếu build, TC chạy lại, kết quả	Nhầm sửa code với xác nhận sửa đúng	Chỉ chuyển defect sang trạng thái đóng khi retest có evidence gắn ID defect
Chạy regression theo danh sách cũ	TC còn gọi tên trường hoặc API payload đã đổi	Không phân tích tác động thay đổi	So version nguồn, xác định TC ảnh hưởng, chạy lại phạm vi đã ghi nhận
Gom nhiều lỗi vào một defect	Một defect chứa lỗi phân quyền, tính tiền, hiển thị	Muốn giảm số lượng ticket	Tách defect theo một hành vi sai, một expected result, một đường tái hiện
Gán severity theo người báo lỗi	“Lỗi gấp” nhưng không nêu tác động	Thiếu tiêu chí tác động nghiệp vụ	Đánh giá severity theo mất dữ liệu, sai giao dịch, chặn luồng, rủi ro bảo mật hoặc phạm vi người dùng
Dùng ảnh chụp màn hình làm bằng chứng duy nhất	Không có URL/môi trường, thời gian, dữ liệu, build	Evidence không thể tái lập	Bổ sung TC ID, bước chạy, actual result, expected result, test data, build và timestamp Asia/Ho_Chi_Minh

Applied

Facts: Nova Foods mô phỏng có TC TC-UAT-ORD-014 kiểm tra tạo đơn bán hàng tổng hợp SO-SYN-00014. Expected result ghi: “Hệ thống chặn lưu khi trường mã khách hàng rỗng.” Người test báo “không lưu được” trong chat.

Current Behavior: Nhóm tạo một defect chung: “Không lưu đơn hàng.” Không có bước tái hiện, không có giá trị trường, không có build, không có liên kết TC-UAT-ORD-014.

Underlying Need: QA và đội phát triển cần phân biệt lỗi validation mã khách hàng với lỗi mạng, phân quyền, dữ liệu khách hàng hết hiệu lực hoặc lỗi lưu đơn hàng.

Options:

Lựa chọn	Giá trị	Rủi ro
Đóng theo chat vì đội phát triển nói đã sửa	Nhanh	Không chứng minh sửa đúng TC
Giữ defect chung	Ít ticket	Không định vị được hành vi sai
Chuẩn hóa defect, chạy retest theo TC	Tái lập và truy vết được	Cần ghi evidence đầy đủ

Decision Criteria: Chọn cách tạo được bằng chứng tái lập, liên kết test basis, phân biệt nguyên nhân và không tự suy diễn thẩm quyền nghiệp vụ.

Decision: Dùng lựa chọn 3. Defect phải ghi TC-UAT-ORD-014, precondition, dữ liệu tổng hợp, bước tái hiện, actual result, expected result, build, severity, owner xử lý và kết quả retest.

Authority: BA duy trì traceability và làm rõ expected result từ artifact nguồn. QA xác nhận bằng chứng test. Business Owner xác nhận chấp nhận nghiệp vụ khi có thẩm quyền ghi nhận. Không có vai trò nào được suy ra là đã phê duyệt từ trạng thái IN_REVIEW.

Artifact: Cập nhật defect record và UAT execution record có liên kết tới TC-UAT-ORD-014; không đổi ID canonical.

Consequence if Wrong: Defect có thể bị đóng khi lỗi validation còn tồn tại. Regression sau đó không biết phải chạy lại TC nào. Bằng chứng UAT không chứng minh được phạm vi kiểm tra.

Cảnh báo: Không dùng dữ liệu cá nhân, dữ liệu khách hàng thật, thông tin đăng nhập thật hoặc dữ liệu production trong UAT. Recovery an toàn: dừng chia sẻ, cô lập evidence chứa dữ liệu không phù hợp, thay bằng dữ liệu tổng hợp, báo Security Owner theo quy trình được áp dụng.

Senior Lens

Sai lầm mới thường là thiếu cấu trúc. Sai lầm đội delivery thường là bỏ cấu trúc khi áp lực tiến độ. Cả hai tạo cùng dấu hiệu: không tái lập được, không đo được tác động, không biết ai có thẩm quyền kết luận. Sửa bằng artifact nhỏ nhưng đủ: một TC có nguồn, một defect có bước tái hiện, một retest có evidence.

Không tự nâng cấp lời nói thành quyết định. Câu “nghiệp vụ đã đồng ý” không phải evidence nếu thiếu artifact, vai trò có thẩm quyền, phạm vi và thời điểm ghi nhận. BA ghi nhận phát biểu là input cần xác minh; không ghi thành approval, baseline hay business rule mới.

Quick Reference

Kiểm tra trước khi chuyển defect	Điều kiện đạt
Tái lập	Có precondition, test data, bước và actual result
So sánh	Có expected result từ TC, AC, BR hoặc nguồn canonical
Truy vết	Có ID TC và liên kết artifact nguồn
Sửa lỗi	Có build hoặc phiên bản được retest
Đóng lỗi	Có kết quả retest và evidence
Thẩm quyền	Không ghi approval khi chưa có tham chiếu được ghi nhận

Core

Cảnh báo chỉ dùng khi lỗi có thể làm sai kết quả UAT, mất bằng chứng kiểm thử, che giấu lỗi nghiêm trọng, hoặc khiến đội dự án hiểu sai trạng thái phát hành. Cảnh báo không dùng để nhấn mạnh câu văn thông thường; lạm dụng làm người đọc bỏ qua rủi ro thật.

[!WARNING] Không đóng defect là Closed chỉ vì người kiểm thử không tái hiện được lỗi một lần. Nếu môi trường, dữ liệu, quyền hoặc phiên bản build khác nhau, bằng chứng chưa đủ để kết luận lỗi đã được sửa.

Rủi ro thật	Dấu hiệu quan sát	Ví dụ Nova Foods mô phỏng, dữ liệu tổng hợp	Phục hồi an toàn
Mất liên kết defect với test	Defect không có Test Case ID, build, ảnh chụp hoặc dữ liệu tái hiện	DEF-UAT-042 ghi “không tạo được phiếu xuất” nhưng không nêu lô hàng tổng hợp, vai trò người dùng hay bản build	Đặt defect về IN_REVIEW; bổ sung bằng chứng; không xác nhận sửa trước khi chạy lại cùng điều kiện
Retest sai phiên bản	Tester kiểm thử trên build cũ, nhưng defect bị đóng theo build mới	Nhóm UAT kiểm tra DEF-UAT-042 trên môi trường có nhãn v0.9.0; đội kỹ thuật sửa ở bản triển khai khác chưa được nhận diện trong artifact	Ghi rõ build/environment; mở lại defect nếu không chứng minh được bản đã kiểm thử
Regression bị bỏ qua	Sửa một luồng nhưng không kiểm tra luồng phụ thuộc	Sửa tính tồn kho khi tạo phiếu xuất, nhưng không chạy lại báo cáo tồn kho sau xuất	Khoanh vùng chức năng bị ảnh hưởng; chạy regression tối thiểu cho tạo phiếu xuất và báo cáo tồn kho; không suy diễn phạm vi rộng hơn bằng chứng
Trạng thái sai che giấu rủi ro	Defect chuyển Closed khi chưa có kết quả retest	Lỗi chặn tạo phiếu xuất được đánh dấu Closed sau khi developer nói đã sửa	Đổi sang trạng thái chờ retest theo quy trình dự án; chỉ đóng khi có kết quả tái kiểm ghi nhận

Source mermaid — có thể chỉnh sửa

stateDiagram-v2
    direction TB
    [*] --> Logged
    Logged --> IN_REVIEW: đủ bằng chứng tối thiểu
    IN_REVIEW --> IN_REVIEW: bổ sung dữ liệu tái hiện
    IN_REVIEW --> Retest: xác định build và môi trường có bản sửa
    Retest --> Closed: tái kiểm đạt
    Retest --> IN_REVIEW: tái kiểm không đạt hoặc điều kiện khác build, môi trường, dữ liệu, quyền
    Closed --> IN_REVIEW: thiếu bằng chứng retest hoặc không chứng minh đúng build

Applied

Trường	Nội dung
Facts	Nova Foods là case mô phỏng. DEF-UAT-042 báo lỗi khi tạo phiếu xuất kho từ đơn bán hàng tổng hợp.
Current Behavior	Defect được chuyển Closed; không có Test Case ID, môi trường, bản build hoặc kết quả retest.
Underlying Need	Đội cần biết lỗi đã được sửa trong điều kiện nào trước khi cho rằng rủi ro UAT giảm.
Options	Giữ Closed; hoặc chuyển IN_REVIEW để hoàn thiện bằng chứng rồi retest.
Decision Criteria	Có liên kết test, điều kiện tái hiện, bản sửa xác định và kết quả retest hay không.
Decision	Chuyển DEF-UAT-042 về IN_REVIEW. Lý do: bốn bằng chứng tối thiểu chưa có.
Authority	BA duy trì traceability. QA Lead xác nhận cách xử lý test/defect. Business Owner không bị suy diễn là đã chấp thuận.
Artifact	Cập nhật bản ghi defect và liên kết tới test evidence trong artifact UAT được kiểm soát; giữ trạng thái corpus IN_REVIEW, version v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Nếu đóng sai, lỗi xuất kho có thể quay lại ở regression; báo cáo tiến độ UAT sẽ sai vì defect không có bằng chứng đóng.

Senior Lens

Ranh giới phục hồi an toàn: chỉ sửa trạng thái, bổ sung bằng chứng, xác định môi trường và chạy retest trong phạm vi lỗi đã ghi nhận. Không tự đổi business rule, cấu hình ERP, quyền người dùng, dữ liệu kế toán, hay kết luận tuân thủ pháp lý để “làm hết lỗi”. Các thay đổi đó cần artifact riêng và thẩm quyền phù hợp.

[!WARNING] Không dùng kết quả UAT mô phỏng để tuyên bố Nova Foods tuân thủ luật, an toàn thực phẩm, kế toán, bảo vệ dữ liệu cá nhân hoặc sẵn sàng production. UAT chứng minh kết quả kiểm thử trong điều kiện đã ghi nhận, không thay thế xác nhận của Legal Owner, Accounting Owner, Security, QA Lead hoặc Business Owner.

Quick Reference

• Cảnh báo: chỉ cho rủi ro gây sai quyết định, mất bằng chứng, hoặc che giấu lỗi.
• Defect đóng: cần bản sửa xác định và retest đạt có ghi nhận.
• Thiếu bằng chứng: quay về IN_REVIEW, không tạo kết luận mới.
• Nova Foods: mô phỏng giáo dục, dữ liệu tổng hợp; IN_REVIEW không phải approval hay baseline.

Core

Năm lỗi dưới đây khác nhau vì loại thông tin thiếu khác nhau. Tách riêng giúp BA sửa đúng chỗ thay vì viết lại cả kịch bản UAT.

Loại lỗi	Dấu hiệu quan sát được	Ví dụ Nova Foods mô phỏng, dữ liệu tổng hợp	Nguyên nhân gốc	Hành động sửa an toàn
Mơ hồ (ambiguity)	Hai người kiểm thử hiểu cùng câu theo hai cách	“Hệ thống cảnh báo khi số lượng tồn kho thấp.” Không có ngưỡng, kho áp dụng, thời điểm kiểm tra	Ngôn ngữ tự nhiên không định nghĩa điều kiện	Viết điều kiện đo được: kho nào, ngưỡng nào, sự kiện nào, kết quả nào
Không đầy đủ (incompleteness)	Kịch bản có luồng chính nhưng thiếu dữ liệu, tiền điều kiện, ngoại lệ hoặc kết quả mong đợi	UAT tạo đơn bán hàng có dòng hàng, nhưng không nêu khách hàng, giá, trạng thái tín dụng hay kết quả lưu	Người viết coi kiến thức ngầm là dữ liệu test	Bổ sung test basis: tiền điều kiện, dữ liệu tổng hợp, bước, expected result, bằng chứng
Khẳng định thẩm quyền không có căn cứ	Ghi “đã được Business Owner phê duyệt” nhưng artifact không có approval reference	UAT-NF-SO-001 ghi “đã chấp thuận áp dụng VAT” trong khi corpus chỉ có IN_REVIEW	Nhầm trạng thái review với phê duyệt; BA suy diễn quyền quyết định	Đổi thành “Verification required”; ghi đúng owner cần xác nhận; không dùng APPROVED hay BASELINED
Dùng sai ký pháp (notation misuse)	Sơ đồ mang nhãn BPMN nhưng dùng ký hiệu PlantUML hoặc mũi tên không có nghĩa chuẩn	Activity diagram mô tả “Kiểm tra tồn kho” bị gọi là BPMN 2.0.2	Nhầm công cụ vẽ với chuẩn ký pháp	Đổi nhãn thành “PlantUML activity diagram”, hoặc vẽ BPMN 2.0.2 đúng chuẩn OMG
Đứt truy vết (traceability break)	Test case không lần ngược được tới requirement, rule, data hoặc defect	Defect DEF-NF-014 chỉ ghi “sai tồn kho”, không có UAT ID, rule ID, ảnh bằng chứng	ID bị đổi, sao chép thủ công, nhiều nguồn chân lý	Giữ canonical ID; liên kết source artifact; dừng đóng defect khi liên kết còn thiếu

Cảnh báo: Không dùng kết quả UAT để tự tạo thẩm quyền nghiệp vụ, kế toán, pháp lý, an toàn thực phẩm hoặc bảo mật. Corpus Nova Foods là mô phỏng giáo dục, dùng dữ liệu tổng hợp; IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải approval hay baseline.

Ranh giới phục hồi an toàn: Có thể sửa câu chữ mơ hồ, bổ sung dữ liệu test tổng hợp, sửa nhãn sơ đồ và khôi phục liên kết ID trong artifact review. Không được tự sửa rule có ảnh hưởng thuế, kế toán, dữ liệu cá nhân hoặc truy xuất thực phẩm thành quyết định vận hành. Các nội dung đó giữ nhãn Verification required và chuyển đúng owner có thẩm quyền.

11. Senior BA Notes & Rules of Thumb

Senior Lens

Senior BA không quyết định thay Business Owner, QA Lead, Architect, Legal Owner, Accounting Owner hoặc Security Owner. Senior BA làm rõ quyết định nào cần đưa ra, bằng chứng nào đủ, ai có thẩm quyền, và hậu quả nếu chọn sai. Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07 không tạo approval hoặc baseline.

Tình huống UAT	Trade-off cần phân tích	Bằng chứng cần có	Người có thẩm quyền quyết định	Kết luận BA được phép ghi
DEF-NF-014 báo tồn kho hiển thị âm sau xuất hàng	Đóng defect nhanh giảm chậm UAT, nhưng có thể che lỗi tồn kho hoặc sai dữ liệu test	UAT case, dữ liệu đầu vào tổng hợp, log thời điểm, ảnh màn hình, rule liên kết từ CANONICAL_BUSINESS_RULES nếu có	Business Owner quyết định hành vi nghiệp vụ; QA Lead quyết định trạng thái test; Architect xác nhận nguyên nhân kỹ thuật	“Chưa đủ bằng chứng phân biệt lỗi rule, dữ liệu hoặc tích hợp; giữ defect mở để phân tích.”
Người dùng muốn bỏ kiểm tra quyền để hoàn tất UAT	UAT nhanh hơn, nhưng mất bằng chứng kiểm soát truy cập	Vai trò test, quyền đã cấp, kết quả truy cập, yêu cầu bảo mật liên quan	Security Owner và Business Owner	“Không khuyến nghị bỏ kiểm tra quyền; dùng tài khoản test đúng vai trò hoặc ghi ngoại lệ có owner xác nhận.”
Finance và Sales bất đồng về thời điểm ghi nhận giá trị đơn hàng	Sales cần báo cáo tức thời; Finance cần diễn giải kế toán đúng	Mô tả quy trình, dữ liệu giao dịch tổng hợp, nguồn Luật Kế toán chỉ ở mức bối cảnh, xác nhận Accounting Owner	Accounting Owner; Business Owner cho ưu tiên vận hành	“Verification required: UAT chưa đủ để xác nhận cách ghi nhận kế toán.”
Defect liên quan dữ liệu khách hàng	Sửa dữ liệu giúp tái kiểm thử nhanh; sao chép dữ liệu có thể tăng rủi ro dữ liệu cá nhân	Phân loại dữ liệu, nguồn dữ liệu test, quyền truy cập, phương án che dữ liệu	Legal Owner và Security Owner	“Chỉ dùng dữ liệu tổng hợp; không suy diễn tuân thủ pháp lý từ kết quả UAT.”

Chất lượng bằng chứng quyết định sức mạnh khuyến nghị. Một ảnh màn hình chỉ chứng minh kết quả quan sát tại một thời điểm; không tự chứng minh nguyên nhân. Log có timestamp chứng minh hệ thống đã ghi sự kiện; không tự chứng minh rule nghiệp vụ đúng. Requirement hoặc business rule mô tả kỳ vọng; không tự chứng minh cấu hình đã triển khai đúng. Senior BA nối các phần này: kỳ vọng từ nguồn canonical, bước tái hiện, dữ liệu tổng hợp, kết quả thực tế, và owner phải xác nhận phần còn chưa biết.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[UAT phát hiện sai lệch] --> B[BA ghi UAT case, dữ liệu tổng hợp, thời điểm và kết quả thực tế]
    B --> C{Tái hiện có nguy cơ mất dữ liệu, lộ dữ liệu cá nhân, sai số dư mô phỏng hoặc che audit trail?}

    C -->|Có| D[Dừng thao tác gây rủi ro; không tiếp tục tái hiện]
    D --> E[Bảo toàn bằng chứng hiện có và ghi giới hạn tái hiện]
    E --> F[Xác định owner: Security Owner và Legal Owner cho dữ liệu cá nhân; Accounting Owner cho số dư hoặc hạch toán; Security Owner hoặc owner phù hợp cho mất dữ liệu hoặc audit trail; Legal Owner cho vấn đề pháp lý]
    F --> G[Chuyển owner xử lý theo thẩm quyền]
    G --> H{Đủ bằng chứng để owner kết luận phần thuộc thẩm quyền?}
    H -->|Không| I[Giữ defect mở hoặc ghi Verification required]
    H -->|Có| J[Ghi quyết định của owner]
    I --> K[Ghi xác nhận của owner, bất định và bằng chứng vào artifact IN_REVIEW]
    J --> K
    K --> O[IN_REVIEW không phải approval hoặc baseline]

    C -->|Không| L{Bằng chứng nối được kỳ vọng từ nguồn canonical, bước tái hiện, dữ liệu tổng hợp, kết quả thực tế và phần chưa biết?}
    L -->|Không| M[Ghi bất định và yêu cầu bằng chứng bổ sung]
    L -->|Có| N[Liên kết requirement, rule nghiệp vụ, defect và bằng chứng kiểm thử]
    M --> P[Xác định owner: Business Owner cho hành vi nghiệp vụ; QA Lead cho trạng thái test; Architect cho nguyên nhân kỹ thuật; Security Owner và Legal Owner cho dữ liệu cá nhân; Accounting Owner cho số dư hoặc hạch toán; Legal Owner cho vấn đề pháp lý]
    N --> P
    P --> Q[Owner xác nhận phần thuộc thẩm quyền]
    Q --> R{Đủ bằng chứng để owner kết luận phần thuộc thẩm quyền?}
    R -->|Không| S[Giữ defect mở hoặc ghi Verification required]
    R -->|Có| T[Ghi quyết định của owner]
    S --> U[Ghi xác nhận của owner, bất định và bằng chứng vào artifact IN_REVIEW]
    T --> U
    U --> O

Ngoại lệ với quy tắc “tái hiện lỗi trước khi kết luận” xảy ra khi tiếp tục tái hiện có thể làm mất dữ liệu, lộ dữ liệu cá nhân, làm sai số dư mô phỏng, hoặc che dấu audit trail. Khi đó, BA dừng thao tác gây rủi ro, bảo toàn bằng chứng hiện có, ghi rõ giới hạn tái hiện, rồi chuyển Security Owner, Accounting Owner hoặc owner phù hợp. Không thay việc tái hiện bằng suy đoán.

Xung đột stakeholder không được giải bằng người nói lớn hơn. BA tách xung đột thành: sự kiện quan sát được, nhu cầu từng bên, rule hoặc constraint liên quan, và quyền quyết định. Ví dụ Sales nói “đơn phải xuất được khi tồn kho bằng 0”; Warehouse nói “không được xuất âm”; hai câu này không tự là requirement đã phê duyệt. Bằng chứng hiện có chỉ cho thấy hai nhu cầu mâu thuẫn. Khuyến nghị defensible là ghi cả hai nhu cầu, nêu tác động UAT, đánh dấu Verification required, và yêu cầu Business Owner quyết định ưu tiên nghiệp vụ; nếu ảnh hưởng hạch toán hoặc kiểm soát tồn kho, thêm Accounting Owner.

Mẫu câu ghi bất định đúng: “Dựa trên UAT case, dữ liệu tổng hợp và log hiện có, hệ thống cho kết quả khác kỳ vọng được mô tả trong artifact liên kết. Chưa có bằng chứng đủ để kết luận nguyên nhân là rule, cấu hình, dữ liệu hay tích hợp. Khuyến nghị giữ DEF-NF-014 ở trạng thái mở và chuyển Business Owner, QA Lead, Architect xem xét theo thẩm quyền.” Mẫu này ghi rõ evidence/reasoning bridge, không gọi nội dung là approved, compliant, baselined hoặc production-ready.

Senior Lens

Senior BA review UAT dựa trên bằng chứng, không dựa trên số người phản đối. Defect là sai lệch có thể quan sát giữa kết quả thực tế và test basis, tức nguồn kiểm thử như requirement, business rule, acceptance criteria hoặc kịch bản UAT. Không có test basis, ghi nhận là Verification required, không gán lỗi sản phẩm.

Heuristic review	Bằng chứng tối thiểu	Red flag	Ngưỡng escalation	Ngoại lệ không áp dụng quy tắc thường
Tái hiện trước khi phân loại defect	Bước tái hiện, dữ liệu tổng hợp, kết quả mong đợi, kết quả thực tế, ảnh hoặc log phù hợp	“Không hoạt động” nhưng thiếu bước và dữ liệu	Không tái hiện được sau 2 lần độc lập hoặc môi trường UAT khác nhau	Lỗi mất dữ liệu, lộ dữ liệu, sai quyền truy cập: escalation ngay dù chưa tái hiện hoàn toàn
Tách defect khỏi change request	So sánh trực tiếp với acceptance criteria đã truy vết	Người dùng nói “hệ thống phải làm khác” nhưng nguồn gốc yêu cầu không nói vậy	Tranh chấp làm đổi phạm vi, chi phí, lịch phát hành hoặc kiểm soát nghiệp vụ	Luồng hiện tại gây nguy cơ an toàn thực phẩm, bảo mật hoặc sai sổ sách: không chờ quy trình change request thường; chuyển đúng owner
Đánh giá severity theo tác động, không theo chức danh người báo	Số giao dịch bị chặn, dữ liệu ảnh hưởng, workaround, phạm vi người dùng	Gọi mọi lỗi là blocker; severity thay đổi theo áp lực họp	Chặn UAT exit, ảnh hưởng tính toàn vẹn dữ liệu, hoặc không có workaround an toàn	Một lỗi ít gặp vẫn cần ưu tiên cao nếu có thể lộ dữ liệu cá nhân hoặc phá traceability lô hàng
Kiểm tra regression sau sửa defect	Defect gốc đạt, luồng liên quan đạt, dữ liệu trước và sau sửa nhất quán	Chỉ kiểm tra màn hình đã sửa; không kiểm tra tích hợp hoặc quyền	Sửa tác động interface, tính giá, tồn kho, phân quyền, import/export hoặc báo cáo	Thay đổi chỉ là nhãn hiển thị và không đổi hành vi, dữ liệu, quyền hay tích hợp: regression có thể giới hạn vào màn hình bị ảnh hưởng
Bảo toàn nguồn chân lý	Liên kết tới artifact canonical, version, status IN_REVIEW	Ghi rule trong defect log nhưng không truy được nguồn	Hai artifact canonical mâu thuẫn hoặc defect buộc diễn giải pháp lý, kế toán, bảo mật	Không có nguồn canonical: dừng quyết định rule; ghi Verification required, không tự tạo rule Nova Foods

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[UAT finding] --> B{Có test basis truy vết?}
    B -- Không --> C[Record Verification required<br/>Không gán lỗi sản phẩm]

    B -- Có --> D{Nhiều expected result hoặc<br/>artifact canonical mâu thuẫn,<br/>hoặc cần diễn giải chuyên môn?}
    D -- Có --> E[Dừng quyết định rule<br/>Gắn Verification required]
    E --> F[Chuyển tới owner có thẩm quyền<br/>Legal, Accounting, Security, QA<br/>hoặc owner phạm vi, chi phí, lịch phát hành]

    D -- Không --> G{Tái hiện được?}
    G -- Có --> H[So sánh actual result với test basis]
    G -- Không --> I{Rủi ro mất dữ liệu, lộ dữ liệu,<br/>sai quyền truy cập, sai sổ sách,<br/>an toàn thực phẩm hoặc traceability?}

    I -- Có --> J[Escalate ngay tới owner có thẩm quyền]
    J --> K[Ghi nhận finding, bảo toàn bằng chứng<br/>và điều tra]
    K --> K_Decision{Điều tra xác nhận defect?}
    K_Decision -- Có --> S[Theo dõi defect trong UAT defect log]
    K_Decision -- Không --> Y[UAT Lead hoặc Business Owner<br/>quyết định đóng theo governance]

    I -- Không --> L{Đã thử 2 lần độc lập<br/>hoặc ở môi trường UAT khác nhau?}
    L -- Không --> M[Thu thập thêm bằng chứng]
    M --> G
    L -- Có --> Y

    H --> N{Lệch test basis?}
    N -- Không --> O{Có yêu cầu hành vi mới<br/>ngoài test basis?}
    O -- Có --> P[Định tuyến change request<br/>tới quy trình phù hợp]
    O -- Không --> Y

    N -- Có --> Q{Chặn UAT exit, ảnh hưởng tính toàn vẹn dữ liệu,<br/>không có workaround an toàn, hoặc tranh chấp đổi<br/>phạm vi, chi phí, lịch phát hành, kiểm soát nghiệp vụ?}
    Q -- Có --> R[Escalate tới owner có thẩm quyền]
    R --> S
    Q -- Không --> S

    S --> T[Sửa defect]
    T --> U{Chỉ đổi nhãn hiển thị,<br/>không đổi hành vi, dữ liệu, quyền, tích hợp?}

    U -- Có --> V[Regression giới hạn<br/>màn hình bị ảnh hưởng]
    U -- Không --> W[Regression defect gốc và các miền bị tác động<br/>interface, tính giá, tồn kho, phân quyền,<br/>import/export hoặc báo cáo]

    V --> W1[Kiểm tra dữ liệu trước/sau sửa nhất quán]
    W --> W1
    W1 --> X{Regression đạt?}
    X -- Không --> S
    X -- Có --> Y

Red flag mạnh: cùng một defect có nhiều expected result; workaround sửa dữ liệu trực tiếp; người test dùng dữ liệu khác kịch bản; developer tự đóng defect; Business Owner yêu cầu “chấp nhận” rủi ro thuộc Legal, Accounting, Security hoặc QA. Với Nova Foods mô phỏng, dữ liệu tổng hợp, Senior BA giữ traceability và chuyển quyết định tới đúng authority; không thay vai trò đó quyết định. Chi tiết thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm và truy xuất nguồn gốc phải giữ nhãn Verification required nếu chưa được owner chuyên môn xác minh từ nguồn chính thức.

Senior Lens

Senior BA không nói “đã đúng” khi bằng chứng chưa đủ. Senior BA tách fact (sự kiện có thể kiểm tra), assumption (giả định dự án), unknown (điểm chưa biết) và recommendation (khuyến nghị). Cách tách này ngăn người đọc biến ý kiến BA thành business rule, approval, hoặc kết luận pháp lý. Với Nova Foods mô phỏng, mọi dữ liệu dưới đây là tổng hợp; IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải baseline hay phê duyệt.

Thành phần ghi nhận	Nội dung phải viết	Không được viết
Fact	Nguồn, thời điểm, ID test, hành vi quan sát được	“Hệ thống chắc chắn sai” khi chưa tái hiện
Assumption	Điều kiện đang tạm giả định và ảnh hưởng	Giả định như quy tắc đã được xác nhận
Unknown	Câu hỏi chưa có bằng chứng, người cần trả lời, hạn chờ	“Không có vấn đề” khi chưa kiểm tra
Recommendation	Phương án, tiêu chí, rủi ro còn lại, thẩm quyền quyết định	“BA phê duyệt phương án”
Decision record	Người có thẩm quyền, quyết định được ghi nhận, liên kết artifact	Gán approval khi chưa có bằng chứng ghi nhận

Ví dụ ghi trong defect record của UAT: “Fact: UAT-INV-042, thực thi ngày 2026-08-07 theo Asia/Ho_Chi_Minh, ghi nhận đơn xuất kho mô phỏng SO-SYN-018 vẫn chuyển trạng thái Posted khi trường lô hàng để trống. Evidence: ảnh chụp màn hình, request/response đã che dữ liệu nhạy cảm, và bước tái hiện 1–5 đính kèm record. Unknown: chưa xác định đây là cấu hình workflow, lỗi validation, hay yêu cầu nghiệp vụ chưa hoàn chỉnh. Recommendation: giữ severity ở mức cần Business Owner và QA Lead xác nhận; không đóng defect bằng nhận định của BA. Reasoning: hành vi quan sát được chứng minh validation hiện thiếu trong kịch bản; chưa chứng minh mọi giao dịch xuất kho phải bắt buộc lô hàng. Verification required: Food Safety Owner và Legal Owner xác nhận nghĩa vụ nghiệp vụ hoặc pháp lý trước khi biến nhận định thành rule.”

Khuyến nghị có thể bảo vệ được khi người khác kiểm tra lại cùng evidence, thấy cùng giới hạn, và biết ai quyết định. Senior BA dùng ngôn ngữ xác suất có điều kiện: “Theo evidence hiện có”, “nếu phạm vi áp dụng là xuất kho hàng cần truy xuất”, “chưa đủ evidence để kết luận”, “đề nghị quyết định bởi Business Owner”. Không dùng “chắc chắn tuân thủ”, “đã được phê duyệt”, hoặc “bắt buộc theo luật” nếu chưa có xác minh từ owner có thẩm quyền và nguồn chính thức hiện hành.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Quan sát UAT] --> B[Ghi Fact và evidence]
    B --> C{Có assumption?}

    C -- Có --> D[Ghi Assumption và ảnh hưởng<br/>không coi là business rule]
    C -- Không --> E{Evidence đủ tái hiện?}
    D --> E

    E -- Không --> F[Ghi Unknown:<br/>câu hỏi, người cần trả lời, hạn chờ]
    F --> G[Yêu cầu bổ sung evidence]
    G --> H[Khuyến nghị có điều kiện<br/>nêu giới hạn evidence]
    H --> I[Giữ IN_REVIEW<br/>không phân loại hoặc đóng defect]

    E -- Có --> J[Giữ phân loại cần xác minh:<br/>defect, configuration hoặc requirement gap]
    J --> K[Khuyến nghị có điều kiện<br/>theo evidence hiện có]
    K --> L[Chuyển xác minh theo thẩm quyền]

    L --> M[Legal Owner:<br/>diễn giải nghĩa vụ pháp lý]
    L --> N[Food Safety Owner:<br/>xác nhận phạm vi nghiệp vụ]
    L --> O[QA Lead:<br/>xác định tiêu chí đóng defect]

    M --> P{Đủ evidence cần thiết?}
    N --> P
    O --> P

    P -- Không --> I
    P -- Có --> Q[Business Owner:<br/>quyết định phương án và ưu tiên]
    Q --> R{Có quyết định được ghi nhận?}

    R -- Có --> S[Tạo decision record<br/>và liên kết artifact]
    R -- Chưa có evidence quyết định --> I

Mẫu câu artifact-ready: “Khuyến nghị chọn phương án B để chặn Posted khi thiếu lô hàng trong phạm vi được Food Safety Owner xác nhận. Cơ sở: UAT-INV-042 tái hiện được ba lần trên dữ liệu tổng hợp và phương án B giảm rủi ro truy vết thiếu. Giới hạn: chưa có xác nhận rằng mọi nhóm hàng đều thuộc phạm vi này. Quyết định và mức ưu tiên thuộc Business Owner; diễn giải nghĩa vụ pháp lý thuộc Legal Owner; tiêu chí đóng defect thuộc QA Lead. Trạng thái ghi nhận: IN_REVIEW, không suy diễn approval.”

12. Associated Template Reference & Completed Artifact

Core

Template là khuôn điền lặp lại để giảm thiếu trường thông tin. Artifact là tệp lưu nội dung đã được kiểm soát. Với Nova Foods Trading & Manufacturing là case mô phỏng, dữ liệu tổng hợp, chỉ được liên kết template khi ID và filename đã có trong nguồn canonical. Evidence: TEMPLATE_MANIFEST chỉ là danh mục kế hoạch; seed không cung cấp ID hoặc filename của template UAT, defect, regression đã được đăng ký. Vì vậy không được tự tạo ID như UAT-TEST-001 hoặc suy diễn tệp mẫu đã tồn tại.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Nhu cầu ghi UAT, defect hoặc regression] --> B{ID và filename có trong nguồn canonical?}
    B -- Có --> C[Liên kết đúng template]
    C --> D[Kiểm tra quality gate]
    D --> E[Consumer dùng artifact theo phạm vi]
    B -- Không --> F[TEMPLATE_MANIFEST chỉ là danh mục kế hoạch<br/>Không có ID hoặc filename đã đăng ký]
    F --> G[Giữ IN_REVIEW, không tạo ID giả]

Applied

Facts: UAT phát hiện giao dịch xuất kho mô phỏng có thể chuyển Posted khi chưa thấy giá trị lô hàng. Current Behavior: learner cần ghi nhận kịch bản, evidence, mức ảnh hưởng và kết quả retest nhưng seed chưa xác nhận template UAT/defect cụ thể. Underlying Need: giữ traceability mà không biến ví dụ học liệu thành cấu hình ERP hoặc rule đã phê duyệt. Options: dùng template đã đăng ký; ghi nội dung tự do không ID; hoặc chờ đăng ký template. Decision Criteria: ID canonical, filename canonical, owner rõ, quality gate rõ, không vượt thẩm quyền. Decision: chỉ tham chiếu TEMPLATE_MANIFEST; chưa gán template ID hoặc filename UAT cụ thể. Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì manifest; QA Lead xác nhận tiêu chí test/defect; Business Owner quyết định ưu tiên nghiệp vụ; Food Safety Owner và Legal Owner xác minh phạm vi truy xuất hoặc nghĩa vụ pháp lý. Artifact: /01-curriculum/TEMPLATE_MANIFEST.md, trạng thái IN_REVIEW, phiên bản v0.9.0. Consequence if Wrong: ID tự tạo làm đứt traceability, người review không tìm được nguồn kiểm soát, và ghi nhận có thể bị hiểu sai là artifact đã baseline hoặc đã được phê duyệt.

Senior Lens

Không phải mọi bảng ghi nhận đều cần template mới. Nếu canonical template đã có và đủ trường, dùng lại. Nếu chưa có template được đăng ký, không tạo bản sao mang tên gần giống. Evidence: TEMPLATE_MANIFEST yêu cầu dừng lô khi ID chưa được đăng ký hoặc khi nội dung đòi hỏi quyết định thuộc thẩm quyền Business Owner, Architect, QA, Legal, Accounting hoặc Compliance. Quality gate tối thiểu phải kiểm tra đúng ID, đúng đường dẫn, trạng thái IN_REVIEW, dữ liệu tổng hợp, owner phù hợp và không diễn đạt approval ngầm định.

Quick Reference

ID hoặc file canonical	Dùng khi	Không dùng khi	Owner	Consumer	Quality gate
TEMPLATE_MANIFEST /01-curriculum/TEMPLATE_MANIFEST.md	Cần xác định template nào đã được quy hoạch, ID nào được đăng ký, hoặc điều kiện dừng của template	Cần thay thế nội dung UAT, defect hoặc regression đã điền; manifest không phải mẫu điền giao dịch	Principal IT Business Analyst / Technical Curriculum Author	BA, Technical Curriculum Author, QA reviewer	Giữ IN_REVIEW, v0.9.0, ngày 2026-08-07; không suy diễn baseline, approval, production readiness
GEN-TMPL-{NNN}	Cần tham chiếu mẫu định danh lô tạo template theo quy tắc manifest	Không dùng như ID template đã đăng ký; {NNN} là placeholder trong quy tắc, không phải định danh Nova Foods cụ thể	Principal IT Business Analyst / Technical Curriculum Author	Người tạo template, QA reviewer	Mỗi lô phải nêu tệp dự kiến, ID template tương ứng, dependency, người ghi nhận, thời điểm Asia/Ho_Chi_Minh, kết quả tạo tệp và nhãn xác minh
TRACEABILITY_ID_REGISTRY /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Cần kiểm tra định danh liên kết giữa requirement, test basis, defect hoặc artifact	Không dùng để tự cấp ID chưa được registry xác nhận	Principal IT Business Analyst / Technical Curriculum Author	BA, QA Lead, reviewer traceability	Chuỗi ID giữ nguyên; mâu thuẫn ID hoặc xung đột nguồn canonical phải escalation theo registry
CANONICAL_BUSINESS_RULES /01-curriculum/CANONICAL_BUSINESS_RULES.md	Defect hoặc regression phụ thuộc business rule đã được catalog kiểm soát	Không dùng để tự kết luận rule vận hành, pháp lý, kế toán hoặc thuế	Principal IT Business Analyst / Technical Curriculum Author; nội dung thuộc owner chuyên môn phù hợp	BA, QA Lead, Business Owner	Không gọi rule là baseline hoặc approved khi chưa có reference minh bạch; Legal, Accounting, Food Safety xác minh nội dung thuộc thẩm quyền
CANONICAL_DATA_DICTIONARY /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Kịch bản UAT cần đối chiếu nghĩa logic của trường dữ liệu, như lô hàng hoặc trạng thái	Không dùng như schema triển khai, cấu hình ERP hoặc evidence production	Principal IT Business Analyst / Technical Curriculum Author	BA, QA, Architect, Data reviewer	Kiểm tra tên trường, định nghĩa logic, phân loại dữ liệu và giới hạn mô phỏng; không suy diễn thiết kế vật lý

Chưa có template UAT, defect hoặc regression với ID và filename cụ thể trong seed được cung cấp. Không gán template giả. Chỉ dùng template cụ thể sau khi TEMPLATE_MANIFEST và registry liên quan ghi nhận canonical ID, filename, owner và quality gate.

Quick Reference

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Lookup checklist này tìm đúng nguồn kiểm soát trước khi dùng UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng), defect và regression (kiểm thử lại phần bị ảnh hưởng sau thay đổi). Nó không thay thế registry canonical và không tạo baseline hay approval.

Mục kiểm tra	Vị trí lookup canonical	Bằng chứng cần thấy	Kết quả được phép dùng
Định danh chapter và đường dẫn	/01-curriculum/CHAPTER_MANIFEST.md	Chapter tương ứng /02-handbook/20-uat-planning-defects-and-regression.md; status IN_REVIEW; version v0.9.0	Xác nhận chapter thuộc corpus, không xác nhận nội dung đã phê duyệt
ID truy vết cho requirement, test, defect	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	ID tồn tại, đúng loại, không trùng và liên kết nguồn	Ghi ID nguyên dạng vào test basis, defect log, regression set
Quy tắc nghiệp vụ làm test basis	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Rule có ID canonical, nguồn và trạng thái xác minh rõ	Thiết kế test theo rule; không tự biến giả định thành rule
Thuộc tính dữ liệu, kiểu dữ liệu, ý nghĩa trường	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Entity, field, định nghĩa logic và phân loại dữ liệu phù hợp	So khớp test data, expected result và defect evidence
Template được phép tra cứu	/01-curriculum/TEMPLATE_MANIFEST.md	Template ID và filename đã đăng ký; trạng thái IN_REVIEW	Dùng template đã đăng ký; không tự đặt ID hoặc filename
Nguồn và giới hạn dẫn chiếu	/00-research/00_SOURCE_MAP.md	Source classification, URL chính thức, safe use boundary	Giữ nhãn Verification required cho nội dung pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật chưa xác minh
Chuỗi học và dependency	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	UAT nhận requirement, acceptance criteria, traceability và test basis từ chapter trước	Không suy diễn business rule mới chỉ để hoàn thành test

Vị trí artifact đã điền cho case Nova Foods: /02-handbook/20-uat-planning-defects-and-regression.md, section 12. Associated Template Reference & Completed Artifact, 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ệ mô phỏng VND. Đây là artifact học liệu đã điền của chapter, không phải template canonical đã baseline và không phải hồ sơ UAT production.

Checklist trước khi tham chiếu artifact đã điền:

• [ ] Đường dẫn chapter khớp chính xác /02-handbook/20-uat-planning-defects-and-regression.md.
• [ ] Status vẫn là IN_REVIEW; không ghi APPROVED, BASELINED hoặc “đã người dùng chấp thuận”.
• [ ] Version là v0.9.0; ngày kiểm soát là 2026-08-07.
• [ ] Tên Nova Foods luôn kèm phạm vi mô phỏng giáo dục và dữ liệu tổng hợp.
• [ ] Mỗi ID requirement, rule, data field, test hoặc defect được đối chiếu tại artifact canonical tương ứng.
• [ ] Nội dung pháp lý, kế toán, thuế, privacy, food-safety hoặc compliance chưa có nguồn chính thức được kiểm tra giữ nhãn Verification required.
• [ ] Không dùng nội dung chapter làm nguồn thay thế cho /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md hoặc /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
• [ ] Không sao chép toàn bộ registry vào chapter; chỉ ghi ID cần thiết và đường dẫn lookup.
• [ ] Nếu manifest không đăng ký template ID hoặc filename cần dùng, dừng tham chiếu; không tự tạo định danh.

Core

Tự-review liên tệp kiểm tra cùng một thông tin có giữ nguyên ID, đường dẫn, trạng thái, phiên bản, ranh giới thẩm quyền và nhãn xác minh giữa các nguồn canonical hay không. Mục tiêu không phải xác nhận Nova Foods đúng ngoài đời thật. Mục tiêu là chặn chapter tạo ra rule ERP, approval, baseline hoặc nghĩa vụ pháp lý không có bằng chứng. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Source mermaid — có thể chỉnh sửa

flowchart TB
    A[Soát chapter] --> B[Đối chiếu CHAPTER_MANIFEST<br/>TRACEABILITY_ID_REGISTRY<br/>CANONICAL_BUSINESS_RULES<br/>CANONICAL_DATA_DICTIONARY<br/>TEMPLATE_MANIFEST<br/>SOURCE_MAP]
    B --> C{Khớp ID, đường dẫn, trạng thái, version,<br/>ngày, locale, tiền tệ, nhãn xác minh,<br/>thẩm quyền, rule, data term, template,<br/>nguồn và giới hạn trích dẫn?}
    C -- Có --> D[Ghi kết quả self-review]
    D --> H[Bàn giao chapter<br/>vẫn trạng thái IN_REVIEW]
    C -- Không --> E{Đủ bằng chứng ghi nhận lệch?}
    E -- Có --> F[Ghi open issue]
    E -- Chưa đủ --> G[Gắn Verification required]
    F --> I[Escalate đúng owner]
    G --> I
    I --> J[Đối chiếu lại tiêu chí bàn giao]
    J --> K{Lệch đã xử lý hoặc ghi nhận<br/>theo tiêu chí bàn giao?}
    K -- Có --> H
    K -- Không --> L[Giữ IN_REVIEW<br/>không bàn giao]

Hạng mục đối chiếu	Nguồn canonical	Kết quả bắt buộc trước bàn giao
Trạng thái, version, ngày, locale	/01-curriculum/CHAPTER_MANIFEST.md	Giữ IN_REVIEW, v0.9.0, 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND.
ID và traceability	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Không tự tạo, đổi tên, tái sử dụng ID canonical.
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Không nâng project assumption thành business rule đã xác nhận.
Thuật ngữ dữ liệu	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Không suy diễn field, giá trị, retention hay cấu trúc ERP.
Template và phạm vi template	/01-curriculum/TEMPLATE_MANIFEST.md	Không nói template đã được tạo, baseline hoặc approved.
Nguồn và giới hạn trích dẫn	/00-research/00_SOURCE_MAP.md	Không bịa điều khoản, trích dẫn, nghĩa vụ pháp lý hoặc kết luận compliance.

Applied

Facts: Chapter nằm tại /02-handbook/20-uat-planning-defects-and-regression.md; corpus đang IN_REVIEW, v0.9.0, ngày 2026-08-07. Current Behavior: UAT (User Acceptance Testing, kiểm thử chấp nhận người dùng) có thể tham chiếu test case, defect và regression nhưng chưa có baseline hay approval. Underlying Need: Bàn giao chapter mà không biến ví dụ mô phỏng thành quyết định vận hành Nova Foods. Options: (1) Xóa mọi nhãn chưa xác minh; (2) giữ nhãn Verification required và escalation; (3) tự kết luận theo hiểu biết BA. Decision Criteria: giữ traceability, không vượt thẩm quyền, không mất rủi ro pháp lý hoặc chất lượng. Decision: Chọn (2). Authority: Principal IT Business Analyst / Technical Curriculum Author ghi nhận và điều phối; owner chuyên môn kết luận phần thuộc thẩm quyền. Artifact: Bảng review trong chapter này, trạng thái IN_REVIEW. Consequence if Wrong: Chapter có thể bị hiểu sai là tài liệu production, legal sign-off, accounting sign-off hoặc user approval.

Senior Lens

Open issue hoặc Verification required	Bằng chứng	Escalation owner	Điều kiện đóng
Chưa có baseline reference	CHAPTER_MANIFEST ghi chưa có baseline tại v0.9.0.	Principal IT Business Analyst / Technical Curriculum Author	Có baseline reference được ghi minh bạch trong artifact kiểm soát.
Chưa có approval reference	CHAPTER_MANIFEST và TEMPLATE_MANIFEST ghi không có approval ngầm định.	Business Owner	Có approval reference từ vai trò có thẩm quyền; không suy diễn từ trạng thái IN_REVIEW.
Diễn giải yêu cầu bảo vệ dữ liệu cá nhân	Nguồn luật và nghị định chỉ cho phép dùng trong ranh giới đã xác minh; yêu cầu hệ thống cần legal-owner verification.	Legal Owner	Legal Owner xác minh diễn giải và phạm vi áp dụng.
Diễn giải kế toán, thuế, hóa đơn	Luật Kế toán và Nghị định 123/2020/NĐ-CP yêu cầu vai trò được ủy quyền xác nhận.	Accounting Owner	Accounting Owner xác nhận nội dung trước khi dùng như rule nghiệp vụ.
Traceability hoặc recall thực phẩm	Luật An toàn thực phẩm cần domain-owner và legal verification.	Business Owner; Legal Owner	Hai owner xác minh phạm vi nghiệp vụ và pháp lý.
Kiểm thử bảo mật hoặc API	OWASP là good practice; không phải luật Việt Nam.	Security; Architect	Security và Architect xác nhận rủi ro, control, kiến trúc mô phỏng.
Đủ test basis, defect workflow, regression scope	ISTQB là nguồn thuật ngữ; mức chấp nhận UAT không tự suy ra từ syllabus.	QA reviewer; Business Owner	QA reviewer kiểm tra test basis; Business Owner xác nhận tiêu chí chấp nhận.

Không bàn giao như APPROVED, BASELINED, compliant hoặc production-ready. Bàn giao chỉ giữ trạng thái IN_REVIEW; open issue và Verification required phải đi cùng owner nêu trên.

Quick Reference

Checklist trước handoff: kiểm tra đúng đường dẫn chapter; kiểm tra IN_REVIEW và v0.9.0; đối chiếu CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TEMPLATE_MANIFEST, 00_SOURCE_MAP; giữ Nova Foods là mô phỏng; giữ dữ liệu tổng hợp; ghi mọi lệch thành open issue hoặc Verification required; gán đúng escalation owner; không ghi nhận user approval.