18 Testing Fundamentals For Ba

Trường kiểm soát	Giá trị
Đường dẫn tệp	/02-handbook/18-testing-fundamentals-for-ba.md
Document title	18 Testing Fundamentals For Ba
Status	IN_REVIEW
Version	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	Asia/Ho_Chi_Minh
Locale	vi-VN
Bối cảnh	Việt Nam; tiền tệ mô phỏng VND
Case study	Nova Foods Trading & Manufacturing — mô phỏng giáo dục; chỉ dữ liệu tổng hợp
Nguồn thuật ngữ chính	ISTQB CTFL Syllabus v4.0.1 — nguồn chính đã xác minh trong /00-research/00_SOURCE_MAP.md
Nguồn quản trị	CHAPTER_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY
Ranh giới thẩm quyền	Học liệu không xác nhận requirement Nova Foods, không tạo baseline, approval, quyết định pháp lý, kế toán, bảo mật, vận hành hay production
Baseline reference	Chưa có baseline reference tại v0.9.0
Approval reference	Chưa có approval reference tại v0.9.0

1. Concept l? g??

Core

Testing fundamentals là nền tảng để BA hiểu kiểm thử phần mềm từ điểm xuất phát: kiểm tra có mục đích, có căn cứ, có bằng chứng. Phần mềm không được gọi là “đúng” vì màn hình mở được hoặc vì người phát triển nói đã xong. Phần mềm chỉ có thể được đánh giá khi so sánh hành vi quan sát được với điều đã được xác định trước.

Trong bối cảnh BA, testing là hoạt động tìm và cung cấp thông tin về mức độ sản phẩm đáp ứng nhu cầu, requirement, business rule, dữ liệu và điều kiện chấp nhận đã được ghi nhận. Testing không phải hành động chứng minh hệ thống hoàn hảo. Lý do: không thể kiểm tra mọi tổ hợp dữ liệu, thời điểm, quyền truy cập, thiết bị và lỗi kỹ thuật. Mục tiêu thực tế là giảm rủi ro bằng chứng cứ đủ tin cậy cho quyết định tiếp theo.

Nền tảng kiểm thử gồm ba phần phải nối được với nhau:

Phần	Câu hỏi phải trả lời	Bằng chứng cần có
Điều mong đợi	Hệ thống phải làm gì, không làm gì, trong điều kiện nào?	Requirement, business rule, acceptance criteria, data definition
Hành vi thực tế	Hệ thống đã phản hồi thế nào khi nhận dữ liệu và điều kiện cụ thể?	Kết quả chạy test, log, ảnh chụp, phản hồi API, dữ liệu ghi nhận
So sánh và kết luận	Khác biệt có tồn tại không; khác biệt gây rủi ro gì?	Test result, defect hoặc quyết định chấp nhận có truy vết

BA không thay QA quyết định kỹ thuật kiểm thử. BA giữ chất lượng của test basis: tập thông tin làm căn cứ thiết kế và đánh giá kiểm thử. Nếu requirement mơ hồ, QA vẫn có thể chạy test, nhưng kết quả không trả lời chắc được hệ thống có đáp ứng nhu cầu hay không. Suy luận này có căn cứ: kết quả chỉ đáng tin khi có tiêu chí để đối chiếu; thiếu tiêu chí thì “pass” hoặc “fail” không có nghĩa nghiệp vụ rõ ràng.

Testing fundamentals cũng phân biệt hai đối tượng. Product là sản phẩm đang được kiểm tra, như màn hình ERP, API, báo cáo hoặc luồng xử lý. Work product là artifact tạo ra để mô tả, xây dựng hoặc kiểm tra sản phẩm, như requirement, business rule, test case và defect report. BA thường tác động mạnh vào work product trước khi tác động đó trở thành lỗi trong product.

Khái niệm chương này giới hạn ở nền tảng tư duy kiểm thử cho BA: vì sao cần đối chiếu kỳ vọng với hành vi thực tế, vì sao bằng chứng cần truy vết, và vì sao chất lượng requirement ảnh hưởng trực tiếp chất lượng test. Chương này không xác lập quy trình QA của Nova Foods, không định nghĩa test technique, không thiết kế test case, không xác nhận tuân thủ pháp lý, không kết luận hệ thống ERP mô phỏng đạt chất lượng production.

Core

Trong kiểm thử, BA cần mô tả điều cần kiểm tra bằng câu có cấu trúc, không bằng cảm giác. Cấu trúc tối thiểu là actor, action, object, outcome. Bốn thành phần này biến câu “hệ thống phải hoạt động đúng” thành nội dung có thể hiểu, thiết kế kiểm thử và truy vết.

Thuật ngữ	Nghĩa Việt ngắn	Câu hỏi BA phải trả lời	Ví dụ dữ liệu tổng hợp Nova Foods
Actor	Tác nhân thực hiện hoặc khởi phát việc	Ai hoặc hệ thống nào làm? Có quyền nào?	Nhân viên kho
Action	Hành động tác nhân yêu cầu hệ thống thực hiện	Làm việc gì, tại thời điểm nào?	Xác nhận nhập kho
Object	Đối tượng bị tác động	Làm trên dữ liệu, chứng từ, hàng hóa hay bản ghi nào?	Phiếu nhập kho GRN-SIM-0001
Outcome	Kết quả quan sát, kiểm chứng được	Sau hành động, trạng thái, dữ liệu, thông báo nào phải có?	Phiếu đổi sang Received; tồn kho tăng theo số lượng nhận
Test	Kiểm thử	Thực hiện kiểm tra có chủ đích để tìm khác biệt giữa kết quả thực tế và kết quả mong đợi	Kiểm tra xác nhận nhập kho với số lượng hợp lệ
Test case	Ca kiểm thử	Tập điều kiện, bước thực hiện, dữ liệu và kết quả mong đợi để kiểm tra một điều kiện	Nhân viên kho xác nhận GRN-SIM-0001 nhận 120 thùng
Expected result	Kết quả mong đợi	Điều hệ thống phải thể hiện nếu hành vi đúng theo test basis	Trạng thái Received; tồn kho tăng 120 thùng
Actual result	Kết quả thực tế	Điều quan sát được khi chạy test	Ghi nhận bởi người kiểm thử, không được BA suy đoán trước
Test basis	Cơ sở kiểm thử	Artifact làm bằng chứng để suy ra điều cần kiểm tra, như requirement, business rule, acceptance criteria	Requirement hoặc business rule đã được quản trị; không phải lời nói nhớ lại
Defect	Lỗi/phát hiện lỗi	Khác biệt có bằng chứng giữa actual result và expected result	Tồn kho tăng 100 thay vì 120, khi test basis yêu cầu tăng theo số lượng nhận
Pass / Fail	Đạt / Không đạt	Actual result có khớp đầy đủ expected result không?	Pass chỉ khi trạng thái và tồn kho đều đúng

Mẫu câu kiểm thử tối thiểu:

[Actor] thực hiện [Action] trên [Object], hệ thống tạo [Outcome].

Ví dụ: “Nhân viên kho xác nhận nhập kho trên phiếu GRN-SIM-0001, hệ thống cập nhật trạng thái phiếu thành Received và tăng tồn kho theo số lượng đã nhận.” Câu có thể kiểm thử vì nhận diện được người thao tác, thao tác, bản ghi chịu tác động và kết quả cần quan sát.

Phân biệt quan trọng: actor không luôn là con người. ERP có thể là actor khi một tác vụ nền gửi dữ liệu sang API. Action không phải mục tiêu mơ hồ như “quản lý kho tốt hơn”; nó phải là thao tác hoặc sự kiện xác định. Object không phải phạm vi chung như “module kho”; nó phải là đối tượng kiểm tra cụ thể. Outcome không phải “thành công”; nó phải là thay đổi hay thông báo nhìn thấy và đối chiếu được.

Ranh giới khái niệm: bốn thành phần trên giúp diễn đạt hạt nhân của điều cần kiểm tra. Chúng chưa thay thế business rule, phân quyền, dữ liệu biên, tiêu chí chấp nhận, thiết kế test case hay bằng chứng chạy test. Nova Foods Trading & Manufacturing chỉ là case study mô phỏng; GRN-SIM-0001, trạng thái và số lượng nêu trên là dữ liệu tổng hợp, không xác nhận cấu hình hay quy trình ERP thực tế.

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: nhân viên kho xác nhận nhận 100 thùng nguyên liệu cho một phiếu nhập kho. Hệ thống ERP phải lưu số lượng nhận và trạng thái phiếu. Testing kiểm tra bằng chứng quan sát được: khi nhập số lượng hợp lệ, hệ thống lưu đúng dữ liệu và hiển thị kết quả phù hợp; khi nhập giá trị không hợp lệ, hệ thống chặn hoặc báo lỗi theo requirement đã được xác định.

Mục	Nội dung
Facts	Phiếu nhập kho mô phỏng có số lượng đặt 100 thùng. Nhân viên kho nhập số lượng nhận 100. Đơn vị tiền tệ bối cảnh là VND, nhưng ví dụ này không xử lý giá, thuế hay hạch toán.
Current Behavior	Chưa có bằng chứng kiểm thử cho biết ERP lưu số lượng, từ chối số âm, hay xử lý số lượng lớn hơn số lượng đặt.
Underlying Need	Business cần biết hành vi hệ thống có khớp requirement trước khi dùng kết quả để vận hành quy trình tiếp theo. Đây là nhu cầu giảm rủi ro sai dữ liệu, không phải bằng chứng hệ thống đạt tuân thủ hay sẵn sàng production.
Options	Kiểm tra thủ công một giá trị hợp lệ; kiểm tra cả giá trị hợp lệ và không hợp lệ; chỉ đọc mô tả requirement mà không chạy kiểm tra.
Decision Criteria	Có đầu vào xác định; có kết quả mong đợi kiểm chứng được; bao phủ hành vi hợp lệ và từ chối dữ liệu sai; không suy diễn quy tắc chưa có nguồn canonical.
Decision	Dùng ít nhất hai test condition: nhận 100 thùng và nhận -1 thùng. Kết quả mong đợi phải lấy từ requirement hoặc business rule đã được xác minh trong artifact canonical.
Authority	BA làm rõ test basis và traceability. QA xác định chiến lược, thực thi hoặc xác nhận kiểm thử theo phạm vi được giao. Business Owner quyết định ý nghĩa nghiệp vụ. Không vai trò nào được suy diễn approval từ ví dụ này.
Artifact	Test case hoặc test condition liên kết tới requirement, business rule và kết quả thực tế. Tại v0.9.0, IN_REVIEW, chưa có baseline hay approval reference.
Consequence if Wrong	Hệ thống có thể nhận số lượng âm hoặc lưu sai số lượng. Tồn kho mô phỏng sau đó sai; các báo cáo, quy trình mua hàng hoặc quyết định vận hành dựa trên dữ liệu đó cũng có thể sai.

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

flowchart TB
    A{"Test basis canonical đủ để xác định kết quả mong đợi?"}

    A -->|Không| B["Blocked: thiếu test basis"]
    B --> C["Business Owner xác nhận ý nghĩa nghiệp vụ"]
    C --> D["Artifact owner cập nhật requirement hoặc business rule canonical"]
    D --> E["BA và QA xác minh traceability"]
    E --> A

    A -->|Có| F{"Thực thi condition 100 thùng?"}
    F -->|Không| F1["QA/Tester ghi Not Run và lý do vào test artifact"]
    F -->|Có| F2["QA/Tester nhập 100 thùng"]
    F2 --> F3["Quan sát số lượng, trạng thái và phản hồi"]
    F3 --> F4{"Kết quả thực tế khớp kết quả mong đợi?"}
    F4 -->|Có| F5["QA/Tester ghi Pass và lưu evidence vào test artifact"]
    F4 -->|Không| F6["QA/Tester ghi Fail và lưu evidence vào test artifact"]

    F1 --> G{"Thực thi condition -1 thùng?"}
    F5 --> G
    F6 --> G

    G -->|Không| G1["QA/Tester ghi Not Run và lý do vào test artifact"]
    G -->|Có| G2["QA/Tester nhập -1 thùng"]
    G2 --> G3["Quan sát ERP từ chối hoặc báo lỗi theo test basis"]
    G3 --> G4{"Kết quả thực tế khớp kết quả mong đợi?"}
    G4 -->|Có| G5["QA/Tester ghi Pass và lưu evidence vào test artifact"]
    G4 -->|Không| G6["QA/Tester ghi Fail và lưu evidence vào test artifact"]

    G1 --> H["Tổng hợp sau khi cả hai condition có trạng thái"]
    G5 --> H
    G6 --> H

    H --> I{"Có condition Fail?"}
    I -->|Có| J["Kết quả tổng hợp: có Fail"]
    J --> K["QA/Tester tạo defect hoặc issue liên kết evidence và test basis"]
    K --> L["Owner triage và xử lý theo quy trình defect canonical"]
    J --> M["Số lượng hoặc trạng thái phiếu có thể sai"]
    M --> N["Quy trình tồn kho tiếp theo có thể dùng dữ liệu sai"]

    I -->|Không| O{"Có condition Not Run?"}
    O -->|Có| P["Kết quả tổng hợp: có Not Run; chưa đủ kết quả cho toàn bộ phạm vi"]
    O -->|Không| Q["Kết quả tổng hợp: tất cả Pass"]
    Q --> R["Ghi nhận hành vi khớp test basis trong phạm vi đã kiểm tra"]

    J --> S["Kết quả kiểm thử không phải deployment approval"]
    P --> S
    R --> S

Ranh giới khái niệm: testing là hoạt động tạo và dùng kiểm tra để tìm bằng chứng về mức độ hành vi thực tế khớp với test basis. Testing không tự viết requirement, không tự quyết định business rule, không chứng minh không còn lỗi, không thay thế UAT, không cấp phép triển khai, không xác nhận tuân thủ pháp luật, kế toán, an toàn thực phẩm, bảo mật hoặc bảo vệ dữ liệu cá nhân.

Loại trừ: ví dụ không xác định quy tắc tồn kho Nova Foods thật, không thiết kế màn hình ERP, không cấu hình API, không tính giá trị VND, không tạo chứng từ kế toán, không diễn giải luật. Các nội dung đó cần artifact canonical và thẩm quyền Business Owner, Architect, QA, Accounting Owner, Legal Owner hoặc Security phù hợp.

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

Core

Testing tồn tại vì phần mềm có thể chạy được nhưng vẫn làm sai điều nghiệp vụ cần. Requirement, business rule, cấu hình ERP và dữ liệu nhập đều có thể bị hiểu khác nhau giữa Business Owner, BA, Developer và QA. Nếu không kiểm tra có cấu trúc, lỗi chỉ lộ khi dữ liệu đã đi qua quy trình kho, bán hàng hoặc kế toán mô phỏng; khi đó chi phí sửa không chỉ là sửa code mà còn là dò nguyên nhân, sửa dữ liệu và kiểm tra lại các luồng liên quan.

Testing ngăn bốn rủi ro chính:

Rủi ro	Cơ chế gây lỗi	Testing ngăn bằng cách nào
Mơ hồ	Câu chữ không nêu điều kiện, dữ liệu biên hoặc kết quả khi lỗi	Chuyển yêu cầu thành điều kiện kiểm tra và kết quả mong đợi quan sát được
Rework	Developer xây theo một cách hiểu, người dùng kỳ vọng cách khác	Phát hiện chênh lệch trước khi luồng được dùng rộng hơn
Lỗi dây chuyền	Một dữ liệu sai đi từ giao dịch nguồn sang báo cáo hoặc tích hợp	Kiểm tra đầu vào, xử lý và đầu ra trên luồng có liên kết
Rủi ro quản trị	Không truy được kiểm tra nào chứng minh requirement đã được xem xét	Liên kết test basis, kiểm tra, kết quả thực tế và defect khi có

Testing không tạo ra yêu cầu đúng. Testing kiểm tra hành vi thực tế so với test basis, tức cơ sở kiểm thử gồm requirement, business rule, acceptance criteria hoặc quyết định đã được ghi nhận. Không có test basis rõ, kết quả “đạt” không có nghĩa nghiệp vụ rõ ràng.

Applied

Trong Nova Foods Trading & Manufacturing mô phỏng, một luồng nhận hàng cho phép nhân viên kho nhập số lượng nhận. Nếu không có kiểm tra, hệ thống có thể lưu giá trị -5 vì trường chỉ kiểm tra kiểu số. Hành vi này không lỗi kỹ thuật theo nghĩa màn hình vẫn lưu thành công, nhưng tạo dữ liệu tồn kho mô phỏng không hợp lý.

Hậu quả quan sát được: giao dịch nhận hàng hiển thị thành công; tồn kho mô phỏng giảm thay vì tăng; báo cáo dùng số tồn đó có thể cho kết quả khác kỳ vọng; nhóm xử lý phải xác định giao dịch nào gây sai và kiểm tra các xử lý phụ thuộc. Testing đặt kiểm tra tại điểm rẻ nhất: trước khi dữ liệu sai đi tiếp.

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

flowchart TB
    A[Nhân viên kho nhập số lượng nhận] --> B{Số lượng nhận không âm?}
    B -->|Có| C[Hệ thống lưu giao dịch]
    C --> D[Tester kiểm tra giao dịch và tồn kho]
    D --> E{Kết quả đúng kỳ vọng?}
    E -->|Có| F[Đạt kỳ vọng]
    E -->|Không| G[Phát hiện sai lệch trước luồng sau]
    B -->|Không| H[Hệ thống từ chối lưu và hiển thị lỗi]
    H --> I[Tester kiểm tra từ chối lưu và lỗi hiển thị]
    I --> J{Kết quả đúng kỳ vọng?}
    J -->|Có| F
    J -->|Không| G

Senior Lens

Rủi ro lớn không phải chỉ là “có bug”. Rủi ro lớn là tổ chức không biết bug vi phạm điều gì, ảnh hưởng luồng nào, ai cần quyết định cách xử lý và có cần kiểm tra hồi quy hay không. Kiểm thử hồi quy là kiểm tra lại hành vi cũ sau thay đổi, nhằm tìm tác động ngoài phạm vi sửa trực tiếp.

BA dùng testing để làm lộ khoảng trống yêu cầu sớm. Khi chưa xác định được kết quả mong đợi cho một tình huống, vấn đề thường nằm ở requirement hoặc business rule chưa đủ rõ, không nằm ở việc viết test case. BA ghi nhận khoảng trống và chuyển người có thẩm quyền quyết định; BA không tự biến cách hiểu cá nhân thành quy tắc Nova Foods.

Nova Foods là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Ví dụ không xác nhận cấu hình ERP thực tế, không xác nhận quy tắc tồn kho thực tế, không tạo approval, baseline hoặc quyền triển khai production.

Quick Reference

Nếu thiếu testing	Hậu quả cần tránh
Không có kết quả mong đợi	Mỗi người đánh giá “đúng” theo cách riêng
Chỉ kiểm tra luồng thành công	Dữ liệu biên và xử lý lỗi đi vào vận hành mô phỏng
Không liên kết với test basis	Không giải thích được kiểm tra đang bảo vệ requirement nào
Sửa lỗi nhưng không kiểm tra lại luồng liên quan	Lỗi cũ hoặc lỗi mới tái xuất ở phần đã phụ thuộc
Gọi “đã test” nhưng không lưu kết quả	Không có bằng chứng quản trị để xem xét phạm vi kiểm tra

Applied

Nova Foods Trading & Manufacturing là case mô phỏng, dữ liệu tổng hợp. Tình huống: ERP tạo đơn bán hàng cho đại lý, rồi kho xác nhận xuất hàng. Testing tồn tại để biến câu “hệ thống chạy được” thành bằng chứng rằng hành vi đã kiểm tra khớp nhu cầu đã quyết định.

Mục	Trước khi có testing có cấu trúc	Sau khi có testing có cấu trúc
Facts	Người dùng nhập đơn SO-TRAIN-001, trạng thái hiển thị Confirmed; kho thấy đơn trong danh sách xuất. Đây là quan sát mô phỏng.	Cùng đơn SO-TRAIN-001 được kiểm tra theo dữ liệu đầu vào, bước chạy, kết quả mong đợi và kết quả thực tế.
Current Behavior	Nhân viên kho xuất hàng dù dòng đơn có số lượng bằng 0, vì danh sách kho chỉ lọc theo trạng thái Confirmed.	Test kiểm tra điều kiện: chỉ dòng có số lượng lớn hơn 0 mới được đưa vào danh sách xuất. Dòng bằng 0 phải bị chặn hoặc không xuất hiện theo quyết định nghiệp vụ.
Underlying Need	Nhu cầu ngầm: kho không được xử lý dòng hàng không có số lượng giao. Không có tiêu chí kiểm tra thì đội dự án có thể hiểu khác nhau.	Nhu cầu được chuyển thành kết quả có thể xác minh: nhập số lượng 0, xác nhận đơn, mở danh sách xuất; hệ thống không tạo tác vụ xuất cho dòng đó.
Options	Sửa giao diện kho để ẩn dòng 0; chặn ngay khi xác nhận đơn; cho phép xuất nhưng cảnh báo.	So sánh từng phương án với điểm kiểm tra: ngăn sai sót sớm, giữ dữ liệu nhất quán, không tự suy diễn quy tắc chưa có thẩm quyền.
Decision Criteria	Không ghi rõ tiêu chí, nên developer, QA và kho có thể chọn khác nhau.	Tiêu chí: điểm chặn phải xác định; thông báo phải quan sát được; kết quả phải lặp lại bằng cùng dữ liệu mô phỏng.
Decision	Không có quyết định được ghi nhận; trạng thái Confirmed bị hiểu như được phép xuất toàn bộ dòng.	Quyết định cho case học liệu: test phải ghi rõ dữ liệu, bước, expected result và actual result trước khi kết luận pass hoặc fail. Đây không phải quyết định vận hành Nova Foods.
Authority	Không xác định người quyết định quy tắc xuất hàng.	Business Owner cần quyết định quy tắc nghiệp vụ; QA kiểm tra bằng chứng; BA duy trì liên kết giữa nhu cầu và test. Không có approval được ghi nhận.
Artifact	Chỉ có quan sát miệng: “đơn đã lên kho”. Không truy ngược được điều gì đã được kiểm tra.	Bản ghi test trong phạm vi /02-handbook/18-testing-fundamentals-for-ba.md: SO-TRAIN-001, số lượng 0, điều kiện kiểm tra, expected result, actual result, trạng thái test.
Consequence if Wrong	Kho có thể xử lý dòng không giao; đội dự án chỉ phát hiện khi thao tác thực tế mô phỏng đã khác kỳ vọng. Sửa muộn có thể đụng giao diện, logic xác nhận và danh sách kho.	Nếu expected result sai, test vẫn có thể chạy đúng kỹ thuật nhưng xác minh sai nhu cầu. Cần trả câu hỏi về Business Owner, không tự đổi rule.

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

flowchart TB
    A[Nhập đơn SO-TRAIN-001<br/>Số lượng = 0] --> B[Ghi expected result<br/>Không tạo tác vụ xuất]
    B --> C[QA xác nhận đơn<br/>Mở danh sách xuất]
    C --> D[QA quan sát actual result<br/>Có hoặc không có tác vụ xuất]
    D --> E[Ghi actual result<br/>và bằng chứng quan sát]
    E --> F{Actual result có khớp<br/>expected result?}

    F -->|Khớp| G[Ghi Pass]
    F -->|Không khớp| H{Bằng chứng đã đủ?}

    H -->|Chưa đủ| I[QA thu thập thêm bằng chứng]
    I --> D

    H -->|Đủ| J[Ghi Fail theo expected result<br/>Chưa xác nhận defect]
    J --> K[Chuyển câu hỏi quy tắc<br/>cho Business Owner]
    K --> L{Quyết định nghiệp vụ<br/>được ghi nhận?}

    L -->|Chưa có| M[Chờ Business Owner<br/>Không tự đổi rule]
    L -->|Xác nhận expected result| N[Giữ Fail<br/>Ghi defect kèm bằng chứng]
    L -->|Sửa expected result| O[BA cập nhật expected result<br/>và liên kết test]
    O --> C

Khác biệt quan sát được không phải số lỗi hay tỷ lệ thành công. Khác biệt là khả năng chỉ ra chính xác dữ liệu nào đã chạy, hành vi nào đã thấy, kết quả nào được mong đợi, và ai phải quyết định khi kết quả không khớp. Testing giảm rework vì phát hiện lệch nghĩa trước khi đội kỹ thuật mở rộng lệch đó sang các màn hình, tích hợp hoặc báo cáo khác.

Core

Trong kiểm thử, nhầm loại phát biểu làm sai test basis (cơ sở kiểm thử): QA có thể kiểm tra điều chưa được quyết định, hoặc bỏ qua điều cần xác minh. Với Nova Foods Trading & Manufacturing là mô phỏng giáo dục, BA phải gắn nhãn từng phát biểu theo bằng chứng, không theo mức độ người nói tự tin.

Loại	Nghĩa từ đầu	Bằng chứng tối thiểu	BA xử lý	Được viết thành test condition?
Verified fact — sự thật đã xác minh	Điều đã có bằng chứng kiểm tra được	Artifact nguồn, trạng thái, phiên bản, ngày, ID hoặc quan sát tái lập được	Trích đúng nguồn và phạm vi	Có, nếu liên quan phạm vi test
Stakeholder input — ý kiến đầu vào của bên liên quan	Nhu cầu, vấn đề hoặc cách hiểu do vai trò nêu	Người nói, vai trò, thời điểm, ngữ cảnh	Ghi nguồn; chưa biến thành rule	Chưa, trừ khi đã được quyết định
Project assumption — giả định dự án	Điều tạm coi đúng để tiếp tục phân tích khi chưa có bằng chứng đủ	Lý do giả định, rủi ro nếu sai, chủ thể xác minh	Gắn nhãn Assumption; tạo việc xác minh	Không; chỉ tạo test khám phá rủi ro nếu được QA thống nhất
Decision — quyết định	Lựa chọn đã được vai trò có thẩm quyền ghi nhận	Options, criteria, authority, artifact quyết định	Liên kết quyết định vào requirement và test basis	Có
Verification-required claim — khẳng định cần xác minh	Phát biểu có thể ảnh hưởng pháp lý, kế toán, bảo mật, thuế, an toàn thực phẩm hoặc vận hành nhưng nguồn/thẩm quyền chưa đủ	Nguồn chính thức hiện hành và xác nhận owner phù hợp	Gắn Verification required; không suy diễn thành bắt buộc	Chưa

Quy tắc phân loại: câu “kho phải chặn xuất hàng khi lô hết hạn” không tự thành fact vì nghe hợp lý. Nó là stakeholder input nếu do Quản lý Kho nêu; là assumption nếu nhóm tạm dùng để thiết kế luồng; là decision chỉ khi Business Owner có thẩm quyền ghi nhận lựa chọn; là verification-required claim nếu được trình bày như nghĩa vụ an toàn thực phẩm mà chưa có xác minh Legal Owner và domain owner. Fact đã xác minh tại corpus chỉ là Nova Foods là case mô phỏng, dữ liệu tổng hợp, Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07; các điều này không chứng minh cấu hình ERP hay rule vận hành thực.

Applied

Trường	Nội dung Nova Foods mô phỏng, dữ liệu tổng hợp
Facts	CHAPTER_MANIFEST và CANONICAL_BUSINESS_RULES có trạng thái IN_REVIEW, phiên bản v0.9.0; không có baseline hay approval reference.
Current Behavior	Nhóm viết test case: “ERP bắt buộc chặn xuất lô hết hạn” và đặt expected result là chặn giao dịch.
Underlying Need	Kho muốn giảm nguy cơ chọn nhầm lô trong quy trình xuất hàng. Đây là nhu cầu nêu bởi stakeholder, chưa phải rule đã quyết định.
Options	1. Chặn toàn bộ xuất lô theo ngày hết hạn. 2. Cảnh báo và yêu cầu quyền override. 3. Không xử lý tại ERP, kiểm soát ngoài hệ thống.
Decision Criteria	Mức rủi ro an toàn thực phẩm, quy trình kho, khả năng truy vết, thẩm quyền Business Owner, xác minh domain/legal.
Decision	Chưa có quyết định được ghi nhận. Không chọn option nào trong tài liệu này.
Authority	Business Owner quyết định vận hành; domain owner và Legal Owner xác minh khẳng định liên quan an toàn thực phẩm; QA xác định cách kiểm thử sau khi có test basis hợp lệ.
Artifact	Ghi vào /01-curriculum/CANONICAL_BUSINESS_RULES.md theo nhãn stakeholder input hoặc Verification required; không ghi thành canonical rule.
Consequence if Wrong	Nếu QA kiểm thử “phải chặn” như rule đã duyệt, đội phát triển có thể xây chặn sai phạm vi. Nếu cần cho phép xuất có kiểm soát, luồng giao hàng bị dừng; nếu cần chặn nhưng chỉ cảnh báo, rủi ro vận hành không được phát hiện trước phát hành.

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

flowchart TB
    A["Khẳng định về Nova Foods mô phỏng"] --> B{"Có bằng chứng artifact truy vết được?"}

    B -- "Có" --> C["Verified fact về nội dung, trạng thái và phiên bản artifact"]
    B -- "Không" --> D{"Đây là ý kiến hoặc nhu cầu của stakeholder?"}

    C --> E{"Có baseline hoặc approval reference<br/>tạo test basis hợp lệ?"}
    E -- "Có" --> T["Test basis hợp lệ"]
    E -- "Không" --> F["Chưa phải test basis hợp lệ"]

    D -- "Có" --> G["Ghi nhãn Stakeholder input trong<br/>/01-curriculum/CANONICAL_BUSINESS_RULES.md"]
    D -- "Không" --> H["Ghi nhãn Verification required trong<br/>/01-curriculum/CANONICAL_BUSINESS_RULES.md"]

    F --> I["Không coi là canonical rule<br/>hoặc expected result bắt buộc"]
    G --> I
    H --> I

    I --> J{"Có dùng khẳng định chưa được quyết định<br/>làm expected result bắt buộc?"}
    J -- "Có" --> K["Hậu quả nếu sai:<br/>chặn sai phạm vi làm dừng giao hàng;<br/>chỉ cảnh báo khi cần chặn làm rủi ro vận hành<br/>không được phát hiện trước phát hành"]
    J -- "Không" --> L["Giữ trạng thái chưa có decision"]
    K --> L

    L --> M{"Có khẳng định domain hoặc legal liên quan?"}
    M -- "Có" --> N["Domain Owner và Legal Owner<br/>xác minh khẳng định tương ứng"]
    M -- "Không" --> O["Không yêu cầu xác minh domain hoặc legal"]
    N --> P
    O --> P

    P["Business Owner đánh giá theo:<br/>rủi ro an toàn thực phẩm, quy trình kho,<br/>khả năng truy vết và kết quả xác minh liên quan"] --> Q["Các option:<br/>1. Chặn toàn bộ xuất lô theo ngày hết hạn<br/>2. Cảnh báo và yêu cầu quyền override<br/>3. Kiểm soát ngoài ERP"]
    Q --> R{"Business Owner chọn option<br/>và ghi decision record?"}

    R -- "Không" --> S["Chưa có decision;<br/>không kiểm thử hành vi bắt buộc"]
    R -- "Có" --> U["Decision record về option đã chọn"]
    U --> T

    T --> V["QA xác định cách kiểm thử và test condition<br/>theo test basis hợp lệ"]
    V --> W["QA không quyết định business rule<br/>và không mặc định chặn xuất lô"]

Senior Lens

BA không “nâng cấp” câu nói thành fact bằng cách chép vào BRD, backlog hay test case. Bản sao phát biểu vẫn là stakeholder input. BA cũng không dùng trạng thái IN_REVIEW làm bằng chứng decision: trạng thái chỉ cho biết artifact đang được xem xét. Với khẳng định pháp lý, kế toán, thuế, bảo mật, riêng URL nguồn chính thức cũng chưa đủ để suy ra requirement hệ thống; cần xác định phần áp dụng và owner có thẩm quyền xác minh.

Cầu nối suy luận phải hiện rõ: evidence là nguồn hoặc quan sát; reasoning là vì sao evidence hỗ trợ kết luận; label là loại phát biểu; next control là người hoặc artifact cần xử lý tiếp. Thiếu một mắt xích, không dùng phát biểu làm expected result bắt buộc.

Quick Reference

Câu hỏi kiểm tra	Nếu “không”	Nhãn an toàn
Có artifact hoặc quan sát tái lập được không?	Không gọi là fact	Stakeholder input, assumption hoặc verification-required claim
Có authority và lựa chọn được ghi nhận không?	Không gọi là decision	Chưa quyết định
Có xác minh phù hợp cho nội dung pháp lý, kế toán, bảo mật, thuế, an toàn thực phẩm không?	Không viết “phải tuân thủ”	Verification required
Test expected result dựa trên fact liên quan hoặc decision chưa?	Không	Không tạo test case khẳng định hành vi bắt buộc

3. V? tr? trong Lifecycle

Core

Testing không bắt đầu khi QA nhận bản build. Testing bắt đầu từ Discovery vì BA phải tạo test basis: tập artifact làm căn cứ kiểm tra, gồm vấn đề nghiệp vụ, phạm vi, quy tắc, yêu cầu, tiêu chí chấp nhận và dữ liệu mẫu. Chuỗi này giúp expected result dựa trên bằng chứng, không dựa trên suy đoán. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu trong ví dụ là tổng hợp.

Mỗi pha có entry gate: điều kiện tối thiểu để bắt đầu pha. Mỗi pha có exit gate: điều kiện tối thiểu để bàn giao sang pha sau. Gate không phải phê duyệt ngầm. Tại IN_REVIEW, gate chỉ ghi nhận mức sẵn sàng để review; không tạo baseline, approval hay quyền triển khai production.

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

flowchart TB
    D[Discovery<br/>Xác định vấn đề và outcome]
    GDA[Exit Discovery / Entry Analysis<br/>Vấn đề nghiệp vụ; phạm vi; assumptions]
    A[Analysis<br/>Làm rõ requirement và rule]
    GAD[IN_REVIEW<br/>Exit Analysis / Entry Delivery<br/>Requirement; rule; acceptance criteria; traceability sẵn sàng review<br/>Chỉ ghi nhận readiness; không tạo baseline, approval hoặc quyền production]
    DV[Delivery<br/>Xây dựng cấu hình hoặc phần mềm]
    GDT[Exit Delivery / Entry Testing<br/>Testable increment; build note; deployed test environment]
    T[Testing<br/>Kiểm tra so với test basis hình thành từ Discovery onward]
    GTR[Exit Testing / Entry Release<br/>Evidence; defect status; residual-risk record]
    R[Release<br/>Đưa thay đổi qua kiểm soát phát hành]
    GRO[Exit Release / Entry Operations<br/>Release record; rollback readiness; communication record]
    O[Operations<br/>Theo dõi vận hành và phản hồi]
    GOD[Exit Operations / Entry Discovery<br/>Incident and feedback evidence]

    D --> GDA --> A --> GAD --> DV --> GDT --> T --> GTR --> R --> GRO --> O --> GOD --> D

Applied

Pha	Entry gate chính xác	BA dùng testing concept thế nào	Exit gate chính xác
Discovery	Có vấn đề cần khảo sát và phạm vi ban đầu	Hỏi “điều gì chứng minh thay đổi thành công?” để phát hiện outcome đo được	Có problem statement, phạm vi, stakeholder input, assumption và câu hỏi chưa xác minh
Analysis	Discovery artifact đủ để phân tích, nhưng chưa được gọi là decision	Chuyển nhu cầu thành requirement có điều kiện, quy tắc, dữ liệu và acceptance criteria có thể kiểm tra	Mỗi requirement cần delivery có acceptance criteria; claim chưa xác minh giữ nhãn Verification required
Delivery	Requirement đủ rõ để đội delivery ước lượng hoặc xây dựng	BA giữ traceability từ requirement sang work item và test condition; không tự suy ra hành vi thiếu evidence	Có increment để kiểm tra, version/build được nhận diện, thay đổi đã ghi nhận
Testing	Có test basis và increment kiểm tra được	So expected result với acceptance criteria, rule hoặc decision đã ghi nhận; log sai lệch thành defect hoặc câu hỏi làm rõ	Có test evidence, trạng thái defect, danh sách rủi ro còn lại và phạm vi chưa kiểm tra
Release	Có kết quả testing được tổng hợp để đánh giá phát hành	BA kiểm tra phạm vi release khớp requirement và known risk được hiển thị, không che giấu	Có release record, điều kiện rollback và thông tin vận hành được ghi nhận
Operations	Thay đổi đã vào môi trường vận hành theo kiểm soát phát hành	BA dùng incident, phản hồi và số liệu vận hành làm evidence cho nhu cầu mới hoặc điều chỉnh test basis	Có evidence phân loại: lỗi, thay đổi nhu cầu, vấn đề dữ liệu hoặc vấn đề quy trình; mục phù hợp quay lại Discovery

Facts: Nova Foods mô phỏng có yêu cầu: “Không cho tạo phiếu xuất kho khi số lượng khả dụng không đủ.” Đây là stakeholder input nếu chưa có rule artifact hoặc decision có thẩm quyền ghi nhận.

Current Behavior: Nếu delivery xây kiểm tra tồn kho chỉ từ câu nói trên, QA có thể viết expected result “hệ thống phải chặn”. Evidence chưa đủ vì “số lượng khả dụng”, thời điểm kiểm tra và cách xử lý đơn một phần chưa được xác định.

Underlying Need: Cần test basis xác định điều kiện đầu vào, hành vi mong đợi và ngoại lệ trước khi test bắt đầu.

Options: Giữ câu nói là input và dừng tạo expected result bắt buộc; hoặc làm rõ thành rule/acceptance criteria có evidence và authority phù hợp.

Decision Criteria: Chọn phương án chỉ khi xác định được nguồn số lượng khả dụng, thời điểm khóa tồn, hành vi khi thiếu hàng, và authority quyết định quy tắc.

Decision: Tại IN_REVIEW, chưa ghi nhận decision. Giữ nhãn Verification required; không tạo test case khẳng định hệ thống bắt buộc chặn phiếu.

Authority: Thẩm quyền quyết định không được suy ra từ BA, QA hoặc trạng thái artifact. Cần được ghi nhận trong artifact kiểm soát phù hợp.

Artifact: Requirement, acceptance criteria, test condition, defect log và release record phải liên kết cùng ID traceability đã đăng ký; không tạo ID mới trong section này.

Consequence if Wrong: Nếu test basis mơ hồ, delivery có thể xây hành vi sai, QA có thể “pass” sai tiêu chí, release mang rủi ro tồn kho hoặc vận hành không được thấy trước.

Senior Lens

Gate tốt kiểm tra khả năng bàn giao, không kiểm tra văn phong artifact. Ví dụ, requirement dài vẫn chưa đủ cho Testing nếu không xác định điều kiện, expected result và nguồn bằng chứng. Ngược lại, một acceptance criterion ngắn có thể đủ nếu nó mô tả rõ trigger, dữ liệu, hành vi và kết quả quan sát được.

Không đẩy claim chưa xác minh xuống Testing để QA “tự quyết”. Testing chỉ xác nhận hành vi đối chiếu test basis; Testing không có quyền biến assumption thành business rule. Khi test phát hiện test basis thiếu, luồng đúng là trả về Analysis để làm rõ, không sửa expected result im lặng.

Quick Reference

Gate	Câu hỏi chặn
Discovery sang Analysis	Vấn đề, phạm vi và điều chưa biết đã được ghi riêng chưa?
Analysis sang Delivery	Requirement có acceptance criteria kiểm tra được chưa?
Delivery sang Testing	Có increment nhận diện được và test basis tương ứng chưa?
Testing sang Release	Có evidence, defect status và residual risk record chưa?
Release sang Operations	Có release record và rollback readiness được ghi nhận chưa?
Operations sang Discovery	Evidence vận hành đã phân loại thành lỗi, nhu cầu mới, dữ liệu hay quy trình chưa?

Core

Owner là vai trò chịu trách nhiệm làm hoặc nhận một đầu ra; handoff là bàn giao có kiểm soát giữa hai vai trò. BA không chuyển “thông tin đã nói miệng”; BA chuyển artifact có ID, trạng thái, nguồn và điểm chưa rõ. Lý do: người nhận cần biết họ nhận gì, được quyết định gì, và phải trả lại gì.

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. /02-handbook/18-testing-fundamentals-for-ba.md đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không có baseline hay approval ngầm định.

Handoff	Upstream owner gửi	Downstream owner nhận	Artifact/bằng chứng tối thiểu	Giới hạn thẩm quyền	Escalation khi
Discovery sang Analysis	Business Owner, Subject Matter Expert (SME)	BA	Nhu cầu, vấn đề, giả định, nguồn phát biểu	SME giải thích quy trình; không tự chốt requirement liên phòng ban	Hai SME mô tả cùng quy trình khác nhau
Analysis sang Delivery	BA	Product Owner, Architect, Delivery Lead	Requirement, acceptance criteria, rule/data tham chiếu từ CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY, traceability ID	BA làm rõ và truy vết; không chọn kiến trúc, không phê duyệt nghiệp vụ	Requirement thiếu nguồn, mâu thuẫn rule, hoặc thay đổi ảnh hưởng bảo mật/tích hợp
Delivery sang Testing	Delivery Lead, Developer	QA Lead, QA Engineer, BA	Build/version, thay đổi đã thực hiện, môi trường kiểm thử, test basis, lỗi biết trước	Developer xác nhận phần đã xây; không tự xác nhận đạt nhu cầu nghiệp vụ	Build không truy vết được về requirement hoặc môi trường khác điều kiện đã công bố
Testing sang Release	QA Lead, BA, Product Owner	Release Manager, Operations	Kết quả test, defect trạng thái, rủi ro còn lại, evidence truy vết	QA đánh giá kiểm thử; BA đối chiếu ý nghĩa nghiệp vụ; không tự cấp quyền release	Defect nghiêm trọng, thiếu evidence, hoặc rủi ro vượt ngưỡng do người có thẩm quyền đặt
Release sang Operations	Release Manager	Operations Lead, Support	Release note, hướng dẫn vận hành, rollback thông tin, known issues	Operations vận hành theo gói release; không sửa rule nghiệp vụ để chữa sự cố	Sự cố dữ liệu, truy cập trái phép, gián đoạn dịch vụ, hoặc cần quyết định rollback

Applied

Facts: Nova Foods mô phỏng có requirement REQ-NF-INV-001: khi kho xác nhận xuất hàng, ERP phải tạo giao dịch giảm tồn kho. BA bàn giao acceptance criteria và liên kết rule tới CANONICAL_BUSINESS_RULES, nhưng catalog đang IN_REVIEW, không baseline.

Current Behavior: Developer hỏi có được tự chọn thời điểm ghi nhận giảm tồn kho là lúc in phiếu xuất hay lúc kho xác nhận hay không.

Underlying Need: Cần một quyết định nghiệp vụ về thời điểm phát sinh giao dịch tồn kho trước khi QA viết expected result.

Options: (1) Developer tự chọn; (2) BA chọn; (3) Business Owner quyết định, Accounting Owner tham vấn nếu ảnh hưởng ghi nhận kế toán.

Decision Criteria: Quyết định thay đổi số lượng tồn, có thể ảnh hưởng đối soát và hạch toán; vì vậy vượt thẩm quyền kỹ thuật và thẩm quyền quản trị artifact của BA.

Decision: Không cố định expected result về thời điểm giảm tồn kho. BA ghi nhận câu hỏi, các lựa chọn, ảnh hưởng và traceability trong gói escalation.

Authority: Business Owner quyết định quy tắc nghiệp vụ; Accounting Owner xác nhận phần diễn giải kế toán nếu áp dụng. BA giữ nguồn, trạng thái và liên kết; QA không tự biến giả định thành expected result.

Artifact: Cập nhật tham chiếu tại CANONICAL_BUSINESS_RULES với trạng thái Verification required; liên kết requirement, câu hỏi quyết định và test case nháp bằng canonical ID khi registry cấp ID.

Consequence if Wrong: QA có thể báo lỗi sai; ERP mô phỏng có thể giảm tồn kho sai thời điểm; dữ liệu test không còn chứng minh requirement. Không được gọi kết quả là compliant, approved hoặc production-ready.

Senior Lens

Handoff tốt có ba lớp: nội dung gồm artifact cụ thể; quyền hạn nêu ai được kết luận; đường quay lại nêu ai xử lý khi thiếu hoặc mâu thuẫn. Thiếu một lớp, downstream owner sẽ tự suy diễn. Suy diễn có thể nhanh, nhưng phá traceability.

BA được phép kết luận artifact “chưa đủ để kiểm thử”. BA không được kết luận “nghiệp vụ chấp nhận rủi ro”, “quy tắc kế toán đúng”, “thiết kế bảo mật đủ”, hoặc “được release”. Khi vấn đề chạm luật bảo vệ dữ liệu, an toàn thực phẩm, kế toán, thuế, bảo mật hoặc kiến trúc, BA chuyển đúng owner chuyên môn. Nguồn pháp lý trong corpus chỉ định hướng học liệu; mọi áp dụng thực tế cần Legal Owner, Accounting Owner, Security hoặc domain owner xác minh.

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

flowchart TB
    BO[Business Owner / SME] -->|Nhu cầu; quyết định nghiệp vụ| BA[BA]

    BA --> CONTENT{Có artifact cụ thể?}
    CONTENT -->|Không| CONTENT_GAP[BA kết luận artifact chưa đủ để kiểm thử]
    CONTENT -->|Có| AUTH{Owner có thẩm quyền cho từng kết luận<br/>đã được xác định?}
    AUTH -->|Không| AUTH_GAP[BA xác định thiếu thẩm quyền]
    AUTH -->|Có| RETURN{Có owner xử lý khi artifact<br/>thiếu hoặc mâu thuẫn?}
    RETURN -->|Không| RETURN_GAP[BA xác định thiếu owner xử lý]
    RETURN -->|Có| READY[Handoff đủ 3 lớp:<br/>nội dung, quyền hạn, đường quay lại]

    CONTENT_GAP --> GAP{Gap thuộc trách nhiệm nào?}
    AUTH_GAP --> GAP
    RETURN_GAP --> GAP

    GAP -->|Quyết định hoặc chấp nhận rủi ro nghiệp vụ| BO_GAP[Business Owner / SME]
    GAP -->|Kế toán hoặc thuế| AO_GAP[Accounting Owner]
    GAP -->|Pháp lý hoặc bảo vệ dữ liệu| LO_GAP[Legal Owner]
    GAP -->|Bảo mật| SO_GAP[Security Owner]
    GAP -->|Kiến trúc| AR_GAP[Architecture Owner]
    GAP -->|An toàn thực phẩm| DO_GAP[Domain Owner]
    GAP -->|Chưa xác định được owner| BLOCKED[Handoff bị chặn:<br/>chưa đủ để kiểm thử]

    BO_GAP --> OWNER_ACTION[Owner xác minh hoặc ra quyết định]
    AO_GAP --> OWNER_ACTION
    LO_GAP --> OWNER_ACTION
    SO_GAP --> OWNER_ACTION
    AR_GAP --> OWNER_ACTION
    DO_GAP --> OWNER_ACTION

    OWNER_ACTION --> RESOLVED{Gap đã được giải quyết?}
    RESOLVED -->|Không| BLOCKED
    RESOLVED -->|Có| UPDATE[BA cập nhật artifact]
    UPDATE --> RECHECK[BA kiểm tra lại 3 lớp handoff]
    RECHECK --> CONTENT

    READY --> DOWN[Downstream owner nhận handoff]
    DOWN -->|Phát hiện thiếu hoặc mâu thuẫn| GAP

Quick Reference

Tình huống	BA làm	BA không làm	Owner nhận escalation
Requirement không có nguồn	Gắn trạng thái chưa xác minh, yêu cầu nguồn	Tự tạo business rule	Business Owner hoặc SME
Rule ảnh hưởng hạch toán	Mô tả tác động, giữ nhãn Verification required	Diễn giải kế toán	Accounting Owner
API lộ dữ liệu cá nhân mô phỏng	Ghi nhận data flow, rủi ro, traceability	Xác nhận bảo mật đạt yêu cầu	Security Owner, Architect
QA thiếu expected result	Truy về requirement, rule, quyết định còn thiếu	Bảo QA đoán kết quả	Business Owner
Defect chặn release	Tổng hợp evidence và impact	Tự chấp nhận rủi ro release	Release Manager, Product Owner, QA Lead

Core

Bản đồ vòng đời cho biết vị trí kiểm thử trong chuỗi tạo giá trị, không phải quy trình phê duyệt. Nó giúp BA thấy kiểm thử cần bằng chứng từ đâu và kết quả kiểm thử quay lại đâu. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

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

flowchart LR
    D[Discovery<br/>Nhận diện vấn đề] --> A[Analysis<br/>Làm rõ nhu cầu và yêu cầu]
    A --> DV[Delivery<br/>Xây dựng cấu hình hoặc phần mềm]
    DV --> T[Testing<br/>So sánh kết quả thực tế với test basis]
    T --> R[Release<br/>Đưa thay đổi qua kiểm soát phát hành]
    R --> O[Operations<br/>Vận hành, theo dõi sự cố và phản hồi]
    O --> D

    A -. test basis .-> T
    T -. lỗi, bằng chứng, kết quả .-> DV
    O -. phản hồi vận hành .-> A

test basis là cơ sở kiểm thử: tập thông tin dùng để thiết kế hoặc đánh giá kiểm thử, như yêu cầu, quy tắc nghiệp vụ, tiêu chí chấp nhận và mô hình dữ liệu. Suy luận này dựa trên ISTQB CTFL Syllabus v4.0.1: hoạt động kiểm thử cần đối chiếu đối tượng kiểm thử với cơ sở kiểm thử; vì vậy Testing không nên tự tạo ý nghĩa nghiệp vụ khi Analysis chưa tạo được bằng chứng nguồn.

Applied

Mục	Nội dung
Facts	Nova Foods mô phỏng có thay đổi ERP liên quan nhập đơn bán hàng bằng dữ liệu tổng hợp. Tài liệu đang tham chiếu gồm /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md, đều IN_REVIEW.
Current Behavior	Nhóm có thể bắt đầu kiểm thử sau Delivery, nhưng không thấy rõ tài liệu Analysis nào làm test basis.
Underlying Need	Cần sơ đồ cho thấy Testing nhận đầu vào từ Analysis, trả bằng chứng lỗi về Delivery, và nhận phản hồi Operations cho vòng sau.
Options	Dùng mô tả văn bản; dùng bảng trạng thái; dùng Mermaid flowchart.
Decision Criteria	Người mới quét được toàn chuỗi; biểu đồ chạy được trong Markdown hỗ trợ Mermaid; không tự nhận là BPMN; không gán quy tắc Nova Foods chưa được xác minh.
Decision	Dùng Mermaid flowchart tuyến tính, có ba liên kết truy vết: Analysis đến Testing, Testing về Delivery, Operations về Discovery.
Authority	Bản đồ chỉ là học liệu. Không xác lập approval, baseline, cấu hình ERP, hay nghĩa vụ pháp lý.
Artifact	/02-handbook/18-testing-fundamentals-for-ba.md, section 03-lifecycle.
Consequence if Wrong	Nếu Testing bị vẽ tách khỏi Analysis, người học có thể viết test case theo suy đoán. Nếu không có vòng phản hồi Operations, lỗi thực tế không quay lại làm rõ nhu cầu.

Senior Lens

Đừng gọi biểu đồ này là BPMN. Nó là Mermaid flowchart để đọc nhanh; BPMN 2.0.2 của OMG mới là nguồn chuẩn cho ký pháp BPMN. Cũng đừng hiểu mũi tên là quyền quyết định hay phê duyệt. Mũi tên chỉ mô tả dòng công việc và dòng bằng chứng. Khi tài liệu nguồn còn IN_REVIEW, kết quả kiểm thử chỉ phản ánh mức khớp với test basis đang xem xét, không xác nhận thay đổi đã đúng cho production.

Quick Reference

Ký hiệu	Nghĩa
Mũi tên liền	Trình tự vòng đời chính
Mũi tên nét đứt	Luồng bằng chứng hoặc phản hồi
Analysis đến Testing	Cung cấp test basis
Testing về Delivery	Cung cấp lỗi, kết quả, bằng chứng tái hiện
Operations về Discovery	Cung cấp phản hồi để nhận diện vấn đề tiếp theo

4. Input c?n thi?t

Core

Kiểm thử cần test basis: tập bằng chứng dùng để suy ra điều cần kiểm tra và kết quả mong đợi. Người mới không cần biết lập trình, nhưng cần phân biệt ba loại đầu vào: kiến thức nền để hiểu nghiệp vụ; bằng chứng để chứng minh nhận định; artifact nguồn để truy về nơi thông tin được kiểm soát.

Với Nova Foods Trading & Manufacturing, đây là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Tên quy trình, số tiền VND, dữ liệu hàng hóa và hành vi ERP trong handbook không chứng minh hệ thống thật đang hoạt động như vậy.

Nhóm đầu vào	Người học cần hiểu từ đầu	Ví dụ dùng khi kiểm thử
Kiến thức nghiệp vụ	Quy trình là chuỗi công việc tạo kết quả nghiệp vụ; quy tắc nghiệp vụ là điều kiện phải được áp dụng nhất quán.	Hiểu đơn bán cần dữ liệu khách hàng, sản phẩm và số lượng trước khi suy ra tình huống kiểm thử.
Kiến thức kiểm thử	Test case là hướng dẫn kiểm tra có dữ liệu, bước thực hiện và kết quả mong đợi; defect là sai lệch quan sát được so với test basis.	Không gọi kết quả “lỗi” nếu chưa đối chiếu với requirement, rule hoặc acceptance criteria.
Bằng chứng	Bằng chứng là nội dung có thể truy về artifact nguồn, không phải ký ức, ý kiến miệng hoặc suy đoán.	Một rule chỉ được dùng làm cơ sở kiểm thử khi liên kết về catalog rule hoặc artifact nguồn.
Artifact nguồn	Artifact là tệp hoặc tài liệu được kiểm soát, chứa thông tin đầu vào.	Requirement, data dictionary, rule catalog, source map và ID registry.
Canonical ID	Định danh chuẩn, ổn định, giữ nguyên chuỗi qua các artifact để liên kết không mơ hồ.	Dùng CANONICAL_BUSINESS_RULES, không đổi thành “rule catalog” trong cột traceability.

Canonical ID không nói nội dung đã đúng, đã baseline hay đã được phê duyệt. ID chỉ trả lời: “Thông tin này phải được truy về artifact nào?” Trạng thái IN_REVIEW của các artifact nguồn là bằng chứng rằng nội dung còn đang xem xét; vì vậy BA được phép ghi nhận liên kết, nhưng không được nâng nội dung đó thành quyết định vận hành hoặc kết luận production.

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

flowchart TB
    I[Canonical ID] -->|định danh| A[Artifact nguồn<br/>IN_REVIEW]
    I -.-> N[Không chứng minh nội dung đúng,<br/>đã baseline hoặc được phê duyệt]

    A -->|chứa thông tin được trích dẫn| E[Bằng chứng truy về artifact nguồn]
    E -->|tập hợp| B[Test basis]

    K[Kiến thức nghiệp vụ và kiểm thử] -->|hỗ trợ diễn giải| B
    K -->|hỗ trợ xây dựng| T[Test case]
    B -->|suy ra dữ liệu, bước và<br/>kết quả mong đợi| T

    T --> X[Thực thi test]
    X --> O[Kết quả quan sát được]
    O --> C{Khớp kết quả mong đợi<br/>trong test basis?}
    B --> C

    C -->|Có| M[Phù hợp theo test basis đang review]
    C -->|Không| D[Sai lệch quan sát được cần review]

    A --> G[Được ghi nhận liên kết truy vết]
    A --> L[Không nâng thành quyết định vận hành<br/>hoặc kết luận production]

Applied

Facts: Nova Foods là mô phỏng giáo dục; corpus đang ở 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. Các artifact dưới đây tồn tại như nguồn quản trị của corpus.

Current Behavior: Nếu người học nhận một câu như “ERP phải kiểm tra dữ liệu đơn hàng”, họ chưa có đủ cơ sở để viết test case. Câu này thiếu nguồn, rule cụ thể, dữ liệu logic và ID để truy vết.

Underlying Need: Biến câu mô tả chung thành test basis có thể kiểm tra bằng cách liên kết mỗi loại thông tin với artifact canonical phù hợp.

Nhu cầu kiểm thử	Artifact nguồn canonical	Canonical ID phải giữ nguyên	Tệp nguồn được kiểm soát	Bằng chứng suy luận
Xác định cấu trúc chapter và dependency học liệu	Chapter manifest	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Manifest xác định chapter, filename và ranh giới curriculum.
Xác định ID được phép dùng trong liên kết	Registry định danh	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Registry là nguồn kiểm soát cho định danh traceability.
Xác định quy tắc nghiệp vụ cần kiểm thử	Catalog quy tắc	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Catalog là vị trí canonical của rule; không suy ra rule từ ví dụ đơn lẻ.
Xác định tên dữ liệu, ý nghĩa và cấu trúc logic	Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Data dictionary là nguồn cho ý nghĩa dữ liệu, không phải cấu hình DB thật.
Xác định nguồn chuẩn, chuẩn kỹ thuật và ranh giới dùng nguồn	Source map	00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Source map ghi issuer, version, URL và safe use boundary.
Xác định cấu trúc template dự kiến	Template manifest	TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Manifest chỉ lập kế hoạch template, không tạo artifact hoàn thành hay approval.

Options: Dùng mô tả miệng; dùng tên artifact không có ID; dùng artifact canonical kèm ID và đường dẫn.

Decision Criteria: Liên kết phải truy lại được một tệp kiểm soát; ID phải giữ nguyên; suy luận phải phân biệt rõ giữa dữ kiện nguồn và nội dung mô phỏng; không được biến IN_REVIEW thành baseline hoặc approval.

Decision: Dùng artifact canonical, canonical ID và đường dẫn tệp làm đầu vào tối thiểu trước khi viết test case Nova Foods.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và liên kết corpus. Vai trò này không xác nhận rule nghiệp vụ, quyết định ERP, compliance, pháp lý, kế toán hay production.

Artifact: /02-handbook/18-testing-fundamentals-for-ba.md, section 04-inputs.

Consequence if Wrong: Nếu test case dùng tên tệp mơ hồ hoặc ID bị đổi, người review không truy được bằng chứng. Nếu BA coi ví dụ mô phỏng là rule thật, test case có thể kiểm tra sai nhu cầu và tạo kết luận sai về ERP.

Senior Lens

Senior BA không bắt đầu từ màn hình hay từ test case mẫu. Senior BA bắt đầu bằng câu hỏi: “Kết quả mong đợi này dựa trên artifact nào?” Nếu không chỉ ra được artifact và canonical ID, đó mới là ý tưởng kiểm thử, chưa là test basis đủ truy vết.

Không trộn nguồn chuẩn với quyết định Nova Foods. Ví dụ, ISTQB CTFL Syllabus v4.0.1 cung cấp thuật ngữ kiểm thử; nó không tạo rule cho đơn hàng Nova Foods. Tương tự, CANONICAL_DATA_DICTIONARY mô tả dữ liệu logic trong corpus; nó không xác nhận schema database, API hay cấu hình ERP production.

Quick Reference

Thuật ngữ	Nghĩa thực hành
Test basis	Tập artifact và bằng chứng để suy ra điều cần kiểm thử
Evidence	Nội dung có thể truy lại nguồn kiểm soát
Artifact	Tệp hoặc tài liệu chứa thông tin đầu vào
Canonical ID	Chuỗi định danh chuẩn phải giữ nguyên khi tham chiếu
Traceability	Khả năng lần từ test case về nguồn gốc và ngược lại
IN_REVIEW	Đang xem xét; không phải baseline, approval hay production-ready

Core

Đầu vào kiểm thử phải đủ tin cậy trước khi BA viết điều kiện kiểm thử. “Chất lượng đầu vào” là khả năng dùng nguồn để tạo kiểm thử không suy đoán. BA kiểm tra: định danh giữ nguyên, nguồn có thẩm quyền rõ, nội dung còn mới, owner chịu trách nhiệm rõ, và phạm vi dùng không vượt ranh giới nguồn. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Kiểm tra	Đạt khi	Không đạt khi	Xử lý BA
Định danh	Giữ đúng Artifact ID, tên tệp, version	ID bị đổi, thiếu, trùng	Dừng liên kết test basis
Phân loại nguồn	Gắn nhãn primary, controlled planning, project assumption, hoặc Verification required	Gọi assumption là quy tắc bắt buộc	Sửa nhãn hoặc escalation
Freshness	Ngày cập nhật, version, status đọc được	Không biết phiên bản hoặc nguồn có thể lỗi thời	Dừng dùng làm căn cứ kiểm thử
Ownership	Có owner và giới hạn thẩm quyền	Owner không có quyền xác nhận nội dung	Chỉ ghi nhận, không kết luận
Khả năng kiểm thử	Nêu được hành vi, dữ liệu, kết quả quan sát	Chỉ có ý định mơ hồ	Yêu cầu làm rõ trước khi thiết kế test

“Primary source” là nguồn gốc từ tổ chức phát hành, ví dụ ISTQB CTFL Syllabus v4.0.1 tại URL đã xác minh. “Controlled planning artifact” là tài liệu corpus có quản trị, ví dụ /01-curriculum/CANONICAL_BUSINESS_RULES.md; nó định hướng học liệu nhưng IN_REVIEW không phải approval hay baseline. “Project assumption” là giả định mô phỏng, không được nâng thành nghĩa vụ. “Verification required” là thông tin chưa đủ bằng chứng hoặc cần owner chuyên môn xác nhận.

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

flowchart TB
    A[Nhận nguồn đầu vào] --> B{Artifact ID, tên tệp, version và status giữ nguyên, đọc được?}
    B -- Không --> S[STOP: thiếu hoặc sai truy vết]
    B -- Có --> C{Phân loại nguồn rõ?}
    C -- Không --> L[Gắn nhãn hoặc escalation]
    L --> C
    C -- Có --> D{Freshness đọc được và còn phù hợp?}
    D -- Không --> O[STOP: không dùng làm căn cứ kiểm thử]
    D -- Có --> E{Có owner và giới hạn thẩm quyền xác nhận?}
    E -- Không --> N[Chỉ ghi nhận, không kết luận]
    E -- Có --> F{Nội dung tạo được kiểm thử quan sát?}
    F -- Không --> R[Trả lại làm rõ]
    F -- Có --> G{Phạm vi dùng không vượt ranh giới nguồn?}
    G -- Không --> X[Giới hạn phạm vi hoặc escalation]
    X --> G
    G -- Có --> H{Nhãn nguồn?}
    H -- Primary source --> J{Nguồn từ tổ chức phát hành và URL đã xác minh?}
    J -- Không --> V[Xác nhận chuyên môn trước khi dùng làm test basis]
    J -- Có --> P[Dùng làm test basis có nhãn primary]
    H -- Controlled planning --> Q[Dùng định hướng; IN_REVIEW không là approval hoặc baseline]
    H -- Project assumption --> I[Dùng có nhãn assumption; không nâng thành nghĩa vụ]
    H -- Verification required --> V

Applied

Facts: BA nhận CANONICAL_BUSINESS_RULES, đường dẫn /01-curriculum/CANONICAL_BUSINESS_RULES.md, status IN_REVIEW, version v0.9.0, ngày 2026-08-07. Artifact nói rõ chưa có baseline và owner không xác nhận quy tắc vận hành thực tế.

Current Behavior: Người mới có thể lấy nội dung catalog này viết test case rồi ghi “đã xác nhận”.

Underlying Need: Test basis cần truy vết được, nhưng không được biến kế hoạch học liệu thành quyết định Nova Foods.

Options: Dùng artifact như quy tắc đã phê duyệt; dùng artifact như nguồn planning có nhãn IN_REVIEW; hoặc dừng toàn bộ kiểm thử.

Decision Criteria: Chọn cách giữ đúng status, không vượt thẩm quyền owner, vẫn cho phép luyện kỹ thuật kiểm thử với dữ liệu tổng hợp.

Decision: Dùng CANONICAL_BUSINESS_RULES làm controlled planning input. Mọi test dẫn xuất phải ghi IN_REVIEW và không dùng từ “đã phê duyệt”, “đã baseline”, hoặc “tuân thủ”.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và traceability. Business Owner, Legal Owner, Accounting Owner, Security, Architect, QA giữ thẩm quyền chuyên môn tương ứng.

Artifact: Tham chiếu nguyên dạng CANONICAL_BUSINESS_RULES và /01-curriculum/CANONICAL_BUSINESS_RULES.md.

Consequence if Wrong: Test có thể kiểm tra sai hành vi, tạo bằng chứng giả về approval, hoặc khiến team xem giả định mô phỏng là cấu hình ERP production.

Senior Lens

Freshness không chỉ là ngày mới. BA so ngày truy cập, version và trạng thái với mục đích dùng. Ví dụ URL pháp lý truy cập ngày 2026-08-07 chỉ cho phép tham chiếu nguồn chính thức trong học liệu. Nếu requirement diễn giải nghĩa vụ pháp lý, cần nhãn Verification required và Legal Owner xác nhận; BA không tự suy luận điều khoản.

Dừng ngay khi có một trong các điều kiện: nguồn mâu thuẫn với artifact canonical; ID hoặc đường dẫn không khớp; status bị diễn giải thành approval; owner không có thẩm quyền cho kết luận cần dùng; nội dung liên quan thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm, bảo mật, hoặc production mà thiếu xác minh chuyên môn. Dừng không phải thất bại. Dừng ngăn test sai lan sang defect, báo cáo và quyết định.

Quick Reference

Nhãn	Nghĩa dùng trong kiểm thử	Có thể kết luận?
Primary source	Nguồn phát hành gốc, dùng đúng safe use boundary	Chỉ kết luận trong ranh giới nguồn
Controlled planning artifact	Tài liệu corpus có ID, version, status	Không suy ra approval hoặc baseline
Project assumption	Giả định phục vụ mô phỏng	Không dùng làm rule bắt buộc
Verification required	Thiếu bằng chứng hoặc cần chuyên gia xác nhận	Không viết expected result mang tính bắt buộc
STOP	Điều kiện đầu vào không an toàn	Không thiết kế hoặc chạy kiểm thử từ nguồn đó

Core

Bảng đầu vào Nova Foods dưới đây là dữ liệu mô phỏng giáo dục, dùng để BA lập test basis, tức tập hợp bằng chứng làm cơ sở thiết kế kiểm thử. Mỗi dòng giữ ID và đường dẫn canonical. Giá trị chưa được xác minh không được biến thành quy tắc kiểm thử.

ID đầu vào	Artifact nguồn canonical	Phân loại nguồn	Giá trị mô phỏng dùng trong bài học	Tình trạng xác minh	Hạng mục chưa giải quyết
SRC-BA-001	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Chapter 18 Testing Fundamentals For Ba; Status IN_REVIEW; Version v0.9.0; ngày 2026-08-07	Đã ghi nhận metadata	Không có baseline reference; không gọi nội dung là đã phê duyệt
SRC-BA-002	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical identifier registry plan	Các ID requirement, rule, data và test phải giữ nguyên khi đã được registry cấp	Đã xác định boundary	Danh sách ID nghiệp vụ Nova Foods chi tiết chưa được cung cấp trong lô này
SRC-BA-003	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Canonical rule catalog plan	Rule catalog là nguồn dự kiến cho business rule, không phải cấu hình ERP thực	IN_REVIEW	Không có rule ID đã xác minh để viết expected result bắt buộc
SRC-BA-004	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Canonical logical data dictionary plan	Data dictionary là nguồn dự kiến cho tên trường, kiểu dữ liệu, định nghĩa logic	IN_REVIEW	Không có field definition Nova Foods đã xác minh trong lô này
SRC-EXT-005	https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf	Primary external standard source	ISTQB CTFL Syllabus v4.0.1; dùng thuật ngữ test basis, test condition, test case	Đã xác minh URL và phiên bản	Không suy diễn test case Nova Foods từ syllabus
SRC-EXT-006	https://www.iso.org/standard/72089.html	Primary external standard source	ISO/IEC/IEEE 29148:2018, Edition 2; dùng abstract và bibliographic status	Đã xác minh URL, trạng thái revision	Cần licensed-text verification nếu viện dẫn điều khoản chính xác
SRC-EXT-007	https://www.w3.org/TR/WCAG22/	Primary external standard source	WCAG 2.2 Recommendation, bản ngày 2024-12-12	Đã xác minh URL và edition	Chưa có giao diện Nova Foods để lập accessibility test condition
SRC-LEGAL-008	https://vanban.chinhphu.vn/?classid=1&docid=214590&pageid=27160&typegroup=	Official legal source	Luật 91/2025/QH15; hiệu lực 2026-01-01	Đã xác minh nguồn seed	Verification required: Legal Owner xác nhận requirement hệ thống nào áp dụng
SRC-LEGAL-009	https://vanban.chinhphu.vn/?docid=183198&pageid=27160	Official legal source	Luật 88/2015/QH13; hiệu lực 2017-01-01	Đã xác minh nguồn seed	Verification required: Accounting Owner xác nhận diễn giải kế toán
SIM-DATA-010	Nova Foods Trading & Manufacturing — simulated educational case study	Synthetic case data	Phiếu nhập kho mô phỏng GRN-SIM-20260807-001; mặt hàng RM-SIM-COCOA-01; số lượng 120; đơn giá 85.000 VND	Dữ liệu tổng hợp	Không đại diện giao dịch, thuế, tồn kho hoặc cấu hình ERP thực
SIM-DATA-011	Nova Foods Trading & Manufacturing — simulated educational case study	Synthetic case data	Lô nguyên liệu mô phỏng LOT-SIM-COCOA-202608; hạn dùng 2027-08-31; kho WH-SIM-HCM-01	Dữ liệu tổng hợp	Verification required: Business Owner xác nhận quy tắc chặn nhận hàng gần hạn dùng, nếu cần
SIM-DATA-012	Nova Foods Trading & Manufacturing — simulated educational case study	Synthetic case data	Vai trò mô phỏng ROLE-SIM-WH-CLERK; thao tác tạo phiếu nhận hàng	Dữ liệu tổng hợp	Verification required: Security Owner xác nhận quyền tạo, sửa, duyệt và xem dữ liệu
SIM-DATA-013	Nova Foods Trading & Manufacturing — simulated educational case study	Synthetic case data	Múi giờ Asia/Ho_Chi_Minh; locale vi-VN; tiền tệ VND	Đã xác định cho corpus	Không suy diễn quy tắc làm tròn, tỷ giá, thuế hoặc hạch toán
UNRES-014	Chưa có artifact canonical được cung cấp	Unresolved verification item	Expected result khi số lượng nhận vượt số lượng đơn mua	CHƯA XÁC MINH	Cần requirement hoặc rule ID canonical trước khi viết test case
UNRES-015	Chưa có artifact canonical được cung cấp	Unresolved verification item	Hành vi khi trùng số lô trong cùng kho	CHƯA XÁC MINH	Cần Data Owner và Business Owner xác nhận khóa dữ liệu, quy tắc gộp hoặc chặn
UNRES-016	Chưa có artifact canonical được cung cấp	Unresolved verification item	Điều kiện duyệt phiếu nhận hàng và phân tách nhiệm vụ	CHƯA XÁC MINH	Cần Business Owner và Security Owner xác nhận thẩm quyền

Không dùng UNRES-014, UNRES-015, UNRES-016 làm expected result. Chúng chỉ là điểm cần xác minh. Bằng chứng hiện có chỉ cho phép lập danh mục đầu vào, không cho phép khẳng định hành vi ERP Nova Foods.

5. Step-by-step BA Activities

Core

Kiểm thử dùng test basis (cơ sở kiểm thử): requirement, quy tắc, quy trình, dữ liệu hoặc acceptance criteria đã có nguồn. BA không tự tạo expected result từ suy đoán. BA chuẩn bị đầu vào, làm rõ điểm mơ hồ, bảo toàn truy vết, hỗ trợ review và bàn giao có kiểm soát.

Applied

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu là dữ liệu tổng hợp. Quy trình dưới đây áp dụng khi BA chuẩn bị và rà soát test basis cho thay đổi ERP. IN_REVIEW, v0.9.0, ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND là metadata corpus; không phải phê duyệt hay baseline.

Bước	Actor	Action và object	Evidence produced	Decision rule	Quality gate	Escalation route
1. Chuẩn bị phạm vi	BA	Mở change scope, requirement, rule, process và data source liên quan. Lập danh sách nguồn với phân loại gốc.	Test-basis inventory; nguồn canonical hoặc mục UNRES-*	Chỉ nhận object có ID hoặc nguồn xác định.	Không có nguồn bị gắn nhầm là canonical.	Thiếu hoặc mâu thuẫn nguồn: Principal IT Business Analyst / Technical Curriculum Author lập gói vấn đề; chuyển owner phù hợp.
2. Phân rã điều kiện kiểm thử	BA	Tách từng requirement thành điều kiện kiểm thử: trigger, input, xử lý, output, lỗi và quyền. “Điều kiện kiểm thử” là điều cần xác minh, chưa phải test case.	Requirement-to-test-condition matrix	Mỗi điều kiện phải truy ngược được tới một nguồn.	Không có expected result không có bằng chứng.	Quy tắc nghiệp vụ chưa rõ: Business Owner; dữ liệu: Data Owner; quyền: Security Owner.
3. Xác định dữ liệu	BA cùng Data Owner	Chọn dữ liệu tổng hợp đủ phủ trường hợp hợp lệ, biên và lỗi. Không suy diễn khóa dữ liệu, thuế, hạch toán hoặc quyền.	Synthetic test-data request	Chỉ dùng dữ liệu được gắn Synthetic case data hoặc dữ liệu đã được owner xác nhận.	Không có dữ liệu cá nhân, dữ liệu production, hoặc giá trị chưa rõ nguồn.	Có dữ liệu cá nhân hoặc yêu cầu bảo vệ dữ liệu: Security Owner và Legal Owner.
4. Soạn expected result	BA	Viết expected result từ requirement hoặc rule đã truy vết. Với UNRES-014, UNRES-015, UNRES-016, ghi điểm chặn xác minh, không viết kết quả mong đợi.	Draft test scenario và trace link	Expected result phải nêu điều quan sát được và nguồn chứng minh.	Reviewer tái tạo được logic từ nguồn đến kết quả.	Không suy ra được kết quả: Business Owner hoặc owner của artifact canonical.
5. Rà soát chéo	BA, QA Reviewer, Business Owner theo phạm vi	Rà test basis, scenario, dữ liệu và truy vết. QA Reviewer kiểm tra tính kiểm thử; Business Owner xác nhận ý nghĩa nghiệp vụ trong phạm vi thẩm quyền.	Review log; issue list; decision record	Không đóng issue bằng giả định.	Mọi issue có owner, nguồn, trạng thái và đường xử lý.	Tranh chấp nghiệp vụ: Business Owner; kỹ thuật tích hợp: Architect; bảo mật: Security Owner.
6. Bàn giao có kiểm soát	BA	Gửi gói test basis cho QA: version, nguồn, scenario, dữ liệu tổng hợp, issue mở và giới hạn sử dụng.	Controlled handoff record	Chỉ bàn giao artifact ghi rõ IN_REVIEW; không gọi là approved hoặc baselined.	QA nhận đủ trace link và biết các điểm UNRES-* không được chạy như expected result.	Thiếu thành phần bàn giao hoặc traceability đứt: trả về BA sửa inventory hoặc matrix.

Ví dụ thực thi Nova Foods: BA thấy dữ liệu SIM-DATA-011 có mặt hàng mô phỏng RM-SIM-COCO-001, lô LOT-SIM-2608-A, hạn dùng 2027-08-31, kho WH-SIM-HCM-01. Bằng chứng chỉ xác nhận dữ liệu tổng hợp tồn tại. Vì nguồn ghi “Verification required” cho quy tắc chặn nhận hàng gần hạn dùng, BA lập điều kiện kiểm thử “hệ thống đánh giá hạn dùng khi nhận hàng” nhưng không ghi “hệ thống phải chặn” làm expected result. Điểm này chuyển Business Owner xác nhận quy tắc và ngưỡng trước khi QA có test case chạy được.

Senior Lens

Chuỗi đúng là: nguồn xác định nội dung, BA biến nội dung thành điều kiện kiểm thử, QA kiểm thử điều kiện đó. BA không thay Business Owner quyết định quy tắc, không thay Architect quyết định tích hợp, không thay Security Owner xác nhận quyền. UNRES-* bảo vệ đội khỏi “test” một hành vi chưa được quyết định.

Quick Reference

• Có nguồn, có trace link, mới viết expected result.
• Có dữ liệu tổng hợp, mới chuẩn bị test data.
• Có điểm chưa xác minh, ghi UNRES-*, không đoán.
• IN_REVIEW không phải APPROVED hoặc BASELINED.

Core

Kiểm thử cần test basis: tập bằng chứng làm căn cứ thiết kế và đánh giá kiểm thử, như yêu cầu, quy tắc nghiệp vụ, acceptance criteria và dữ liệu mẫu. BA không tự xác nhận hệ thống đạt chất lượng; BA chuẩn bị căn cứ đúng, làm rõ ý nghĩa nghiệp vụ, giữ liên kết truy vết và chuyển vấn đề đến vai trò có thẩm quyền. Với Nova Foods Trading & Manufacturing mô phỏng, chỉ dùng dữ liệu tổng hợp; trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Applied

1. Chuẩn bị test basis — Actor: BA. Action: thu thập requirement, business rule, acceptance criteria và data definition từ artifact canonical. Object: phạm vi chức năng đang chuẩn bị kiểm thử. Evidence produced: danh sách nguồn, phiên bản, trạng thái IN_REVIEW và liên kết tới /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md. Decision rule: chỉ dùng nguồn canonical có ID và đường dẫn xác định; nguồn thiếu ID hoặc mâu thuẫn không thành test basis. Quality gate: mỗi phát biểu kiểm thử truy được về ít nhất một nguồn; không diễn giải IN_REVIEW thành baseline hoặc approval. Escalation route: Principal IT Business Analyst / Technical Curriculum Author khi thiếu traceability; Business Owner khi ý nghĩa nghiệp vụ chưa rõ.

2. Phân rã điều kiện kiểm thử — Actor: BA. Action: chuyển từng quy tắc hoặc acceptance criterion thành điều kiện quan sát được: dữ liệu vào, hành vi mong đợi, kết quả và ngoại lệ. Object: test condition, tức điều kiện cần được kiểm tra. Evidence produced: bảng điều kiện kiểm thử liên kết nguồn và giả định dự án. Decision rule: điều kiện phải phân biệt được đạt hoặc không đạt bằng bằng chứng; câu mô tả mơ hồ như “xử lý đúng” phải được làm rõ. Quality gate: không có điều kiện nào tự thêm quy tắc kế toán, thuế, pháp lý, an toàn thực phẩm hoặc bảo mật. Escalation route: Accounting Owner, Legal Owner, domain owner hoặc Security theo bản chất điều kiện.

3. Xác định dữ liệu kiểm thử — Actor: BA phối hợp QA. Action: mô tả tập dữ liệu tổng hợp tối thiểu cho luồng hợp lệ, biên và không hợp lệ. Object: giá trị trường, trạng thái giao dịch và quan hệ dữ liệu. Evidence produced: danh sách dữ liệu kiểm thử gắn mục đích từng điều kiện. Decision rule: mỗi giá trị phải chứng minh được vì sao đại diện cho biên hoặc ngoại lệ; không dùng dữ liệu cá nhân hay dữ liệu vận hành thật. Quality gate: locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND được ghi khi chúng ảnh hưởng kết quả. Escalation route: Data Owner hoặc Architect khi nguồn dữ liệu, mapping hay quyền truy cập chưa xác định.

4. Rà soát khả năng kiểm thử — Actor: BA và QA reviewer. Action: kiểm tra liệu điều kiện có đầu vào, hành động, kết quả mong đợi và bằng chứng đánh giá hay không. Object: test basis và test condition. Evidence produced: danh sách điểm rõ, điểm mơ hồ, giả định và vấn đề cần quyết định. Decision rule: nếu hai người đọc có thể kết luận khác nhau từ cùng điều kiện, điều kiện chưa đủ rõ để bàn giao. Quality gate: kết quả mong đợi không chỉ nêu giao diện; phải nêu tác động nghiệp vụ hoặc dữ liệu khi có tác động đó. Escalation route: Business Owner cho quyết định nghiệp vụ; Architect cho hành vi tích hợp; QA Lead cho phạm vi và kỹ thuật kiểm thử.

5. Bàn giao có kiểm soát — Actor: BA. Action: gửi gói test basis, điều kiện, dữ liệu tổng hợp, vấn đề mở và giới hạn thẩm quyền cho QA. Object: gói bàn giao kiểm thử. Evidence produced: bản ghi bàn giao có người nhận, thời điểm theo Asia/Ho_Chi_Minh, artifact nguồn và vấn đề chưa giải quyết. Decision rule: chỉ bàn giao như đầu vào review; không gắn nhãn “đã phê duyệt”, “đã baseline” hoặc “production-ready” khi không có tham chiếu tương ứng. Quality gate: QA nhận đủ nguồn để tái tạo reasoning từ requirement đến kết quả mong đợi. Escalation route: Principal IT Business Analyst / Technical Curriculum Author khi gói thiếu artifact; Owner có thẩm quyền khi vấn đề mở cần quyết định.

Senior Lens

Cầu nối reasoning phải hiện trong evidence: “nguồn nói gì”, “BA suy ra điều kiện nào”, “ai có quyền quyết định phần còn mơ hồ”. Ví dụ, một trường tiền tệ hiển thị VND chỉ tạo điều kiện định dạng nếu requirement hoặc data dictionary nêu trường đó; không tự suy ra quy tắc làm tròn, hạch toán hay thuế. Các nội dung pháp lý, kế toán, quyền riêng tư và an toàn thực phẩm giữ nhãn Verification required cho đến khi owner chuyên môn xác minh từ nguồn chính thức.

Quick Reference

Thành phần bắt buộc mỗi bước	Câu hỏi kiểm tra
Actor	Ai thực hiện và ai có thẩm quyền quyết định?
Action	Thao tác cụ thể nào được thực hiện?
Object	Artifact, dữ liệu hoặc điều kiện nào bị tác động?
Evidence produced	Tạo ra bằng chứng nào để người khác kiểm tra lại?
Decision rule	Khi nào chấp nhận, làm rõ hoặc dừng?
Quality gate	Điều kiện tối thiểu trước khi sang bước kế tiếp là gì?
Escalation route	Vấn đề đi đến vai trò nào khi BA không có thẩm quyề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. Bảng dưới ghi một lượt thực thi kiểm thử cho luồng ERP tạo đơn bán hàng và kiểm tra hạn mức tín dụng. Facts: đơn SO-SIM-00017 có tổng tiền 125.000.000 VND; khách CUS-SIM-0042 có hạn mức mô phỏng 100.000.000 VND; dữ liệu đầu vào thuộc test basis trong phiên bản đang IN_REVIEW v0.9.0, ngày 2026-08-07. Current Behavior: hệ thống dự kiến chặn xác nhận đơn khi tổng dư nợ sau đơn vượt hạn mức. Underlying Need: chứng minh quy tắc được diễn đạt thành trường hợp kiểm thử, dữ liệu, kết quả quan sát và truy vết kiểm tra được. Options: chấp nhận kết quả chặn; cho phép vượt hạn mức; hoặc dừng để làm rõ rule. Decision Criteria: chỉ chấp nhận khi kết quả thực tế khớp expected result, bằng chứng đủ tái lập, không có lỗi chặn chưa được phân loại. Decision: trạng thái test FAIL nếu hệ thống cho xác nhận đơn. Authority: Business Owner xác nhận ý nghĩa nghiệp vụ; QA xác nhận kết quả test; Accounting Owner hoặc Legal Owner phải xác minh mọi diễn giải tài chính hoặc pháp lý. Artifact: test execution record liên kết requirement, rule, dữ liệu và bằng chứng. Consequence if Wrong: đơn vượt hạn mức có thể được xử lý sai trong mô phỏng; không được suy ra cấu hình hay quyết định vận hành thực.

Test ID	Điều kiện và dữ liệu tổng hợp	Thao tác thực thi	Kết quả mong đợi	Bằng chứng lưu	Quyết định thực thi
TC-SIM-SO-017	CUS-SIM-0042; hạn mức 100.000.000 VND; SO-SIM-00017; giá trị đơn 125.000.000 VND	Nhập đơn, chọn khách, chạy xác nhận đơn	Hệ thống không xác nhận đơn; hiển thị lý do vượt hạn mức; trạng thái đơn không thành Confirmed	Ảnh màn hình, ID giao dịch mô phỏng, thời điểm Asia/Ho_Chi_Minh, actual result	PASS khi đủ ba điều kiện; FAIL khi đơn được xác nhận; BLOCKED khi môi trường hoặc dữ liệu không dùng được
TC-SIM-SO-018	Cùng khách; giá trị đơn 100.000.000 VND	Nhập và xác nhận đơn	Hệ thống xử lý theo rule tại ngưỡng bằng hạn mức; cần expected result được Business Owner làm rõ nếu chưa có rule canonical	Bản ghi actual result và liên kết CANONICAL_BUSINESS_RULES	Không tự suy luận toán tử > hay >=; escalation Business Owner khi rule chưa rõ

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

flowchart TB
    A[Test basis: requirement, rule, dữ liệu mô phỏng] --> B{Rule canonical áp dụng cho trường hợp đang test?}

    B -- Không --> C[Không tự suy luận > hoặc >=]
    C --> D[Escalate Business Owner; Accounting Owner hoặc Legal Owner khi thuộc thẩm quyền]
    D --> E[Ghi BLOCKED / clarification pending và lưu lý do]
    E --> R[Controlled handoff: test execution record]

    B -- Có --> F[BA lập test case và expected result]
    F --> G{Môi trường và dữ liệu dùng được?}
    G -- Không --> H[Ghi BLOCKED và lưu lý do]
    H --> R

    G -- Có --> I[QA thực thi trên môi trường mô phỏng]
    I --> J{Actual result khớp expected result?}

    J -- Không --> O{Rule mơ hồ hoặc nguồn xung đột khi phân tích sai lệch?}
    O -- Có --> D
    O -- Không --> P[Ghi FAIL, defect và lưu evidence]
    P --> R

    J -- Có --> K{Bằng chứng đủ tái lập?}
    K -- Không --> L[Ghi BLOCKED do thiếu bằng chứng]
    L --> R

    K -- Có --> M{Có lỗi chặn chưa được phân loại?}
    M -- Không --> N[Ghi PASS và lưu evidence]
    N --> R

    M -- Có --> Q[Ghi BLOCKED / pending classification]
    Q --> S[QA phân loại lỗi]
    S --> T[Đánh giá lại actual result, bằng chứng và lỗi chặn]
    T --> J

Sơ đồ là Mermaid flowchart, không phải BPMN. Cầu nối suy luận: giá trị đơn 125.000.000 VND lớn hơn hạn mức 100.000.000 VND; vì vậy expected result phải là chặn xác nhận nếu rule mô phỏng nói không cho vượt hạn mức. Nếu source canonical không nêu rõ hành vi tại đúng ngưỡng, BA ghi BLOCKED hoặc yêu cầu làm rõ, không tự tạo quy tắc.

6. Output thu ???c

Core

Output testing là artifact được tạo hoặc cập nhật để người khác kiểm tra test basis, thực thi kiểm thử, hoặc xử lý sai lệch. Artifact không phải bằng chứng phê duyệt. Trong corpus Nova Foods mô phỏng, mọi artifact giữ Status: IN_REVIEW, Version: v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh; chỉ dùng dữ liệu tổng hợp.

Artifact	Owner chịu trách nhiệm duy trì	Status	Canonical ID hoặc liên kết bắt buộc	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
Test case specification	BA soạn; QA review khả năng thực thi	IN_REVIEW	TC-SIM-SO-017, TC-SIM-SO-018; liên kết CANONICAL_BUSINESS_RULES khi có rule	Mục tiêu, precondition, dữ liệu, bước test, expected result, test basis, owner, trạng thái	Ghi version, ngày, người đổi, trường đổi, lý do, tác động traceability
Test data set	QA duy trì; BA xác nhận nghĩa dữ liệu theo test basis	IN_REVIEW	Liên kết test case tương ứng; tham chiếu CANONICAL_DATA_DICTIONARY khi field đã được đăng ký	ID dữ liệu mô phỏng, giá trị input, đơn vị VND, điều kiện dùng, phân loại synthetic	Ghi thay đổi giá trị, lý do, test case bị ảnh hưởng, thời điểm
Test execution record	QA ghi nhận	IN_REVIEW	Liên kết TC-SIM-SO-017 hoặc TC-SIM-SO-018	Người thực thi, thời điểm, môi trường mô phỏng, actual result, PASS/FAIL/BLOCKED, evidence reference	Không sửa đè kết quả cũ; ghi lần chạy mới hoặc correction entry có lý do
Defect hoặc clarification record	QA tạo; BA duy trì liên kết requirement/rule	IN_REVIEW	Liên kết test case, requirement hoặc CANONICAL_BUSINESS_RULES	Mô tả quan sát, bước tái hiện, expected/actual result, mức ảnh hưởng, evidence, owner xử lý	Ghi trạng thái chuyển đổi, quyết định làm rõ, nguồn xác nhận, tác động test lại
Traceability update	BA duy trì	IN_REVIEW	TRACEABILITY_ID_REGISTRY và ID nguồn liên quan	Quan hệ test basis–test case–execution–defect, loại liên kết, trạng thái liên kết	Ghi liên kết thêm, xóa, sửa; không đổi ID im lặng

PASS, FAIL, BLOCKED là kết quả lần chạy, không thay thế status quản trị IN_REVIEW. Cầu nối suy luận: người review cần biết test nào dựa trên rule nào và lần chạy nào phát hiện sai lệch; vì vậy mỗi output phải giữ ID nguồn và liên kết truy vết.

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

flowchart TB
    A[CANONICAL_BUSINESS_RULES<br/>Test basis]

    B[TC-SIM-SO-017<br/>Test case<br/>BA soạn · QA review]
    C[TC-SIM-SO-018<br/>Test case<br/>BA soạn · QA review]

    H[Test data set cho TC-SIM-SO-017<br/>QA duy trì · BA xác nhận]
    I[Test data set cho TC-SIM-SO-018<br/>QA duy trì · BA xác nhận]
    J[CANONICAL_DATA_DICTIONARY]

    D[Test execution record<br/>TC-SIM-SO-017<br/>QA ghi nhận]
    E[Test execution record<br/>TC-SIM-SO-018<br/>QA ghi nhận]

    R[Kết quả lần chạy:<br/>PASS / FAIL / BLOCKED<br/>Không phải status quản trị]

    X1[Defect or clarification record<br/>QA tạo · BA giữ liên kết]
    X2[Defect or clarification record<br/>QA tạo · BA giữ liên kết]

    G[Traceability update<br/>TRACEABILITY_ID_REGISTRY<br/>BA duy trì]

    M[Metadata chung output artifact<br/>Status: IN_REVIEW<br/>Version: v0.9.0 · 2026-08-07<br/>Asia/Ho_Chi_Minh]
    L[Lịch sử thay đổi<br/>TC, data, defect, trace: ghi thay đổi<br/>Execution: không sửa đè kết quả cũ]

    A -->|test basis cho| B
    A -->|test basis cho| C

    B -->|liên kết dữ liệu test| H
    C -->|liên kết dữ liệu test| I
    H -.->|khi field đã được đăng ký| J
    I -.->|khi field đã được đăng ký| J

    B -->|ghi nhận lần chạy| D
    C -->|ghi nhận lần chạy| E
    H -->|dữ liệu dùng| D
    I -->|dữ liệu dùng| E

    D --> R
    E --> R

    D -->|khi phát hiện sai lệch hoặc cần làm rõ| X1
    E -->|khi phát hiện sai lệch hoặc cần làm rõ| X2
    B -.->|test case liên quan| X1
    C -.->|test case liên quan| X2
    X1 -.->|requirement hoặc rule liên quan| A
    X2 -.->|requirement hoặc rule liên quan| A

    A -->|đăng ký quan hệ test basis| G
    B -->|đăng ký quan hệ test case| G
    C -->|đăng ký quan hệ test case| G
    D -->|đăng ký quan hệ execution| G
    E -->|đăng ký quan hệ execution| G
    X1 -->|đăng ký sai lệch hoặc làm rõ| G
    X2 -->|đăng ký sai lệch hoặc làm rõ| G

    M -.-> B
    M -.-> C
    M -.-> H
    M -.-> I
    M -.-> D
    M -.-> E
    M -.-> X1
    M -.-> X2
    M -.-> G

    L -.-> B
    L -.-> C
    L -.-> H
    L -.-> I
    L -.-> D
    L -.-> E
    L -.-> X1
    L -.-> X2
    L -.-> G

Sơ đồ mô tả luồng truy vết artifact, không phải BPMN.

Applied

Mục bắt buộc	Nova Foods ERP mô phỏng, dữ liệu tổng hợp
Facts	TC-SIM-SO-017 kiểm tra đơn bán 125.000.000 VND; test basis nêu hạn mức tín dụng mô phỏng 100.000.000 VND.
Current Behavior	Output cần tạo là test case, test data set và execution record; chưa có kết quả thực thi được ghi nhận.
Underlying Need	QA cần expected result có nguồn; BA cần giữ liên kết để người review phân biệt rule, dữ liệu và kết quả chạy.
Options	Ghi test case không liên kết nguồn; hoặc liên kết TC-SIM-SO-017 với CANONICAL_BUSINESS_RULES và execution record.
Decision Criteria	Truy ngược được nguồn, không tự suy diễn rule, đủ dữ liệu để tái thực thi, lịch sử thay đổi không bị mất.
Decision	Dùng liên kết canonical; ghi BLOCKED nếu rule nguồn không đủ xác định expected result.
Authority	BA duy trì traceability; QA ghi execution; Business Owner làm rõ rule nghiệp vụ; Legal/Accounting Owner chỉ tham gia khi nội dung thuộc thẩm quyền họ.
Artifact	TC-SIM-SO-017, test data set liên kết case, test execution record, cập nhật TRACEABILITY_ID_REGISTRY.
Consequence if Wrong	QA có thể test nhầm rule, defect không tái hiện được, hoặc kết quả bị hiểu sai là quyết định nghiệp vụ đã được chấp thuận.

Senior Lens

Không dùng tên file, ảnh chụp màn hình, hoặc tin nhắn trao đổi làm canonical ID. Chúng là evidence reference. Canonical ID phải trỏ đến artifact kiểm soát hoặc entry đã đăng ký, như TC-SIM-SO-017, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.

Mỗi thay đổi phải ghi tối thiểu: version, ngày theo Asia/Ho_Chi_Minh, người ghi nhận, nội dung đổi, lý do, artifact bị ảnh hưởng. Lý do: thay expected result có thể đổi phạm vi test; sửa im lặng phá vỡ khả năng audit và review. IN_REVIEW chỉ cho biết artifact đang được xem xét có kiểm soát; không có nghĩa approved, baselined, compliant, production-ready, hoặc được người dùng chấp thuận.

Quick Reference

Kiểm tra trước downstream review	Điều kiện đạt
Định danh	Có canonical ID hoặc liên kết canonical đúng chuỗi
Ownership	Có owner duy trì và ranh giới thẩm quyền
Nội dung	Đủ trường tối thiểu của loại artifact
Truy vết	Liên kết được test basis, test case, execution và sai lệch nếu có
Lịch sử	Có change-history entry, không sửa đè không dấu vết
Trạng thái	Ghi IN_REVIEW; không tuyên bố approval hay production readiness

Core

Output kiểm thử là artifact ghi được kết quả từ test basis: requirement, business rule, acceptance criteria, luồng nghiệp vụ, dữ liệu và rủi ro. Nó biến câu hỏi “hệ thống có làm đúng không?” thành bằng chứng truy vết được. Với Nova Foods Trading & Manufacturing mô phỏng, chỉ dùng dữ liệu tổng hợp; không suy ra cấu hình ERP thật.

Thành phần anatomy	Nội dung bắt buộc	Ví dụ giá trị mô phỏng
Test basis	Nguồn để thiết kế kiểm thử	CANONICAL_BUSINESS_RULES, requirement, acceptance criteria
Scenario	Tình huống nghiệp vụ cần kiểm tra	Tạo phiếu xuất kho cho đơn bán có đủ tồn khả dụng
Precondition	Điều kiện trước test	Người dùng có quyền mô phỏng; SKU có tồn khả dụng
Test data	Dữ liệu đầu vào, nguồn và trạng thái	SKU NF-RM-001; số lượng 100; kho WH-HCM-01; dữ liệu tổng hợp
Test steps	Hành động tuần tự, tái lập được	Mở đơn bán, nhập SKU, nhập số lượng, xác nhận xuất kho
Expected result	Kết quả mong đợi, đo được	Phiếu xuất tạo thành công; tồn khả dụng giảm 100 đơn vị
Actual result	Kết quả quan sát khi chạy	Ghi đúng giá trị quan sát, không thay bằng nhận xét chung
Evidence	Bằng chứng kiểm tra	Mã giao dịch mô phỏng, ảnh màn hình đã che dữ liệu, log API nếu có
Result	Trạng thái chạy test	NOT_RUN, PASS, FAIL, BLOCKED
Defect link	Liên kết lỗi nếu kết quả khác kỳ vọng	Chỉ ghi khi có defect được tạo; không tự kết luận nguyên nhân

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

flowchart TB
    A[Test basis] --> B[Test scenario]
    B --> C[Test case]
    C --> D{Đã bắt đầu thực hiện?}
    D -->|Không| E[Test execution record]
    E --> F[NOT_RUN]
    D -->|Có| G{Bị chặn?}
    G -->|Có| H[Test execution record]
    H --> I[BLOCKED + lý do/evidence]
    G -->|Không| J[Actual result]
    J --> K{Actual = Expected?}
    K -->|Có| L[Test execution record]
    L --> M[PASS + evidence]
    K -->|Không| N[Test execution record]
    N --> O[FAIL + evidence]
    O --> P{Đã tạo defect?}
    P -->|Có| Q[Defect link]
    P -->|Không| R[Không có defect link]

Applied

Facts: Nova Foods là case mô phỏng giáo dục, dữ liệu tổng hợp, locale vi-VN, tiền tệ VND, thời gian quản trị Asia/Ho_Chi_Minh. Artifact nguồn đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY là nguồn canonical được nêu trong corpus, nhưng không chứng minh rule hay data model vận hành thật.

Current Behavior: Chưa có kết quả chạy ERP thật. Vì vậy, output dưới đây là mẫu đã điền cho mục đích học cách ghi test artifact; cột Actual Result giữ trạng thái chưa chạy thay vì bịa bằng chứng.

Underlying Need: QA reviewer cần tái tạo cùng tình huống và so Expected Result với Actual Result. Không có test data, bước chạy và evidence, kết quả PASS hoặc FAIL không kiểm chứng được.

Trường	Giá trị đã điền cho Nova Foods mô phỏng
Test output reference	CANONICAL_BUSINESS_RULES; CANONICAL_DATA_DICTIONARY
Scenario name	Xuất kho đơn bán khi tồn khả dụng đủ
Business context	Kho thành phẩm mô phỏng phục vụ đơn bán
Test data	Kho WH-HCM-01; SKU NF-FG-001; tồn khả dụng trước xuất 250; số lượng yêu cầu 100; đơn vị EA; giá trị đơn hàng mô phỏng 15.000.000 VND
Precondition	SKU NF-FG-001 tồn tại trong dữ liệu mô phỏng; kho WH-HCM-01 có tồn khả dụng 250 EA; đơn bán mô phỏng ở trạng thái cho phép xuất kho
Step 1	Mở đơn bán mô phỏng chứa SKU NF-FG-001, số lượng 100 EA
Expected result 1	Hệ thống hiển thị đúng SKU, kho và số lượng yêu cầu 100 EA
Actual result 1	NOT_RUN; chưa có bằng chứng thực thi
Step 2	Thực hiện chức năng xuất kho cho đơn bán
Expected result 2	Hệ thống tạo một phiếu xuất kho mô phỏng liên kết đơn bán
Actual result 2	NOT_RUN; chưa có bằng chứng thực thi
Step 3	Tra cứu tồn khả dụng SKU tại WH-HCM-01 sau xuất kho
Expected result 3	Tồn khả dụng là 150 EA, tính từ 250 EA - 100 EA
Actual result 3	NOT_RUN; chưa có bằng chứng thực thi
Execution result	NOT_RUN
Evidence	Chưa có; không được ghi ảnh màn hình, transaction ID hoặc log không tồn tại
Defect link	Không có, vì test chưa chạy
Data classification	Dữ liệu tổng hợp; không dùng dữ liệu cá nhân, khách hàng thật, nhân sự thật hoặc giao dịch thật

Options: Ghi một dòng “xuất kho thành công”; hoặc ghi từng bước cùng dữ liệu, kỳ vọng, thực tế và evidence. Phương án một dòng nhanh nhưng không cho reviewer biết số tồn nào đã được kiểm tra hay sai ở bước nào.

Decision Criteria: Output phải cho người khác chạy lại cùng điều kiện; Expected Result phải tính được từ dữ liệu đầu vào; Actual Result phải tách khỏi Expected Result; evidence phải tồn tại trước khi tham chiếu.

Decision: Dùng output theo từng bước. Giá trị 250 EA, 100 EA, 150 EA tạo chuỗi kiểm tra rõ: tồn sau xuất bằng tồn trước trừ số lượng xuất. Đây là suy luận số học từ dữ liệu mô phỏng trong cùng record, không phải business rule Nova Foods đã xác nhận.

Authority: QA reviewer đánh giá tính đầy đủ của bằng chứng kiểm thử. Business Owner xác nhận ý nghĩa nghiệp vụ khi cần. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability học liệu, không xác nhận vận hành, accounting, legal, security hoặc production.

Artifact: Test execution record phải liên kết ngược tới CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY; không thay thế hai nguồn này, không tạo baseline, không ghi nhận approval.

Consequence if Wrong: Nếu ghi PASS khi chưa có Actual Result và evidence, downstream reviewer có thể tin sai rằng tồn kho đã được kiểm tra. Nếu dùng tồn đầu kỳ không rõ nguồn, defect có thể bị phân loại sai thành lỗi ERP dù lỗi nằm ở test data.

Senior Lens

Không gộp “kỳ vọng” và “quan sát”. Expected Result là chuẩn so sánh trước khi chạy; Actual Result là sự kiện sau khi chạy. Tách hai trường ngăn người test sửa kỳ vọng để khớp hệ thống.

Không suy diễn nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo vệ dữ liệu từ test output này. Nếu test chạm dữ liệu cá nhân, hóa đơn, truy xuất lô hoặc hạch toán, gắn nhãn Verification required và chuyển đúng owner chuyên môn.

Quick Reference

Kiểm tra anatomy	Đạt khi
Tái lập	Có precondition, test data, step và expected result
Truy vết	Có tham chiếu CANONICAL_BUSINESS_RULES hoặc CANONICAL_DATA_DICTIONARY khi phù hợp
Trung thực bằng chứng	NOT_RUN khi chưa chạy; không bịa actual result hoặc evidence
Phân biệt trạng thái	IN_REVIEW không phải approval, baseline hoặc production-ready
Phạm vi dữ liệu	Chỉ dữ liệu tổng hợp Nova Foods mô phỏng

Core

Quality gate là cổng kiểm tra chất lượng trước khi artifact chuyển sang downstream review, tức xem xét bởi vai trò nhận đầu ra. Cổng này chỉ xác nhận artifact đủ để review. Nó không xác nhận nội dung đúng tuyệt đối, không phải phê duyệt, không phải baseline, không phải sẵn sàng production.

Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, mọi output testing phải giữ 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. Lý do: review cần nhận biết đúng phiên bản và phạm vi; thiếu metadata làm reviewer có thể kiểm tra nhầm bản hoặc suy diễn nhầm thẩm quyền.

Mã gate	Điều kiện bắt buộc	Bằng chứng phải có	Kết quả khi không đạt
QG-TEST-001	Artifact có canonical ID, filename, owner, status, version, ngày cập nhật	Header hoặc metadata kiểm tra được	Không chuyển review
QG-TEST-002	Mọi test item liên kết test basis bằng ID canonical	Requirement, business rule, data hoặc acceptance criteria source ID	Gắn TRACEABILITY GAP; không chuyển review
QG-TEST-003	Expected result đo được, không dùng từ mơ hồ như “đúng”, “ổn”, “hợp lý”	Giá trị, trạng thái, thông báo, dữ liệu lưu, hoặc hành vi quan sát được	Trả về tác giả làm rõ
QG-TEST-004	Test data là synthetic data; không có dữ liệu cá nhân hay dữ liệu vận hành thật	Nhãn Synthetic data only và giá trị test	Loại dữ liệu khỏi artifact
QG-TEST-005	Mỗi phát hiện lỗi có severity, evidence, bước tái hiện và liên kết test item	Defect record đầy đủ	Không phân loại là defect reviewable
QG-TEST-006	Change history ghi thay đổi từ bản trước hoặc ghi khởi tạo	Dòng lịch sử thay đổi có ngày, người ghi nhận, nội dung	Không chuyển review
QG-TEST-007	Không diễn đạt APPROVED, BASELINED, compliant, production-ready, user-approved	Soát trạng thái và kết luận	Sửa ngôn ngữ kiểm soát

Applied

Facts: Nova Foods là case mô phỏng giáo dục; artifact testing đang ở IN_REVIEW, v0.9.0. Current Behavior: BA soạn test output và muốn gửi QA reviewer. Underlying Need: QA cần đủ căn cứ để kiểm tra traceability và testability, không phải nhận một kết luận đã được phê duyệt. Options: gửi ngay; hoặc chạy quality gate trước. Decision Criteria: artifact có đủ metadata, liên kết nguồn, expected result đo được, dữ liệu tổng hợp, lịch sử thay đổi. Decision: chạy QG-TEST-001 đến QG-TEST-007; chỉ gắn nhãn Ready for downstream review khi tất cả đạt. Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì governance; QA reviewer đánh giá chất lượng testing; không vai trò nào trong ví dụ này tự cấp approval. Artifact: output testing thuộc /02-handbook/18-testing-fundamentals-for-ba.md. Consequence if Wrong: reviewer kiểm tra nhầm phiên bản, không truy được test basis, hoặc hiểu sai readiness là quyền dùng production.

Artifact output mô phỏng	Gate evidence hoàn chỉnh	Trạng thái sau gate
Test scenario TS-NF-001	Liên kết CANONICAL_BUSINESS_RULES; expected result nêu trạng thái đơn hàng; test data ghi synthetic	IN_REVIEW — Ready for downstream review
Test case TC-NF-001	Bước thực hiện, dữ liệu tổng hợp, expected result quan sát được, liên kết TS-NF-001	IN_REVIEW — Ready for downstream review
Defect record DEF-NF-001	Liên kết TC-NF-001, actual result, expected result, severity, evidence, bước tái hiện	IN_REVIEW — Ready for downstream review
Test summary TSR-NF-001	Phạm vi test, số lượng case, kết quả thực thi, defect reference, giới hạn review	IN_REVIEW — Ready for downstream review

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

flowchart TB
    O[Principal IT Business Analyst / Technical Curriculum Author<br/>Duy trì governance] -.-> B

    A[BA hoàn tất output testing<br/>IN_REVIEW, v0.9.0] --> Q[BA chạy quality gate<br/>QG-TEST-001 đến QG-TEST-007]
    Q --> B{Đủ metadata, liên kết nguồn,<br/>expected result đo được, dữ liệu synthetic,<br/>lịch sử thay đổi?}

    B -- Không --> C[BA bổ sung evidence<br/>hoặc sửa metadata]
    C --> A

    B -- Có --> D[IN_REVIEW, v0.9.0<br/>Ready for downstream review]
    D --> E[QA reviewer đánh giá<br/>chất lượng testing]
    E --> G{Kết quả downstream review}
    G -->|Phát hiện vấn đề| H[Review finding]
    G -->|Cần quyết định| I[Quyết định trong phạm vi thẩm quyền]
    H --> J[Downstream review không cấp production approval<br/>Không vai trò nào tự cấp approval]
    I --> J

    A -. Bỏ qua quality gate<br/>hoặc gắn nhãn readiness sai .-> R[Readiness không hợp lệ]
    R --> K[Reviewer có thể kiểm tra nhầm phiên bản,<br/>không truy được test basis,<br/>hoặc hiểu sai readiness là quyền dùng production]

Senior Lens

Không dùng quality gate để che rủi ro. Gate chỉ kiểm tra độ hoàn chỉnh và khả năng review, không thay reviewer quyết định rule nghiệp vụ, thiết kế kỹ thuật, pháp lý, kế toán, bảo mật hay vận hành. Ví dụ, test case có thể liên kết CANONICAL_BUSINESS_RULES và đạt traceability, nhưng rule đó vẫn IN_REVIEW; vì vậy test case sẵn sàng để QA review, không chứng minh rule đúng cho ERP thực tế.

Nếu source ID không tồn tại, mâu thuẫn, hoặc source chứa yêu cầu pháp lý chưa được Legal Owner xác minh, dừng chuyển review theo phạm vi đó. Ghi rõ Verification required thay vì tạo kết luận thay thế. Evidence bridge: downstream reviewer chỉ đánh giá được khi biết output dựa vào nguồn nào và nguồn đang chắc đến mức nào.

Quick Reference

Nhãn được phép sau gate	Ý nghĩa
IN_REVIEW — Ready for downstream review	Đủ metadata, traceability, evidence và kiểm soát để reviewer bắt đầu review
IN_REVIEW — Not ready for downstream review	Có ít nhất một gate fail hoặc chưa có evidence
TRACEABILITY GAP	Không liên kết được output với test basis canonical
Verification required	Cần vai trò có thẩm quyền xác minh nguồn, rule hoặc diễn giải

Không thay nhãn trên bằng APPROVED, BASELINED, production-ready, compliant hoặc user-approved.

7. Who consumes those outputs?

Core

Nova Foods Trading & Manufacturing là case study mô phỏng; mọi dữ liệu là tổng hợp. Output testing không chỉ dành cho QA. Mỗi output là test basis, tức tập bằng chứng để vai trò khác đọc cùng một yêu cầu, rule, dữ liệu và kết quả thay vì suy diễn riêng.

Output testing	Developer	QA	Architect	PM/Product Owner	Business Owner	Operations	Specialist owner
Test scenario	Đọc luồng cần hỗ trợ trước khi code.	Dùng để bao phủ luồng chính, lỗi và biên.	So với boundary giữa ERP, API và thành phần kỹ thuật.	Đọc để thấy phạm vi chức năng được kiểm tra.	Đọc để đối chiếu luồng với cách làm nghiệp vụ mô phỏng.	Đọc để nhận biết điểm tác động vận hành.	Đọc phần thuộc chuyên môn như kho, kế toán, chất lượng.
Test case	Tái hiện bước lỗi, sửa code và kiểm tra lại.	Thực thi, ghi actual result và evidence.	Xem test có chạm tích hợp, phân quyền hoặc hiệu năng cần thiết không.	Theo dõi acceptance criteria đã được chuyển thành kiểm tra hay chưa.	Xem ví dụ dữ liệu và kết quả mong đợi có diễn đạt đúng ý nghiệp vụ không.	Xem thao tác có thể chạy được trong quy trình ngày thường không.	Kiểm tra điều kiện chuyên ngành được biểu diễn rõ.
Traceability matrix	Tìm requirement, rule hoặc API liên quan khi sửa lỗi.	Kiểm tra mỗi test có nguồn và mỗi nguồn có coverage.	Dò tác động kiến trúc từ requirement tới interface.	Theo dõi phạm vi release và khoảng trống coverage.	Thấy rule nghiệp vụ nào chưa được kiểm tra.	Xác định quy trình vận hành nào chưa có test.	Dò rule chuyên ngành tới test tương ứng.
Defect record	Nhận lỗi tái lập được, có bước, dữ liệu và evidence.	Quản lý vòng đời lỗi và retest.	Đọc lỗi có dấu hiệu thiết kế, tích hợp hoặc bảo mật.	Nhìn tác động delivery qua trạng thái lỗi.	Hiểu tác động nghiệp vụ mô phỏng của lỗi.	Nhận biết gián đoạn thao tác hoặc hỗ trợ sau triển khai.	Phân tích lỗi thuộc lĩnh vực chuyên môn.
Test execution evidence	Xác nhận bản sửa được kiểm tra trên dữ liệu tổng hợp.	Chứng minh kết quả thực thi đã ghi nhận.	Đọc log, request/response hoặc ảnh màn hình khi liên quan kỹ thuật.	Xem trạng thái kiểm thử của phạm vi release.	Đọc kết quả theo ngôn ngữ nghiệp vụ.	Dùng làm đầu vào chuẩn bị hướng dẫn và hỗ trợ.	Xem bằng chứng điều kiện chuyên ngành đã được chạy.

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

flowchart TD
    BA["BA chuẩn bị test basis"]
    REQ["Requirement"]
    RULE["Business rule"]
    DATA["Test data"]
    SCENARIO["Test scenario"]
    CASE["Test case"]
    TRACE["Traceability matrix"]

    BA -->|"chuẩn bị"| SCENARIO
    BA -->|"chuẩn bị"| CASE
    BA -->|"chuẩn bị"| TRACE

    REQ -->|"xác định coverage"| SCENARIO
    RULE -->|"xác định coverage"| SCENARIO
    SCENARIO -->|"chi tiết hóa"| CASE
    REQ -->|"liên kết nguồn"| CASE
    RULE -->|"liên kết rule"| CASE
    DATA -->|"cung cấp dữ liệu"| CASE

    REQ -->|"ghi nguồn"| TRACE
    RULE -->|"ghi rule"| TRACE
    DATA -->|"ghi dữ liệu"| TRACE
    CASE -->|"ghi coverage"| TRACE

    CASE -->|"giao thực thi"| QA_EXEC["QA thực thi test case"]
    QA_EXEC -->|"ghi actual result"| EVIDENCE["Test execution evidence"]
    QA_EXEC --> RESULT{"Kết quả ban đầu?"}

    RESULT -->|"Pass"| DONE["Kết thúc lần kiểm tra"]
    RESULT -->|"Fail"| DEFECT["Defect record"]

    DEFECT -->|"giao sửa lỗi"| DEV["Developer sửa"]
    DEV -->|"giao kiểm tra lại"| QA_RETEST["QA retest"]
    QA_RETEST -->|"cập nhật actual result"| EVIDENCE
    QA_RETEST --> RETEST{"Kết quả retest?"}
    RETEST -->|"Pass"| DONE
    RETEST -->|"Fail và cập nhật lỗi"| DEFECT

    TRACE -.->|"liên kết nguồn và coverage"| EVIDENCE
    DEFECT -.->|"truy ngược test case"| CASE
    DEFECT -.->|"liên kết bằng chứng lỗi"| EVIDENCE

    EVIDENCE -->|"đọc tác động kỹ thuật"| ARCH["Architect"]
    EVIDENCE -->|"theo dõi phạm vi"| PM["PM/Product Owner"]
    EVIDENCE -->|"đọc kết quả nghiệp vụ"| BO["Business Owner"]
    EVIDENCE -->|"chuẩn bị vận hành"| OPS["Operations"]
    EVIDENCE -->|"kiểm tra điều kiện chuyên môn"| SPEC["Specialist owner"]

Evidence bridge: cùng một test case liên kết requirement, business rule và dữ liệu test. Vì vậy Developer biết cần sửa hành vi nào; QA biết cần chạy gì; các vai trò còn lại biết kết quả đang nói về phạm vi nào. Không có liên kết này, một trạng thái “Pass” chỉ là kết quả rời rạc, không chứng minh coverage.

Applied

Vai trò	Cách dùng output trong Nova Foods mô phỏng
Developer	Đọc test case của luồng tạo Sales Order để tái hiện lỗi khi mã khách hàng tổng hợp không hợp lệ. Dùng defect record để biết build nào bị ảnh hưởng.
QA	Dùng traceability matrix để kiểm tra test case liên kết đúng requirement và CANONICAL_BUSINESS_RULES; dùng execution evidence để retest sau sửa lỗi.
Architect	Đọc test scenario có gọi API đồng bộ khách hàng để nhận biết boundary ERP–API cần được kiểm tra. Đây là đọc tác động kỹ thuật, không phải phê duyệt kiến trúc.
PM/Product Owner	Dùng dashboard execution tổng hợp để thấy phạm vi acceptance criteria nào đã có kết quả test. Không diễn giải tỷ lệ Pass là phê duyệt release.
Business Owner	Đọc expected result bằng ngôn ngữ nghiệp vụ: đơn hàng chỉ chuyển bước tiếp theo khi dữ liệu đầu vào hợp lệ theo rule đang IN_REVIEW.
Operations	Dùng scenario để nhận biết thao tác nhân viên bán hàng, kho và hỗ trợ có thể bị ảnh hưởng khi lỗi xuất hiện.
Specialist owner	Đọc case chứa điều kiện chuyên môn. Ví dụ Accounting Owner đọc điều kiện liên quan ghi nhận kế toán; điều này không biến test case thành diễn giải Luật Kế toán. Verification required vẫn giữ khi nguồn chuyên môn chưa được xác minh.

Senior Lens

Không đổi người đọc thành người sở hữu nội dung. Developer tiêu thụ test case để sửa code, không tự đổi business rule. QA tiêu thụ traceability để kiểm tra coverage, không tự xác nhận rule nghiệp vụ đúng. Architect tiêu thụ evidence kỹ thuật, không dùng output testing để tự ghi nhận compliance. Business Owner và specialist owner đọc kết quả để phản hồi theo thẩm quyền của họ; artifact hiện IN_REVIEW, v0.9.0, ngày 2026-08-07, không có baseline hay approval.

Sai lầm handoff phổ biến: PM/Product Owner đọc “Pass” và hiểu toàn bộ yêu cầu đã hoàn tất. Nghĩa đúng: test case cụ thể đạt trên dữ liệu tổng hợp và điều kiện thực thi đã ghi nhận. Một output chỉ đủ cho người nhận khi giữ source classification, canonical ID, phiên bản và trạng thái nguồn.

Quick Reference

Người nhận	Output ưu tiên	Mục đích đọc
Developer	Test case, defect record	Tái hiện và sửa hành vi
QA	Test scenario, test case, traceability, evidence	Thực thi và kiểm tra coverage
Architect	Scenario tích hợp, technical evidence	Nhận biết tác động boundary kỹ thuật
PM/Product Owner	Traceability, execution summary	Theo dõi phạm vi kiểm thử
Business Owner	Expected result, scenario nghiệp vụ	Đọc tác động nghiệp vụ
Operations	Scenario, defect impact	Chuẩn bị tác động vận hành
Specialist owner	Case và rule thuộc chuyên môn	Đọc điều kiện chuyên ngành

Core

Đầu ra kiểm thử gồm test basis (cơ sở kiểm thử: requirement, business rule, data dictionary, acceptance criteria), test case, test data, defect và traceability matrix (ma trận truy vết). Người nhận không tự đổi nguồn canonical. Họ dùng bằng chứng để quyết định trong thẩm quyền; xung đột phải escalation (chuyển vấn đề đến vai trò có thẩm quyền).

Người nhận	Có thể quyết định	Bằng chứng cần	Phải escalation khi
Developer	Cách sửa lỗi kỹ thuật; phạm vi unit test; nguyên nhân lỗi có tái tạo được	Bước tái tạo, expected result, actual result, dữ liệu tổng hợp, liên kết test basis	Expected result mâu thuẫn business rule; sửa ảnh hưởng API, dữ liệu, bảo mật hoặc integration
QA	Defect có đủ điều kiện ghi nhận; mức ưu tiên kiểm thử; regression scope	Test case, kết quả chạy, môi trường, bằng chứng lỗi, traceability	Không xác định được expected result; lỗi chặn release; rủi ro dữ liệu, bảo mật hoặc accessibility
Architect	Tác động kiến trúc, integration contract, hiệu năng, bảo mật	Luồng lỗi, interface bị ảnh hưởng, payload tổng hợp, dependency, rủi ro	Thay đổi phá vỡ contract; cần đổi mô hình dữ liệu, quyền truy cập hoặc kiến trúc
PM/Product Owner	Thứ tự xử lý; trade-off phạm vi, thời gian, rủi ro	Severity, business impact, phạm vi regression, bằng chứng QA	Quyết định làm thay đổi business outcome, cam kết khách hàng hoặc release risk vượt ngưỡng đã công bố
Business Owner	Ý nghĩa nghiệp vụ của expected result; chấp nhận hay từ chối quy tắc nghiệp vụ	Requirement, CANONICAL_BUSINESS_RULES, ví dụ giao dịch tổng hợp, tác động nghiệp vụ	Quy tắc liên quan giá, doanh thu, chính sách hoặc xung đột giữa đơn vị nghiệp vụ
Operations	Khả năng chạy vận hành, xử lý ngoại lệ, rollback và giám sát	Runbook dự kiến, lỗi tái tạo, tác động batch/interface, dữ liệu tổng hợp	Lỗi có thể mất dữ liệu, gián đoạn vận hành hoặc cần quyền production
Specialist owner: Legal, Accounting, Security, Food-safety	Diễn giải chuyên môn trong phạm vi vai trò	Nguồn chính thức, requirement, dữ liệu bị ảnh hưởng, rủi ro, giả định dự án	Có yêu cầu pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm hoặc truy xuất nguồn gốc. Verification required trước khi dùng cho production

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

flowchart TB
    A[Test result or defect with test basis and evidence] --> B{Expected result clear and consistent with canonical source?}
    B -- No: unclear or conflict --> H{Escalation reason}
    B -- Yes --> C{Recipient role}

    C -- Developer --> C1[Decide technical fix, unit-test scope, or reproducible root cause]
    C -- QA --> C2[Decide defect readiness, test priority, or regression scope]
    C -- Architect --> C3[Assess architecture, integration, performance, or security impact]
    C -- PM/Product Owner --> C4[Decide priority or scope-time-risk trade-off within authority]
    C -- Business Owner --> C5[Decide expected business meaning or business-rule acceptance]
    C -- Operations --> C6[Assess operability, exception handling, rollback, or monitoring]
    C -- Specialist owner --> C7[Interpret Legal, Accounting, Security, or Food-safety matters]

    C1 --> E
    C2 --> E
    C3 --> E
    C4 --> E
    C5 --> E
    C6 --> E
    C7 --> E

    E{Decision exceeds role authority or crosses escalation boundary?}
    E -- No --> K{Specialist decision for production?}
    E -- Yes --> H

    H -- Contract, data model, access, architecture, API, or integration --> X1[Provide affected interface, dependency, payload, and risk]
    H -- Business outcome, price, revenue, policy, or business-unit conflict --> X2[Provide requirement, canonical rules, examples, and business impact]
    H -- Customer commitment, release risk above threshold, or accessibility risk --> X3[Provide severity, business impact, regression scope, and QA evidence]
    H -- Data loss, operational disruption, rollback, or production permission --> X4[Provide runbook, reproduced error, and batch or interface impact]
    H -- Legal, accounting, personal data, security, food safety, or traceability --> X5[Provide official source, requirement, affected data, risk, and assumptions]
    H -- Expected result unclear or conflicting --> X6[Provide test basis, business rules, and conflict evidence]

    X1 --> G[Authorized owner gives decision]
    X2 --> G
    X3 --> G
    X4 --> G
    X5 --> G
    X6 --> G

    G --> K
    K -- Yes --> V[Verify specialist decision before production]
    K -- No --> I[Apply authorized decision without changing canonical source]
    V --> I
    I --> J[Record decision, evidence, and traceability]

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng; dữ liệu tổng hợp. QA chạy test tạo đơn bán hàng trị giá 12.500.000 VND. Hệ thống cho phép lưu đơn khi CustomerID trống.

Current Behavior: API trả 201 Created; đơn được tạo nhưng không liên kết khách hàng.

Underlying Need: Xác định đây là lỗi phần mềm, thiếu test data hay requirement chưa rõ.

Options: Developer chặn CustomerID ở API; QA ghi defect chờ làm rõ; Business Owner xác nhận đơn bán có được phép không gắn khách hàng.

Decision Criteria: CANONICAL_DATA_DICTIONARY có định nghĩa bắt buộc của CustomerID hay không; CANONICAL_BUSINESS_RULES có quy tắc ngoại lệ hay không; test basis có expected result rõ hay không.

Decision: QA không tự kết luận validation bắt buộc. QA escalation vì expected result chưa được chứng minh bởi nguồn canonical.

Authority: Business Owner quyết định ý nghĩa nghiệp vụ; Architect xem xét nếu thay đổi tác động integration; Developer quyết định cách sửa sau khi rule rõ.

Artifact: Defect phải chứa payload tổng hợp, actual result, test basis tham chiếu CANONICAL_DATA_DICTIONARY và CANONICAL_BUSINESS_RULES, cùng nhãn IN_REVIEW, v0.9.0, ngày 2026-08-07.

Consequence if Wrong: Developer tự thêm validation có thể chặn luồng đơn hợp lệ; QA tự đóng defect có thể để dữ liệu đơn không truy vết khách hàng đi vào luồng sau.

Senior Lens

Bằng chứng không phải ý kiến vai trò. Expected result chỉ đáng tin khi nối được tới requirement, business rule hoặc data definition canonical. Thiếu nối này nghĩa là thiếu quyết định, không phải lỗi developer mặc định. BA giữ gói bằng chứng và traceability; BA không thay Business Owner, Architect, Legal, Accounting, Security, QA hoặc Operations phán quyết.

Quick Reference

Tín hiệu	Hành động
Lỗi tái tạo được, expected result rõ	Developer và QA xử lý trong phạm vi kỹ thuật, ghi traceability
Expected result không có nguồn canonical	Escalation đến Business Owner hoặc owner của nguồn
Thay đổi API, schema, quyền hoặc integration	Escalation đến Architect và Security khi có dữ liệu nhạy cảm
Ảnh hưởng số tiền, chứng từ hoặc hạch toán	Escalation đến Accounting Owner; Verification required
Ảnh hưởng dữ liệu cá nhân, thực phẩm hoặc truy xuất	Escalation đến specialist owner; Verification required

Core

Sai hiểu khi bàn giao thường do người nhận suy diễn từ artifact thay vì xác nhận phạm vi quyết định. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, artifact đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, không bên nào được coi nội dung là đã baseline hoặc đã phê duyệt. BA phải biến suy diễn thành câu hỏi có thể trả lời, ghi nhận câu trả lời vào artifact kiểm soát phù hợp, rồi escalation khi câu trả lời thuộc thẩm quyền khác.

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

flowchart TB
    A[BA bàn giao test basis] --> B[Người nhận đọc artifact]
    B --> C{Có điểm thiếu nghĩa, dữ liệu, phạm vi, quyền quyết định hoặc có nguy cơ hiểu sai trạng thái IN_REVIEW?}
    C -- Không --> D[Chỉ dùng artifact theo vai trò và giới hạn trạng thái]
    C -- Có --> E[Đặt câu hỏi làm rõ chính xác]
    E --> F{Quyết định hoặc nội dung cần xác nhận thuộc thẩm quyền người trả lời?}
    F -- Có --> G[Ghi câu trả lời vào artifact kiểm soát phù hợp, kèm nguồn, quyết định và liên kết truy vết]
    F -- Không --> H[Escalation đến owner có thẩm quyền quyết định]
    H --> G
    G --> D

Sai hiểu bàn giao	Rủi ro	Câu hỏi làm rõ chính xác	Escalation khi
Developer hiểu acceptance criteria là thiết kế kỹ thuật	Code chọn API, bảng DB hoặc cơ chế lỗi chưa được Architect xác nhận	“Acceptance criterion này chỉ xác nhận kết quả nghiệp vụ; endpoint, schema dữ liệu và cơ chế retry nào là quyết định kiến trúc cần Architect xác nhận?”	Cần chọn integration pattern, data ownership, bảo mật hoặc cơ chế xử lý lỗi
QA hiểu ví dụ dữ liệu là toàn bộ tập kiểm thử	Bỏ trường hợp biên, dữ liệu lỗi, quyền truy cập	“Ví dụ này minh họa luật nào; miền giá trị hợp lệ, không hợp lệ và điều kiện biên nào phải tạo test case riêng?”	Business rule thiếu điều kiện hoặc mâu thuẫn với CANONICAL_BUSINESS_RULES
PM/Product Owner hiểu lỗi test là thay đổi phạm vi	Defect bị đổi thành change request hoặc ngược lại	“Kết quả hiện tại vi phạm acceptance criterion đã ghi, hay yêu cầu mới ngoài phạm vi artifact?”	Không xác định được nguồn canonical của tiêu chí
Business Owner hiểu trạng thái IN_REVIEW là sẵn sàng vận hành	Quyết định nghiệp vụ dựa trên nội dung chưa kiểm soát	“Nội dung này đang IN_REVIEW; quyết định nghiệp vụ nào cần Business Owner xác nhận trước khi dùng làm test basis?”	Quy tắc ảnh hưởng giá, tồn kho, đơn hàng hoặc quy trình nghiệp vụ
Operations hiểu test pass là vận hành được	Thiếu hướng dẫn xử lý sự cố, quyền, monitoring	“Khi job thất bại, vai trò nào phát hiện, thao tác nào được phép, và bằng chứng nào xác nhận phục hồi?”	Cần thay đổi quy trình vận hành, phân quyền hoặc cam kết dịch vụ
Specialist owner hiểu BA đã diễn giải pháp lý hoặc kế toán	Áp dụng sai nghĩa vụ pháp lý, hạch toán, an toàn thực phẩm	“Đây là project assumption hay yêu cầu đã được Legal Owner, Accounting Owner hoặc domain owner xác minh theo nguồn chính thức?”	Nội dung liên quan dữ liệu cá nhân, hóa đơn, kế toán, truy xuất hoặc thu hồi thực phẩm

Applied

Facts: Test basis mô phỏng ghi: “Đơn bán hàng bị chặn khi vượt hạn mức tín dụng.” Không nêu thời điểm kiểm tra, nguồn hạn mức, ngoại lệ người dùng, hay cách xử lý khi dịch vụ tín dụng không phản hồi.

Current Behavior: Developer chuẩn bị kiểm tra hạn mức lúc tạo đơn. QA chuẩn bị test chặn đơn. Operations cho rằng có thể tạo đơn sau rồi chờ batch đêm kiểm tra.

Underlying Need: Cả ba cần cùng một nghĩa nghiệp vụ có thể kiểm thử: thời điểm kiểm tra, kết quả chặn, dữ liệu chứng minh và xử lý lỗi integration.

Options: (1) Kiểm tra lúc tạo đơn; (2) kiểm tra khi xác nhận đơn; (3) kiểm tra theo batch. Đây là các phương án mô phỏng, không phải cấu hình ERP Nova Foods.

Decision Criteria: Phương án phải chỉ rõ điểm kiểm tra, chủ sở hữu dữ liệu hạn mức, trạng thái đơn khi vượt hạn mức, hành vi khi không lấy được dữ liệu và vai trò có quyền ngoại lệ.

Decision: Chưa chọn phương án. Bằng chứng hiện có chỉ nêu “bị chặn”, không đủ để suy ra thời điểm hoặc cơ chế.

Authority: Business Owner quyết định ý nghĩa nghiệp vụ và ngoại lệ; Architect quyết định integration; Operations xác nhận khả năng xử lý sự cố; QA xác định test coverage sau khi nhận đủ testable condition.

Artifact: Ghi câu hỏi vào test basis liên kết CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY; không tạo ID mới trong micro-batch này.

Consequence if Wrong: Developer và QA có thể cùng hoàn thành công việc nhưng kiểm thử hai hành vi khác nhau; lỗi chỉ lộ khi luồng vận hành gặp dữ liệu hạn mức không phản hồi.

Câu hỏi bàn giao cần ghi nguyên văn:

1. “Điểm nghiệp vụ nào phải kiểm tra hạn mức tín dụng: tạo đơn, xác nhận đơn hay batch; ai có thẩm quyền xác nhận?”
2. “Khi hạn mức bị vượt, đơn chuyển sang trạng thái nào và người dùng nào được phép yêu cầu ngoại lệ?”
3. “Nguồn canonical của hạn mức là gì; CANONICAL_DATA_DICTIONARY đã định nghĩa owner, thời điểm cập nhật và độ trễ dữ liệu chưa?”
4. “Nếu không truy xuất được hạn mức, hệ thống phải chặn, cho lưu nháp hay báo lỗi; quyết định này thuộc Business Owner hay Architect?”
5. “QA cần xem đây là defect với tiêu chí hiện có, hay change request vì tiêu chí chưa mô tả hành vi?”

Senior Lens

Câu hỏi tốt không hỏi “cần làm gì?” vì câu trả lời dễ thành ý kiến. Câu hỏi tốt khóa bốn biến: nguồn bằng chứng, thời điểm, trạng thái kết quả và người có thẩm quyền. Nếu một câu trả lời sửa business rule, data ownership, kiến trúc integration hoặc nghĩa vụ pháp lý, BA không tự hợp nhất câu trả lời thành quyết định. BA ghi nguồn, người trả lời, điểm chưa xác minh và chuyển escalation.

Không dùng “đã thống nhất”, “đã duyệt” hoặc “đã chấp thuận” khi artifact là IN_REVIEW. Cách ghi an toàn: “Cần xác minh với Business Owner”, “Project assumption”, hoặc “Verification required”, tùy bằng chứng hiện có.

Quick Reference

Khi nghe câu này	BA phải hỏi
“QA tự suy ra case còn lại.”	“Luật nào cho phép suy ra; các biên dữ liệu bắt buộc là gì?”
“Developer tự quyết định lỗi integration.”	“Hành vi nghiệp vụ khi dependency lỗi đã được Business Owner xác nhận chưa?”
“Đây là yêu cầu pháp lý.”	“Nguồn chính thức nào xác nhận; Legal Owner đã xác minh chưa?”
“Test pass là đủ deploy.”	“Bằng chứng vận hành, bảo mật và quyền truy cập nào còn cần owner chuyên môn xác nhận?”

8. Detailed Worked Example

Core

Ví dụ làm việc chi tiết biến một yêu cầu mơ hồ thành test basis, tức tập bằng chứng để QA thiết kế và đánh giá kiểm thử. Trong lô này, chỉ ghi nhận Facts và Current Behavior. Chưa kết luận nhu cầu gốc, phương án, tiêu chí chọn, quyết định, thẩm quyền hay artifact quyết định.

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing là case study giáo dục; toàn bộ dữ liệu dưới đây là tổng hợp, dùng locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Corpus đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Không có phê duyệt hay baseline được suy ra từ ví dụ này.

Kịch bản: Nhân viên bán hàng tạo đơn bán hàng cho khách phân phối và nhập mức chiết khấu dòng hàng.

Nhóm fact	Giá trị tổng hợp	Bằng chứng hoặc giới hạn
Người dùng	NV-BH-014, vai trò Sales Executive	Dữ liệu người dùng mô phỏng cho kịch bản kiểm thử.
Khách hàng	KH-PP-021, Công ty Phân phối An Phát	Tên, mã và quan hệ thương mại là dữ liệu tổng hợp.
Đơn hàng	SO-20260807-001	Đơn chưa phát hành hóa đơn, trạng thái màn hình Draft.
Hàng hóa	TP-NUOC-330ML, Nước trái cây Nova 330 ml	SKU và mô tả chỉ phục vụ học liệu.
Số lượng	500 chai	Giá trị nhập trên dòng đơn.
Đơn giá	12.000 VND mỗi chai	Giá trị trước chiết khấu, chưa bàn đến thuế hay hạch toán.
Chiết khấu nhập	15%	Giá trị người dùng nhập tại trường Line Discount %.
Nguồn hạn mức chiết khấu	Chưa xác định trong đầu vào hiện có	Verification required: chưa có bản ghi được xác minh từ CANONICAL_BUSINESS_RULES hoặc artifact nghiệp vụ có thẩm quyền.
Trạng thái artifact nguồn	IN_REVIEW, v0.9.0	Theo artifact quản trị corpus; không phải bằng chứng quyết định vận hành.

Facts: Màn hình tạo đơn hiển thị trường Line Discount % cho từng dòng hàng. Người dùng NV-BH-014 nhập 15 và lưu đơn SO-20260807-001. Giá trị dòng trước chiết khấu là 500 × 12.000 = 6.000.000 VND. Giá trị chiết khấu hiển thị là 900.000 VND. Giá trị dòng sau chiết khấu hiển thị là 5.100.000 VND. Đây là phép tính số học của dữ liệu mô phỏng, không phải quy tắc giá hay chính sách chiết khấu Nova Foods.

Trường payload	Giá trị
salesOrderId	SO-20260807-001
customerId	KH-PP-021
createdBy	NV-BH-014
orderStatus	Draft
itemCode	TP-NUOC-330ML
quantity	500
unitPriceVnd	12000
lineDiscountPercent	15
lineGrossAmountVnd	6000000
lineDiscountAmountVnd	900000
lineNetAmountVnd	5100000

Current Behavior: Khi người dùng bấm Save Draft, ERP mô phỏng lưu đơn thành công và hiển thị thông báo Lưu nháp thành công. Màn hình không hiện hạn mức chiết khấu của người dùng, không hiện nguồn dữ liệu hạn mức, không yêu cầu lý do ngoại lệ, không tạo yêu cầu phê duyệt và không chặn mức 15%. Bằng chứng cho mô tả này là quan sát hành vi giả định của kịch bản; không có artifact nguồn được xác minh chứng minh hành vi này là đúng cho ERP thực tế.

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

flowchart TB
    subgraph SIM["ERP mô phỏng — hành vi quan sát giả định"]
        A[NV-BH-014 mở/tạo đơn SO-20260807-001] --> B[Nhập dòng TP-NUOC-330ML]
        B --> C[500 chai × 12000 VND]
        C --> D[Nhập Line Discount % = 15]
        D --> E[Tính gross 6000000 VND]
        E --> F[Tính discount 900000 VND]
        F --> G[Tính net 5100000 VND]
        G --> H[Bấm Save Draft]
        H --> I[ERP lưu SO-20260807-001<br/>trạng thái Draft]
        I --> J[Hiển thị Lưu nháp thành công]
        J --> K[Không chặn mức 15%]
        K --> L[Không hiển thị hạn mức<br/>hoặc nguồn dữ liệu hạn mức]
        L --> M[Không yêu cầu lý do<br/>không tạo yêu cầu phê duyệt]
    end

    N[Giới hạn bằng chứng:<br/>chỉ quan sát kịch bản ERP mô phỏng;<br/>chưa xác minh cho ERP thực tế] -.-> SIM

Senior Lens

Phân biệt fact với suy luận. “Hệ thống không chặn 15%” là Current Behavior quan sát được. “15% vượt hạn mức” chưa thể ghi vì chưa có nguồn canonical xác định hạn mức, owner và hiệu lực dữ liệu. BA phải giữ khoảng trống này thấy được; không biến phép tính 900.000 VND thành bằng chứng rằng chiết khấu được phép.

Quick Reference

Thành phần	Ghi nhận trong lô này	Không được suy ra
Facts	Dữ liệu đơn, người dùng, SKU, phép tính hiển thị	Chính sách giá hoặc thẩm quyền chiết khấu
Current Behavior	Lưu nháp thành công, không thấy kiểm tra hạn mức	Hành vi này đúng, được duyệt hoặc production-ready
Nguồn nghiệp vụ	Chưa xác định	15% là hợp lệ, sai, vượt ngưỡng hoặc cần phê duyệt

Applied

Bối cảnh mô phỏng: Nova Foods Trading & Manufacturing, dữ liệu tổng hợp, vi-VN, Asia/Ho_Chi_Minh, VND, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Ví dụ dạy cách BA biến quan sát thành kiểm thử được truy vết; không là cấu hình ERP thật, quyết định vận hành, hay xác nhận tuân thủ.

Bước	Nội dung thực hiện	Bằng chứng và cầu nối suy luận
Facts	Đơn bán hàng SO-NF-20260807-001 có khách CUS-NF-001, tổng phải thu 12.500.000 VND, trạng thái Confirmed. Kho WH-HCM-01 còn 80 thùng SKU-NF-NUOCMAM-500; đơn yêu cầu 100 thùng.	Dữ liệu đơn và tồn kho là sự kiện kiểm thử tổng hợp, không phải ý kiến. Thiếu 20 thùng là phép tính 100 - 80.
Current Behavior	Người dùng bấm Xác nhận giao hàng. ERP mô phỏng tạo phiếu giao DN-NF-20260807-001 cho đủ 100 thùng, trừ tồn kho thành -20, vẫn giữ đơn ở Confirmed.	Hành vi quan sát cho thấy hệ thống cho phép tồn âm và phát hành chứng từ giao vượt tồn.
Underlying Need	Nova Foods cần ngăn giao hàng vượt số lượng khả dụng để tránh ghi nhận tồn kho sai và hứa giao không thể thực hiện.	Số lượng giao 100 lớn hơn tồn khả dụng 80; vì vậy kiểm soát phải chạy trước khi tạo phiếu giao. Đây là nhu cầu nghiệp vụ, chưa là quy tắc được phê duyệt.
Options	OPT-NF-001: cho phép tồn âm. OPT-NF-002: chặn toàn bộ xác nhận giao hàng khi thiếu tồn. OPT-NF-003: cho phép giao một phần 80 thùng và giữ lại 20 thùng.	Ba lựa chọn bao phủ hành vi hiện tại, chặn tuyệt đối, và giao một phần. Không suy diễn nghĩa vụ pháp lý hay kế toán.
Decision Criteria	DC-NF-001: không tạo tồn âm. DC-NF-002: không tạo phiếu giao vượt tồn. DC-NF-003: người dùng biết số giao được và số còn chờ. DC-NF-004: đơn còn thiếu vẫn truy vết được.	Tiêu chí xuất phát trực tiếp từ chênh lệch tồn 20 thùng và nhu cầu tránh chứng từ sai.
Decision	Khuyến nghị BA: chọn OPT-NF-003. Tạo phiếu giao 80 thùng; giữ 20 thùng ở đơn; không cho tồn kho âm.	OPT-NF-003 đạt cả bốn tiêu chí: tồn sau giao bằng 0, không vượt tồn, hiển thị phần thiếu, và giữ vết đơn chưa giao đủ. Đây là khuyến nghị kiểm thử, không là quyết định được ủy quyền.
Authority	Business Owner quyết định chính sách cho phép giao một phần. Warehouse Manager xác nhận quy trình kho. Accounting Owner xác nhận ảnh hưởng chứng từ và hạch toán. QA Lead xác nhận test basis và kết quả kiểm thử.	Các vai trò có thẩm quyền khác nhau. Principal IT Business Analyst / Technical Curriculum Author chỉ ghi nhận và duy trì truy vết, không được tự phê duyệt. Tại IN_REVIEW, chưa có approval reference.
Artifact	Ghi yêu cầu giả định REQ-NF-INV-001, quy tắc dự thảo BR-NF-INV-001, tiêu chí chấp nhận AC-NF-INV-001, test case TC-NF-INV-001 trong hồ sơ học liệu. Liên kết quản trị: CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.	Artifact biến khuyến nghị thành test basis, tức tập đầu vào để thiết kế kiểm thử. Các ID trong ví dụ là dữ liệu tổng hợp phục vụ đào tạo; không khẳng định đã đăng ký hay baseline.
Consequence if Wrong	Nếu chọn OPT-NF-001, tồn -20 che giấu thiếu hàng. Nếu chọn OPT-NF-002, đơn giao được 80 thùng bị chặn dù có hàng. Nếu test mong đợi 100 thùng, QA có thể báo pass cho hành vi gây tồn âm.	Mỗi lựa chọn sai tạo lỗi nghiệp vụ khác nhau. Vì vậy expected result phải nêu rõ 80, 20, trạng thái đơn và tồn sau xử lý.

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

flowchart TB
    A["SO-NF-20260807-001<br/>Yêu cầu giao: 100 thùng<br/>Tồn WH-HCM-01: 80 thùng"] --> B["Người dùng bấm<br/>Xác nhận giao hàng"]
    B --> C["Thiếu 20 thùng<br/>100 - 80"]

    C --> D["Hành vi quan sát hiện tại<br/>Tạo DN-NF-20260807-001: 100 thùng"]
    D --> E["Tồn kho thành -20<br/>Đơn vẫn Confirmed"]
    E --> F["Rủi ro<br/>Phiếu giao vượt tồn và tồn âm"]

    C --> G["Khuyến nghị BA<br/>Chọn OPT-NF-003"]
    G --> H["Căn cứ lựa chọn<br/>Không tồn âm<br/>Không giao vượt tồn<br/>Hiển thị giao 80 / chờ 20<br/>Giữ truy vết phần chưa giao"]
    H --> I["Dự thảo test basis<br/>REQ-NF-INV-001, BR-NF-INV-001<br/>AC-NF-INV-001, TC-NF-INV-001"]

    I --> J["Warehouse Manager<br/>cần xác nhận quy trình kho"]
    I --> K["Accounting Owner<br/>cần xác nhận ảnh hưởng<br/>chứng từ và hạch toán"]
    I --> L["QA Lead<br/>cần xác nhận test basis<br/>và kết quả kiểm thử"]
    I --> M["Business Owner<br/>cần quyết định chính sách<br/>giao một phần"]

    M --> N{"Có approval reference<br/>cho OPT-NF-003?"}
    N -->|"Chưa có"| O["Corpus IN_REVIEW<br/>Artifact vẫn là dự thảo"]
    O --> P["Không dùng dự thảo<br/>làm quy tắc vận hành"]

    N -->|"Nếu được phê duyệt"| Q["Kịch bản tương lai<br/>Tạo DN-NF-20260807-001: 80 thùng"]
    Q --> R["Tồn sau giao = 0"]
    R --> S["Còn chờ 20 thùng<br/>Đơn chưa hoàn tất toàn bộ"]

Artifact	Nội dung hoàn chỉnh
REQ-NF-INV-001	ERP phải kiểm tra tồn khả dụng tại kho được chọn trước khi xác nhận giao hàng.
BR-NF-INV-001	Số lượng trên phiếu giao không được lớn hơn tồn khả dụng của SKU tại kho tại thời điểm xác nhận. Project assumption: quy tắc chờ Business Owner và Warehouse Manager xác nhận.
AC-NF-INV-001	Với yêu cầu 100 thùng và tồn khả dụng 80 thùng, hệ thống tạo phiếu giao 80 thùng, ghi nhận còn chờ 20 thùng, và tồn sau giao bằng 0.
TC-NF-INV-001	Tiền điều kiện: SKU-NF-NUOCMAM-500 tại WH-HCM-01 có 80 thùng. Bước: tạo đơn 100 thùng, xác nhận giao hàng. Kết quả mong đợi: DN-NF-20260807-001 có 80 thùng; số còn chờ 20; tồn không âm; đơn không bị đánh dấu hoàn tất toàn bộ.

Phân loại nguồn: thuật ngữ test basis và thiết kế kiểm thử hộp đen tham chiếu nguồn chính ISTQB CTFL Syllabus v4.0.1; nội dung Nova Foods là giả định dự án mô phỏng. Không có suy diễn pháp lý, kế toán, thuế, hay an toàn thực phẩm từ ví dụ này.

Core

Ví dụ kiểm thử dùng test basis: tập bằng chứng làm căn cứ thiết kế kiểm thử, gồm quy tắc, dữ liệu, payload và kết quả mong đợi. 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.

Applied

Trường	Giá trị đầy đủ
Scenario ID	NF-TEST-INV-001
Tên tình huống	Chặn xuất kho lô hết hạn cho đơn bán
Artifact status	IN_REVIEW
Artifact version	v0.9.0
Ngày dữ liệu	2026-08-07
Nguồn quy tắc	/01-curriculum/CANONICAL_BUSINESS_RULES.md, trạng thái IN_REVIEW
Nguồn dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md, trạng thái IN_REVIEW
Ranh giới nguồn	Hai artifact trên là kế hoạch corpus. Không chứng minh quy tắc ERP vận hành hay tuân thủ thực tế.

Bước phân tích	Nội dung hoàn chỉnh	Cầu nối suy luận
Facts	Đơn bán SO-NF-20260807-001 yêu cầu 120 thùng SKU-NUOCMAM-500; kho WH-HCM-01; ngày xuất dự kiến 2026-08-07. Lô LOT-NM500-20260701-A còn 150 thùng, hạn dùng 2026-08-06.	Ngày xuất lớn hơn hạn dùng một ngày. Lô còn đủ số lượng nhưng không còn hợp lệ theo ngày.
Current Behavior	API giữ hàng hiện nhận lô có tồn khả dụng, không so sánh requestedShipDate với expiryDate. API trả thành công và tạo dòng phân bổ 120 thùng.	Điều kiện hiện tại chỉ kiểm tra số lượng. Thiếu kiểm tra hạn dùng.
Underlying Need	Hệ thống phải từ chối phân bổ khi ngày xuất dự kiến sau hạn dùng của lô.	Cần ngăn dữ liệu phân bổ không phù hợp trước bước xuất kho.
Options	OPT-01: giữ logic hiện tại. OPT-02: kiểm tra hạn dùng trong API giữ hàng. OPT-03: chỉ cảnh báo trên màn hình kho.	OPT-01 không xử lý lỗi. OPT-03 phụ thuộc thao tác người dùng và không bảo vệ tích hợp API.
Decision Criteria	Chính xác quy tắc; áp dụng cho UI và API; chặn trước cập nhật tồn; thông báo lỗi truy vết được; không tạo phân bổ dở dang.	OPT-02 đáp ứng cả năm tiêu chí.
Recommendation	BA khuyến nghị OPT-02: API kiểm tra hạn dùng trước khi tạo phân bổ.	Kiểm tra tại điểm ghi dữ liệu dùng chung, nên UI và tích hợp nhận cùng kết quả.
Authorized Decision	Chưa có quyết định được ủy quyền. IN_REVIEW không phải approval, baseline hay production authorization.	Không có tham chiếu approval trong nguồn đầu vào.
Authority	Business Owner quyết định chính sách xuất hàng; Solution Architect quyết định vị trí kiểm tra API; QA Lead xác nhận test coverage. BA ghi nhận traceability, không thay các vai trò này.	Mỗi quyết định thuộc thẩm quyền nghiệp vụ, kỹ thuật hoặc kiểm thử khác nhau.
Artifact	Test case TC-NF-INV-001; payload PAYLOAD-NF-INV-001; rule reference BR-NF-INV-001; trace record TR-NF-INV-001.	ID giữ liên kết từ quy tắc đến payload và kết quả kiểm thử.
Consequence if Wrong	Nếu API chấp nhận lô hết hạn, đơn có thể được phân bổ rồi chuyển sang xuất kho; tồn kho bị giữ sai; cần hủy phân bổ và điều tra dữ liệu.	Sai tại điểm kiểm tra sớm lan sang tồn kho, đơn hàng và vận hành.

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

flowchart TB
    A[POST /api/v1/inventory-reservations] --> B{requestedQuantity > 0?}
    B -- Không --> E[Validation error<br/>Không tạo allocation<br/>availableQuantity không đổi]
    B -- Có --> C{requestedQuantity <= availableQuantity?}
    C -- Không --> F[HTTP 409 INSUFFICIENT_STOCK<br/>Không tạo allocation<br/>availableQuantity không đổi]
    C -- Có --> D{So sánh ngày YYYY-MM-DD<br/>tại Asia/Ho_Chi_Minh:<br/>requestedShipDate <= expiryDate?}
    D -- Không --> G[HTTP 422 LOT_EXPIRED_FOR_SHIPMENT<br/>Không tạo allocation<br/>availableQuantity không đổi]
    D -- Có --> H[HTTP 201<br/>Tạo allocation<br/>availableQuantity: 150 → 30]

Rule ID	Quy tắc hoàn chỉnh	Ví dụ đạt	Ví dụ không đạt
BR-NF-INV-001	Hệ thống chỉ tạo phân bổ khi requestedQuantity lớn hơn 0 và không lớn hơn availableQuantity.	Yêu cầu 120, tồn 150.	Yêu cầu 151, tồn 150.
BR-NF-INV-002	Hệ thống chỉ tạo phân bổ khi requestedShipDate nhỏ hơn hoặc bằng expiryDate, so sánh theo ngày YYYY-MM-DD tại Asia/Ho_Chi_Minh.	Xuất 2026-08-06, hạn dùng 2026-08-06.	Xuất 2026-08-07, hạn dùng 2026-08-06.
BR-NF-INV-003	Khi vi phạm bất kỳ quy tắc nào, hệ thống không tạo allocation và không thay đổi availableQuantity.	Không áp dụng.	Lô hết hạn vẫn giữ availableQuantity = 150.

Payload PAYLOAD-NF-INV-001

{
  "salesOrderId": "SO-NF-20260807-001",
  "warehouseId": "WH-HCM-01",
  "skuId": "SKU-NUOCMAM-500",
  "lotId": "LOT-NM500-20260701-A",
  "requestedQuantity": 120,
  "uom": "THUNG",
  "requestedShipDate": "2026-08-07",
  "currency": "VND"
}

Dữ liệu lô trước gọi API

lotId	skuId	warehouseId	availableQuantity	uom	expiryDate
LOT-NM500-20260701-A	SKU-NUOCMAM-500	WH-HCM-01	150	THUNG	2026-08-06

Kết quả mong đợi TC-NF-INV-001

{
  "status": 422,
  "code": "LOT_EXPIRED_FOR_SHIPMENT",
  "message": "Lot LOT-NM500-20260701-A expires on 2026-08-06 and cannot be reserved for shipment date 2026-08-07.",
  "salesOrderId": "SO-NF-20260807-001",
  "lotId": "LOT-NM500-20260701-A",
  "allocationId": null
}

Test case ID	Điều kiện đầu vào	Hành động	Kết quả mong đợi
TC-NF-INV-001	Payload và dữ liệu lô như trên.	Gọi POST /api/v1/inventory-reservations.	HTTP 422; mã LOT_EXPIRED_FOR_SHIPMENT; không có allocationId; tồn khả dụng vẫn 150.
TC-NF-INV-002	Đổi requestedShipDate thành 2026-08-06.	Gọi cùng API.	HTTP 201; tạo allocation ALLOC-NF-20260807-001; tồn khả dụng thành 30.
TC-NF-INV-003	Đổi requestedQuantity thành 151; giữ ngày xuất 2026-08-06.	Gọi cùng API.	HTTP 409; mã INSUFFICIENT_STOCK; không có allocation; tồn khả dụng vẫn 150.

Senior Lens

Không viết “đã quyết định triển khai OPT-02”. Bằng chứng chỉ cho phép ghi “BA khuyến nghị OPT-02”. Muốn đổi thành quyết định được ủy quyền cần bản ghi quyết định có người có thẩm quyền, ngày, phạm vi và tham chiếu approval; corpus hiện không có bản ghi đó.

Quick Reference

Liên kết	Giá trị
Quy tắc đến test	BR-NF-INV-002 → TC-NF-INV-001, TC-NF-INV-002
Payload đến test	PAYLOAD-NF-INV-001 → TC-NF-INV-001
Truy vết	TR-NF-INV-001
Phân loại	Dữ liệu tổng hợp, Nova Foods mô phỏng, IN_REVIEW, v0.9.0

9. Related Concepts & Dependencies

Core

Dependency (phụ thuộc) là quan hệ trong đó artifact này cần thông tin, định danh hoặc quyết định từ artifact khác để giữ cùng một nghĩa. Traceability (truy vết) là khả năng lần ngược từ đầu ra kiểm thử về nguồn đã tạo ra nó. Hai việc khác nhau: dependency cho biết cần đọc gì; traceability cho biết đã liên kết chính xác với nguồn nào.

Nguồn chân lý canonical là artifact được chỉ định giữ nội dung gốc. Handbook này không chép lại định nghĩa ID, quy tắc, cấu trúc dữ liệu hay danh mục template. Handbook chỉ ghi tham chiếu. Lý do: nếu cùng một quy tắc xuất hiện ở hai nơi, một nơi đổi mà nơi kia không đổi sẽ tạo hai cách hiểu cho cùng nghiệp vụ.

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

flowchart TB
    SM["00_SOURCE_MAP<br/>nguồn, phiên bản, boundary"]
    CA["01_CURRICULUM_ARCHITECTURE<br/>test basis: requirement, rule, data,<br/>acceptance criteria"]
    CM["CHAPTER_MANIFEST<br/>chapter identity và filename"]
    TM["TEMPLATE_MANIFEST<br/>danh mục template và dependency"]
    IR["TRACEABILITY_ID_REGISTRY<br/>namespace và ID canonical"]
    BR["CANONICAL_BUSINESS_RULES<br/>business rule gốc"]
    DD["CANONICAL_DATA_DICTIONARY<br/>nghĩa, kiểu, phân loại dữ liệu"]

    H["/02-handbook/18-testing-fundamentals-for-ba.md<br/>Section 9<br/>chỉ tham chiếu nguồn canonical"]

    TE["Test case và test evidence<br/>tiêu thụ liên kết nguồn"]
    TT["Template test dự kiến<br/>tiêu thụ persistent ID"]

    SM -->|"upstream: nguồn canonical<br/>boundary: không suy diễn ngoài nguồn"| H
    CA -->|"upstream: test basis<br/>boundary: không tự tạo business rule"| H
    CM -->|"upstream: identity, filename<br/>boundary: không đổi identity/filename"| H
    TM -->|"upstream: tham chiếu template/dependency<br/>không phải template hoàn chỉnh/approval"| H
    IR -->|"upstream: namespace, ID canonical<br/>không tự cấp ID mới"| H
    BR -->|"upstream: business rule canonical<br/>không tự tạo hoặc chép rule"| H
    DD -->|"upstream: data dictionary canonical<br/>payload không thay data dictionary"| H

    H -->|"traceability: liên kết test basis<br/>test không đổi nghĩa requirement/rule"| TE
    H -->|"traceability: persistent ID<br/>không dùng text tự do"| TT

Hướng	Artifact hoặc khái niệm	Vai trò với section 9	Boundary
Upstream	/00-research/00_SOURCE_MAP.md (00_SOURCE_MAP)	Xác định nguồn, phiên bản nguồn và giới hạn dùng nguồn.	Không suy diễn điều khoản pháp lý hoặc chuẩn ngoài boundary nguồn.
Upstream	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md (01_CURRICULUM_ARCHITECTURE)	Xác định testing nhận test basis từ requirement, rule, data và acceptance criteria.	Không tự tạo business rule để đủ ví dụ.
Upstream	/01-curriculum/CHAPTER_MANIFEST.md (CHAPTER_MANIFEST)	Giữ canonical chapter identity và filename.	Không đổi title, số section hoặc đường dẫn trong handbook.
Upstream	/01-curriculum/TEMPLATE_MANIFEST.md (TEMPLATE_MANIFEST)	Chỉ ra template dự kiến và dependency của template.	Manifest không phải template đã hoàn chỉnh hay approval.
Upstream	/01-curriculum/TRACEABILITY_ID_REGISTRY.md (TRACEABILITY_ID_REGISTRY)	Giữ namespace và tính duy nhất của persistent ID.	Không tự cấp ID mới trong section này.
Upstream	/01-curriculum/CANONICAL_BUSINESS_RULES.md (CANONICAL_BUSINESS_RULES)	Giữ nội dung gốc của business rule.	Handbook chỉ tham chiếu BR-NF-INV-002, không chép thành rule thứ hai.
Upstream	/01-curriculum/CANONICAL_DATA_DICTIONARY.md (CANONICAL_DATA_DICTIONARY)	Giữ nghĩa trường dữ liệu, kiểu dữ liệu và phân loại dữ liệu logic.	Payload minh họa không thay thế data dictionary.
Downstream	Test case và test evidence	Dùng liên kết nguồn để chọn test basis và giải thích expected result.	Test không tự đổi nghĩa requirement hoặc rule.
Downstream	Template test	Dùng ID canonical để giữ liên kết khi test được cập nhật hoặc rà soát.	Không dùng text tự do thay persistent ID.

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; dữ liệu đều tổng hợp. Ví dụ tồn kho dùng BR-NF-INV-002, TC-NF-INV-001, TC-NF-INV-002, TC-NF-INV-003, TR-NF-INV-001 và endpoint POST /api/v1/inventory-reservations.

Current Behavior: Chapter testing có thể diễn giải test case từ payload, ngày hết hạn lô và HTTP response. Nếu chép lại quy tắc hết hạn vào chapter, learner có thể sửa bản chép nhưng không sửa CANONICAL_BUSINESS_RULES.

Underlying Need: Test case cần biết rule nào sinh ra expected result, nhưng không được biến handbook thành catalog quy tắc hoặc registry ID thứ hai.

Options: (1) Chép toàn bộ nội dung BR-NF-INV-002 vào chapter. (2) Chỉ ghi ID, canonical artifact và vai trò của ID trong test. (3) Dùng mô tả tự do như “rule lô hết hạn”.

Decision Criteria: Liên kết phải tìm được nguồn gốc; ID phải ổn định; thay đổi rule phải phát hiện được vùng bị ảnh hưởng; không tạo nguồn chân lý song song.

Decision: Chọn phương án 2. Ghi BR-NF-INV-002 là tham chiếu đến /01-curriculum/CANONICAL_BUSINESS_RULES.md; ghi TC-NF-INV-001 là test case kiểm tra kết quả từ rule đó. Bằng chứng: CANONICAL_BUSINESS_RULES được định nghĩa là catalog canonical, còn TRACEABILITY_ID_REGISTRY giữ định danh canonical.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và metadata, nhưng không xác nhận rule là quyết định vận hành thực tế, không baseline và không approval.

Artifact: /02-handbook/18-testing-fundamentals-for-ba.md, section 09-dependencies, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, Asia/Ho_Chi_Minh.

Consequence if Wrong: Nếu ghi “rule hết hạn” thay BR-NF-INV-002, reviewer không thể xác định rule nào đổi. Nếu chép rule vào handbook, expected result của TC-NF-INV-001 có thể lệch catalog canonical mà không bị phát hiện.

Senior Lens

Persistent ID (định danh bền vững) không mang nghĩa phiên bản. BR-NF-INV-002 vẫn là cùng thực thể truy vết khi nội dung được cập nhật có kiểm soát; version, trạng thái, lịch sử thay đổi và tham chiếu baseline của artifact quản lý cho biết nội dung tại thời điểm nào. Không thêm hậu tố ngày vào ID để biểu diễn version nếu registry chưa quy định cách đó.

Khi cần giải thích liên kết, dùng công thức: ID + artifact canonical + vai trò dùng. Ví dụ: TC-NF-INV-001 tham chiếu BR-NF-INV-002 trong /01-curriculum/CANONICAL_BUSINESS_RULES.md để xác định điều kiện lô hết hạn không được reserve cho ngày xuất sau hạn. Câu này cho người đọc đủ đường tìm nguồn mà không nhân bản nội dung rule.

Quick Reference

Thành phần cần tham chiếu	Cách ghi đúng	Không ghi
Chapter identity	/02-handbook/18-testing-fundamentals-for-ba.md theo CHAPTER_MANIFEST	Filename biến thể hoặc title tự dịch
Template identity	Tham chiếu TEMPLATE_MANIFEST trước khi dùng template	Tự tạo tên template không có manifest
ID registry	Tham chiếu TRACEABILITY_ID_REGISTRY	Tự sinh REQ, BR, TC mới
Business rule	BR-NF-INV-002 + CANONICAL_BUSINESS_RULES	Chép rule thành bản thứ hai
Data meaning	CANONICAL_DATA_DICTIONARY	Suy diễn field definition từ payload
Source boundary	00_SOURCE_MAP	Gọi nguồn tham khảo là approval hoặc baseline

Core

Ma trận truy vết (traceability matrix) nối nhu cầu với kiểm thử bằng ID ổn định. Mỗi hàng ghi quan hệ kiểm chứng được; không sao chép nội dung gốc. Nova Foods Trading & Manufacturing là case mô phỏng, chỉ dùng dữ liệu tổng hợp, IN_REVIEW, v0.9.0, ngày 2026-08-07.

Chuỗi liên kết	ID	Vai trò trong kiểm thử	Nguồn canonical / bằng chứng
NEED	NEED-NF-TEST-001	Nhu cầu: người dùng kho cần biết lô nguyên liệu nào đủ điều kiện xuất cho lệnh sản xuất mô phỏng.	Nhu cầu nghiệp vụ; ID phải tra trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
REQ	REQ-NF-TEST-001	Yêu cầu hệ thống phải chặn xác nhận xuất nếu lô không có trạng thái đủ điều kiện theo rule được áp dụng.	Requirement là test basis; không thay thế mô tả requirement canonical.
BR	BR-NF-TEST-001	Quy tắc nghiệp vụ quyết định điều kiện lô được phép xuất.	/01-curriculum/CANONICAL_BUSINESS_RULES.md; nội dung rule còn IN_REVIEW, không phải quyết định vận hành.
AC	AC-NF-TEST-001	Tiêu chí chấp nhận: khi chọn lô không đủ điều kiện, hệ thống từ chối xác nhận và hiển thị lỗi nghiệp vụ.	Acceptance criterion gắn với REQ-NF-TEST-001; dùng để xác định pass/fail.
DATA/API	DATA-NF-TEST-001	Dữ liệu thử: lotId, qualityStatus, quantity, uom; API, nếu có, phải kiểm tra hợp đồng request/response.	/01-curriculum/CANONICAL_DATA_DICTIONARY.md; đặc tả HTTP API phải giữ nguồn canonical riêng, không viết lại trong test case.
TC	TC-NF-TEST-001	Test case: chọn lô có qualityStatus = "HOLD" rồi xác nhận xuất. Kỳ vọng: thất bại theo AC-NF-TEST-001.	Test case chứng minh AC, không chứng minh độc lập tính đúng đắn của BR.

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

flowchart LR
  N[NEED-NF-TEST-001] --> R[REQ-NF-TEST-001]
  R --> B[BR-NF-TEST-001]
  R --> A[AC-NF-TEST-001]
  B --> A
  D[DATA-NF-TEST-001] --> T[TC-NF-TEST-001]
  A --> T

Applied

Mục	Nội dung
Facts	Lô mô phỏng LOT-SYN-240807-01 có qualityStatus = "HOLD"; người dùng thử xác nhận xuất cho lệnh sản xuất mô phỏng.
Current Behavior	TC-NF-TEST-001 chưa thể kết luận pass/fail nếu không nối được AC với rule và dữ liệu trạng thái lô.
Underlying Need	QA cần biết kiểm thử đang xác nhận hành vi nào, dựa trên yêu cầu nào, dữ liệu nào và rule nào.
Options	Ghi mô tả tự do trong TC; hoặc dùng chuỗi ID NEED–REQ–BR–AC–DATA/API–TC.
Decision Criteria	Truy ngược được nguồn; không nhân bản nguồn chân lý; phân biệt lỗi requirement, rule, dữ liệu, API và thực thi test.
Decision	Dùng chuỗi ID trong bảng; mỗi ID chỉ liên kết tới artifact canonical tương ứng.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết quản trị. Business Owner xác nhận nhu cầu; QA xác nhận bằng chứng test; Architect xác nhận hợp đồng API khi có; các vai trò này chưa được ghi nhận phê duyệt.
Artifact	/01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md, test artifact chứa TC-NF-TEST-001.
Consequence if Wrong	TC có thể pass dù kiểm tra sai rule, sai dữ liệu, sai endpoint, hoặc bỏ sót acceptance criterion. Báo cáo test khi đó không đủ bằng chứng cho quyết định phát hành.

Senior Lens

NEED trả lời “vì sao cần”; REQ trả lời “hệ thống phải làm gì”; BR giới hạn quyết định nghiệp vụ; AC định nghĩa kết quả chấp nhận được; DATA/API xác định đầu vào, đầu ra hoặc hợp đồng tích hợp; TC tạo bằng chứng thực thi. Suy luận này dựa trên phân tách test basis và test case trong thực hành kiểm thử: test case không được tự tạo quy tắc mới.

Không suy diễn nghĩa vụ pháp lý, kế toán, an toàn thực phẩm hay bảo mật từ chuỗi trên. Nếu BR-NF-TEST-001 viện dẫn nguồn pháp lý hoặc domain rule, giữ nhãn Verification required đến khi Legal Owner, Accounting Owner hoặc domain owner có thẩm quyền xác minh.

Quick Reference

Kiểm tra trước khi chạy TC	Đạt khi
ID tồn tại	Mỗi ID tra được trong registry hoặc artifact canonical được kiểm soát.
Quan hệ đủ	TC liên kết ít nhất AC; AC liên kết REQ; REQ liên kết NEED.
Rule rõ	Có BR khi hành vi phụ thuộc điều kiện nghiệp vụ.
Dữ liệu rõ	Có DATA/API khi kết quả phụ thuộc trường dữ liệu hoặc tích hợp.
Không nhân bản	TC tham chiếu ID, không chép lại nguyên văn requirement, rule hay data dictionary.

Core

Thay đổi lan truyền khi một nguồn phụ thuộc đổi ý nghĩa, cấu trúc hoặc trạng thái; mọi artifact dùng đầu ra đó phải được kiểm tra lại. Ví dụ, CANONICAL_DATA_DICTIONARY đổi kiểu hoặc giá trị hợp lệ của trường lotCode; yêu cầu, tiêu chí chấp nhận, đặc tả API và test case đang dựa trên trường này có thể không còn cùng nghĩa. Đây không phải lỗi “tài liệu cũ”; đây là đứt chuỗi bằng chứng giữa điều cần đạt và cách kiểm thử.

Thay đổi im lặng là thay đổi không có phiên bản, lịch sử thay đổi, đánh giá ảnh hưởng hoặc thông báo đến bên giữ artifact phụ thuộc. Nó nguy hiểm vì ID vẫn còn tồn tại nhưng nội dung sau ID đã khác. Traceability chỉ chứng minh liên kết nếu liên kết trỏ đến đúng phiên bản nội dung đã được xem xét.

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

flowchart TB
    A[Canonical artifact đổi] --> B[Ghi version và lịch sử thay đổi]
    B --> C[Đánh giá ảnh hưởng]
    C --> D[Thông báo bên giữ artifact phụ thuộc]
    D --> E[Bên giữ artifact cập nhật REQ, AC, API hoặc TC]
    E --> F[Kiểm tra liên kết trỏ đúng version đã xem xét]
    F --> G[Kiểm tra test basis]
    A -. thay đổi im lặng .-> H[REQ, AC, API hoặc TC lệch nghĩa]
    H --> I[Test pass giả hoặc lỗi production]

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. CANONICAL_DATA_DICTIONARY là nguồn kiểm soát logic dữ liệu; TRACEABILITY_ID_REGISTRY kiểm soát định danh; cả hai đang IN_REVIEW, v0.9.0, ngày 2026-08-07.

Current Behavior: Test case kiểm tra API nhận lotCode theo cách hiểu đang có trong test basis. Đặc tả API đổi quy tắc chuẩn hóa lotCode, nhưng không cập nhật liên kết, version hoặc test case.

Underlying Need: QA cần biết test đang xác minh đúng hành vi yêu cầu, không chỉ xác minh API vẫn trả HTTP thành công.

Options: Giữ TC cũ; sửa TC theo suy đoán; hoặc dừng dùng TC bị ảnh hưởng, mở đánh giá ảnh hưởng và tham chiếu artifact canonical đã đổi.

Decision Criteria: Có thay đổi ý nghĩa dữ liệu; có artifact phụ thuộc; có bằng chứng version; có thẩm quyền xác nhận nội dung nghiệp vụ và kỹ thuật.

Decision: Chọn đánh giá ảnh hưởng. Không tự suy đoán giá trị hợp lệ mới. Gắn trạng thái “cần xem xét lại” cho TC phụ thuộc đến khi nguồn canonical ghi nhận thay đổi và người có thẩm quyền xác nhận nội dung thuộc phạm vi của họ.

Authority: Principal IT Business Analyst / Technical Curriculum Author giữ liên kết và lịch sử artifact. Business Owner xác nhận ý nghĩa nghiệp vụ; Architect xác nhận hợp đồng tích hợp; QA xác nhận phạm vi test. Không có approval ngầm định từ trạng thái IN_REVIEW.

Artifact: Ghi thay đổi tại artifact canonical liên quan; cập nhật liên kết kiểm soát trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; không sao chép quy tắc dữ liệu sang /02-handbook/18-testing-fundamentals-for-ba.md.

Consequence if Wrong: TC cũ có thể pass vì API trả kết quả hợp lệ về kỹ thuật, nhưng dữ liệu lô không còn đúng nghĩa nghiệp vụ. Hậu quả học liệu là dạy sai test basis; hậu quả nếu áp dụng thực tế có thể là dữ liệu truy vết sai. Đây là rủi ro mô phỏng, không phải kết luận về vận hành Nova Foods.

Senior Lens

Không phải mọi thay đổi đều cần chạy lại mọi test. Phân loại theo loại tác động:

Loại thay đổi im lặng	Cái có thể hỏng	Dấu hiệu cần chặn
Đổi business rule	Kết quả mong đợi của TC sai	TC vẫn dùng expected result cũ
Đổi dữ liệu hoặc schema	Mapping API, dữ liệu test, kiểm tra biên	Tên trường còn nhưng kiểu, độ dài hoặc giá trị hợp lệ đổi
Đổi API contract	Request, response, mã lỗi, tích hợp	Test chỉ kiểm tra HTTP 200
Đổi AC	Phạm vi nghiệm thu và test basis lệch	TC liên kết requirement nhưng không kiểm tra AC mới
Đổi trạng thái hoặc version artifact	Bằng chứng review không còn xác định	Link còn hoạt động nhưng không ghi version nguồn

Quy tắc senior: ID ổn định không thay thế kiểm soát nội dung. Nếu cùng một ID có nội dung khác mà không có lịch sử, không thể chứng minh TC kiểm tra phiên bản nào. Khi đó kết quả test phải được xem là bằng chứng chưa đủ, không phải bằng chứng đạt.

Quick Reference

Khi phát hiện thay đổi	Hành động tối thiểu	Không được làm
Nguồn canonical đổi	Xác định artifact và TC phụ thuộc	Chép nội dung mới vào nhiều nơi
Không rõ thay đổi có ảnh hưởng	Đánh dấu cần đánh giá ảnh hưởng	Tự kết luận không ảnh hưởng
TC dùng dữ liệu hoặc API cũ	Rà test basis, dữ liệu test, expected result	Chạy lại rồi gọi kết quả là hợp lệ
Không có version hoặc lịch sử	Coi liên kết là không đủ bằng chứng	Gán approval hoặc baseline
Có yếu tố pháp lý, kế toán, bảo mật, an toàn thực phẩm	Giữ nhãn Verification required và chuyển đúng owner	Diễn giải thành nghĩa vụ Nova Foods

10. Common Mistakes & Anti-patterns

Core

Testing của BA không phải “chạy màn hình xem có lỗi”. Testing là kiểm tra bằng chứng rằng hệ thống đáp ứng nhu cầu đã xác định. Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp.

Sai lầm	Red flag quan sát được	Nguyên nhân gốc	Hành động sửa
Viết test case sau khi phát triển xong	TC chỉ có bước bấm nút, không có kết quả mong đợi	Nhóm xem test là việc riêng của QA	BA lập test basis từ requirement, business rule, acceptance criteria trước khi build
Dùng câu “hệ thống hoạt động đúng” làm expected result	Người test tự đoán số tiền, trạng thái hoặc thông báo lỗi	Kết quả chưa đo được	Ghi giá trị, trạng thái, quyền truy cập, thông báo hoặc dữ liệu lưu cụ thể
Chỉ test happy path	Không có test dữ liệu rỗng, sai định dạng, vượt giới hạn, trùng lặp	Tập trung demo thay vì rủi ro vận hành	Bổ sung positive, negative và boundary test theo từng điều kiện đầu vào
Test bằng dữ liệu không kiểm soát	Cùng TC cho kết quả khác giữa các lần chạy	Dùng dữ liệu chia sẻ hoặc dữ liệu thay đổi tự do	Ghi rõ dữ liệu test, trạng thái trước test và điều kiện dọn dẹp
Đóng defect bằng lời nói	Defect không có bước tái hiện, bằng chứng hoặc môi trường	Thiếu kỷ luật ghi nhận	Ghi bước tái hiện, actual result, expected result, dữ liệu, môi trường và bằng chứng
Gọi test “pass” khi API trả HTTP 200	Dữ liệu nghiệp vụ sai nhưng test vẫn pass	Chỉ kiểm tra transport, không kiểm tra nội dung response	Kiểm tra mã HTTP, schema, giá trị nghiệp vụ, mã lỗi và tác động dữ liệu
Gộp nhiều mục tiêu vào một TC	Một bước fail làm không rõ rule nào hỏng	TC viết theo màn hình, không theo điều kiện kiểm tra	Tách TC khi expected result hoặc điều kiện nghiệp vụ khác nhau
Sửa requirement sau test nhưng không rà TC	TC cũ vẫn pass dù requirement đã đổi	Không có kiểm tra tác động thay đổi	Rà requirement, rule, AC, test data và TC liên quan trước khi chạy lại

Applied

Facts: Đơn bán hàng mô phỏng Nova Foods có tổng tiền 1.250.000 VND. Người test nhập số lượng 0, bấm lưu, hệ thống trả HTTP 200.

Current Behavior: Nhóm ghi kết quả “Pass vì API thành công”.

Underlying Need: Cần biết hệ thống có ngăn dữ liệu số lượng không hợp lệ trước khi tạo đơn hay không. HTTP 200 chỉ cho biết yêu cầu được xử lý ở tầng giao tiếp; không chứng minh rule nghiệp vụ đúng.

Options:

Phương án	Bằng chứng tạo ra	Điểm yếu
Chỉ kiểm tra HTTP status	Có phản hồi từ API	Không xác minh dữ liệu đơn
Kiểm tra response và dữ liệu lưu	Xác minh phản hồi, mã lỗi, bản ghi tạo ra	Cần dữ liệu test xác định
Kiểm tra UI, API và dữ liệu lưu	Phát hiện lệch giữa các tầng	Chi phí cao hơn

Decision Criteria: Chọn mức kiểm tra đủ để chứng minh điều kiện nghiệp vụ, không chỉ chứng minh endpoint phản hồi. Với rule chặn số lượng 0, cần xác minh không tạo đơn hợp lệ hoặc hệ thống trả lỗi nghiệp vụ được xác định.

Decision: Đổi TC: nhập số lượng 0; kiểm tra response; kiểm tra thông báo; kiểm tra không có đơn hợp lệ được tạo từ dữ liệu test này.

Authority: BA duy trì test basis và expected result. QA xác nhận kỹ thuật test execution. Business Owner xác nhận ý nghĩa nghiệp vụ của việc chấp nhận hoặc từ chối đơn. Không có approval ngầm định tại IN_REVIEW, v0.9.0.

Artifact: Cập nhật TC, dữ liệu test và defect record liên kết tới nguồn requirement hoặc acceptance criteria đang kiểm soát. Không tự tạo rule mới từ kết quả test.

Consequence if Wrong: Đơn có số lượng 0 có thể đi qua luồng bán hàng mô phỏng, làm sai báo cáo số lượng và che giấu lỗi validation.

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

flowchart TB
    A[BA: duy trì test basis và expected result] --> B[Chuẩn bị dữ liệu test kiểm soát]
    B --> C[QA: thực thi test case số lượng 0]
    C --> G[Kiểm tra response, thông báo và không có đơn hợp lệ được tạo]
    G --> D[Đối chiếu kết quả thực tế với expected result]
    D --> E{Đủ bằng chứng?}

    E -->|Chưa đủ| F[Giữ kết quả: chưa đủ bằng chứng]
    F --> B

    E -->|Đủ| H{Lỗi nghiệp vụ hoặc không tạo đơn hợp lệ?}
    H -->|Có| I[Pass có bằng chứng]
    H -->|Không| J[Xác nhận test basis với BA]
    J --> K{Rule có nguồn kiểm soát?}

    K -->|Không| L[Business Owner: làm rõ requirement hoặc acceptance criteria]
    L --> F
    K -->|Có| M[Business Owner: xác nhận ý nghĩa nghiệp vụ]
    M --> N[Ghi defect liên kết requirement hoặc acceptance criteria]
    N --> O[Chạy lại sau bản sửa được xác nhận]
    O --> C

    P[HTTP 200 không quyết định Pass] -.-> G

Cảnh báo: Không đánh dấu Pass chỉ vì màn hình không lỗi hoặc API trả HTTP 200. Điều này có thể che lỗi dữ liệu nghiệp vụ. Ranh giới phục hồi an toàn: giữ kết quả là chưa đủ bằng chứng, bổ sung expected result và chạy lại trên dữ liệu test kiểm soát.

Senior Lens

Senior BA tìm lỗi trong cách nhóm tạo bằng chứng, không chỉ trong phần mềm. Nếu TC không nói rõ điều kiện trước test, dữ liệu đầu vào và expected result, người khác không thể lặp lại kết quả. Khi không thể lặp lại, kết quả không đủ mạnh để hỗ trợ quyết định release.

Quy tắc gọn: mỗi TC phải trả lời được ba câu. Test cái gì? Dùng dữ liệu nào? Kết quả nào chứng minh đạt hoặc không đạt? Thiếu một câu, TC cần sửa trước khi dùng làm bằng chứng.

Quick Reference

Dấu hiệu	Phán đoán	Sửa ngay
Expected result là “thành công”	Không đo được	Thay bằng giá trị hoặc trạng thái cụ thể
TC không có test data	Không tái hiện được	Ghi dữ liệu và trạng thái ban đầu
Pass chỉ dựa HTTP 200	Thiếu kiểm tra nghiệp vụ	Kiểm tra response và dữ liệu lưu
Defect không có bước tái hiện	Không xử lý ổn định	Bổ sung steps, actual result, evidence
Một TC kiểm tra nhiều kết quả khác nhau	Khó xác định lỗi	Tách TC theo mục tiêu kiểm tra

Core

[!WARNING] Rủi ro thật: dùng dữ liệu mô phỏng Nova Foods như bằng chứng vận hành, pháp lý, kế toán hoặc an toàn thực phẩm. Corpus chỉ có dữ liệu tổng hợp, trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; chưa có baseline hay approval. Không được đưa test case lỗi thành xác nhận tuân thủ.

Cảnh báo chỉ dùng khi lỗi có thể gây quyết định sai, mất dữ liệu, sai số tiền VND, lộ dữ liệu cá nhân, hoặc chặn vận hành. Lỗi trình bày nhỏ không cần warning; ghi nhận như lỗi tài liệu thường để tránh làm người đọc mất cảnh giác với rủi ro nghiêm trọng.

Applied

Tình huống thất bại Nova Foods mô phỏng	Dấu hiệu quan sát được	Thiệt hại có thể xảy ra	Phục hồi an toàn
BA ghi “hệ thống đã tuân thủ Luật Bảo vệ dữ liệu cá nhân” sau khi test màn hình ẩn số điện thoại	Không có kết quả review từ Legal Owner; chỉ có ảnh chụp test UI	Đội delivery hiểu sai rằng một test giao diện đủ chứng minh tuân thủ pháp lý	Gỡ kết luận tuân thủ; đổi thành “Verification required”; giữ bằng chứng test ở phạm vi hiển thị dữ liệu; chuyển vấn đề cho Legal Owner và Security
QA dùng đơn hàng tổng hợp NF-SO-2026-001 để kết luận tồn kho thực luôn không âm	Không có nguồn cấu hình kho, dữ liệu đầu kỳ, hoặc quyết định Business Owner	Release có thể chấp nhận luồng xuất kho sai	Khôi phục trạng thái test thành “chưa kết luận”; tách test data khỏi business rule; chỉ tạo defect khi có requirement hoặc rule canonical làm test basis
Tester sửa trực tiếp expected result sau khi hệ thống trả tổng tiền khác	Expected result không còn liên kết requirement; không có lịch sử lý do sửa	Che giấu defect, sai doanh thu hoặc thuế trong dữ liệu mô phỏng VND	Khóa kết quả chạy đã ghi; tạo bản cập nhật test case có lý do; đối chiếu requirement, rule và quyết định có thẩm quyền trước khi chạy lại

Giới hạn phục hồi: được sửa nhãn trạng thái, expected result chưa được phê duyệt, test data tổng hợp và liên kết traceability. Không được tự sửa business rule, diễn giải luật, công thức kế toán, cấu hình ERP, dữ liệu production, hoặc ghi “đã được phê duyệt”. Những việc này cần owner có thẩm quyền và bằng chứng được ghi trong artifact kiểm soát.

Senior Lens

Cảnh báo tốt nêu đủ bốn phần: đối tượng rủi ro, hậu quả, bằng chứng thiếu, hành động chặn. Ví dụ: “Không dùng kết quả test API để xác nhận quyền truy cập an toàn; thiếu review Security và bằng chứng cấu hình môi trường; dừng kết luận security, chuyển Security review.” Lập luận này rõ vì test API chỉ chứng minh phản hồi của API trong điều kiện chạy; nó không tự chứng minh toàn bộ kiểm soát bảo mật.

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

flowchart TB
    A[Phát hiện kết quả test API bị dùng để kết luận security] --> B[Ranh giới bằng chứng: test API chỉ chứng minh phản hồi API trong điều kiện chạy]
    B --> C[Không chứng minh toàn bộ kiểm soát bảo mật]
    C --> D[Đặt warning: rủi ro là kết luận security]
    D --> E[Hậu quả: không thể xác nhận quyền truy cập an toàn]
    E --> F[Bằng chứng thiếu: Security review và cấu hình môi trường]
    F --> G[Hành động chặn: dừng kết luận security]
    G --> H[Chuyển cho Security owner thực hiện review]
    H --> I{Đủ bằng chứng và được Security chấp thuận?}
    I -- Có --> J[Chỉ cập nhật kết luận theo quyết định Security được ghi nhận]
    I -- Không --> K[Giữ trạng thái chặn và ghi rõ bằng chứng còn thiếu]

Quick Reference

Quy tắc	Áp dụng
Warning không phải nhãn trang trí	Chỉ dùng cho rủi ro delivery thật
Test evidence có phạm vi	Không nâng thành approval, compliance hay quyết định nghiệp vụ
Phục hồi phải giữ dấu vết	Không xóa kết quả, không sửa im lặng
Nova Foods là mô phỏng	Dữ liệu tổng hợp không xác nhận ERP thực tế hay production

Core

Năm lỗi khác nhau, không gộp chung thành “yêu cầu chưa rõ”. Mơ hồ là một câu có nhiều cách hiểu hợp lý. Không đầy đủ là thiếu dữ kiện bắt buộc để thực hiện hoặc kiểm thử. Khẳng định thẩm quyền không có bằng chứng là gọi nội dung là “đã phê duyệt”, “theo luật”, “bắt buộc” khi artifact không có nguồn và vai trò xác nhận. Dùng sai ký pháp là gắn tên chuẩn cho sơ đồ không tuân chuẩn đó. Đứt truy vết là không nối được nhu cầu, quy tắc, yêu cầu, tiêu chí chấp nhận và kiểm thử.

Loại lỗi	Red flag quan sát được	Nguyên nhân gốc	Sửa đúng
Mơ hồ	“Duyệt đơn lớn”, không có ngưỡng VND, vai trò, thời điểm	BA ghi ngôn ngữ hội thoại thành rule	Tách điều kiện, hành động, ngoại lệ, nguồn quyết định
Không đầy đủ	Có trường Số lô nhưng không nêu bắt buộc, định dạng, nơi sinh	Chỉ mô tả màn hình, không mô tả dữ liệu và luồng lỗi	Bổ sung quy tắc dữ liệu, trạng thái lỗi, owner, test basis
Thẩm quyền không có bằng chứng	“Luật yêu cầu giữ dữ liệu X năm” không có điều khoản đã xác minh và Legal Owner	Suy diễn từ nguồn thứ cấp hoặc kinh nghiệm cũ	Gắn Verification required; chuyển Legal Owner xác nhận
Dùng sai ký pháp	Sơ đồ PlantUML activity được gọi là BPMN	Nhầm công cụ vẽ với chuẩn mô hình	Gọi đúng là activity diagram; chỉ gọi BPMN khi tuân BPMN 2.0.2
Đứt truy vết	Test case không chỉ được requirement hay rule nguồn	Tạo test từ ghi nhớ, copy bảng cũ	Liên kết về artifact canonical, kiểm tra ID và trạng thái nguồn

[!WARNING] Gắn nhãn “đã phê duyệt” cho nội dung IN_REVIEW tạo rủi ro quyết định sai và mất dấu trách nhiệm. v0.9.0 của corpus Nova Foods chưa có baseline reference hoặc approval reference. Không được dùng trạng thái file, tên Owner, hoặc cuộc họp không có artifact kiểm soát làm bằng chứng thẩm quyền.

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Phiếu nhận hàng mô phỏng ghi: “Kho kiểm tra lô hàng giá trị cao trước khi nhập kho.”

Current Behavior: Nhóm QA viết test “chặn nhập kho khi giá trị cao”. Tài liệu không có ngưỡng VND, cách tính giá trị, người kiểm tra, trạng thái phiếu khi bị chặn, hay liên kết tới rule canonical.

Underlying Need: Cần kiểm thử quyết định nhận hàng có thể tái lập. Suy luận: cùng một dữ liệu đầu vào phải cho cùng kết quả; thiếu ngưỡng và authority khiến QA không xác định expected result.

Options:

Lựa chọn	Hệ quả
Tự đặt ngưỡng 50.000.000 VND	Tạo rule Nova Foods không có thẩm quyền
Giữ câu mơ hồ và test theo hiểu biết QA	Test không lặp lại, defect không phân xử được
Ghi giả định có nhãn và chuyển owner xác nhận	Giữ tiến độ phân tích, không biến giả định thành quyết định

Decision Criteria: Có nguồn canonical; có Business Owner hoặc owner chuyên môn phù hợp; điều kiện tính được; trạng thái và ngoại lệ kiểm thử được; liên kết không vượt ranh giới thẩm quyền.

Decision: Không tạo ngưỡng. Ghi: “Ngưỡng giá trị cao: Verification required; Business Owner xác định. Công thức giá trị: Verification required; Accounting Owner xác nhận nếu ảnh hưởng hạch toán.” Test chỉ kiểm tra hệ thống xử lý được cấu hình ngưỡng sau khi nguồn hợp lệ tồn tại.

Authority: CANONICAL_BUSINESS_RULES là nguồn catalog quy tắc dự kiến, trạng thái IN_REVIEW, không phải bằng chứng phê duyệt. Legal, Accounting, Business Owner, Architect và QA giữ thẩm quyền riêng; Principal IT Business Analyst / Technical Curriculum Author không thay thế các vai trò này.

Artifact: Liên kết quản trị phải giữ nguyên: /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Consequence if Wrong: Nếu QA coi 50.000.000 VND là rule thật, hệ thống mô phỏng có thể chặn hoặc cho nhập kho sai. Recovery an toàn: dừng dùng expected result đó, đánh dấu test là không hợp lệ do thiếu test basis, giữ lịch sử thay đổi, lấy xác nhận từ owner phù hợp rồi tạo lại liên kết. Không sửa im lặng test cũ.

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

flowchart TB
    N["QA cần expected result cho hàng giá trị cao"] --> F{"Đã dùng ngưỡng tự đặt<br/>50.000.000 VND?"}

    F -- "Có" --> S["Dừng dùng expected result<br/>Đánh dấu test không hợp lệ"]
    F -. "Rủi ro" .-> R["Có thể chặn hoặc cho nhập kho sai"]
    S --> H["Giữ test cũ và lịch sử thay đổi<br/>Không sửa im lặng"]
    H --> V["Đánh dấu Verification required"]

    F -- "Không" --> C{"Có nguồn canonical hợp lệ?"}
    C -- "Không" --> V
    C -- "Có" --> P{"Có bằng chứng xác nhận từ<br/>owner đúng thẩm quyền?"}

    P -- "Không hoặc chỉ IN_REVIEW" --> V
    P -- "Có" --> M{"Điều kiện tính được,<br/>trạng thái phiếu và ngoại lệ<br/>kiểm thử được?"}

    V --> Z["Không tự đặt ngưỡng<br/>50.000.000 VND"]
    Z --> D{"Nội dung cần xác nhận"}
    D -- "Ngưỡng giá trị cao" --> BO["Lấy xác nhận từ Business Owner"]
    D -- "Công thức ảnh hưởng hạch toán" --> AO["Lấy xác nhận từ Accounting Owner"]
    D -- "Nội dung khác" --> OO["Lấy xác nhận từ owner chuyên môn phù hợp"]

    BO --> K["Giữ bằng chứng xác nhận"]
    AO --> K
    OO --> K
    K --> W{"Nguồn hợp lệ đã tồn tại?"}
    W -- "Chưa" --> U["Chưa tạo expected result"]
    U --> W
    W -- "Có" --> L["Tạo hoặc cập nhật liên kết"]
    L --> P

    M -- "Không" --> V
    M -- "Có" --> A["Hoàn thiện requirement<br/>và acceptance criteria"]
    A --> Q["QA kiểm tra hệ thống xử lý<br/>ngưỡng đã cấu hình"]
    Q --> T["Expected result dựa trên nguồn hợp lệ<br/>và đúng thẩm quyền"]
    T --> X["Kiểm tra liên kết governance"]

    X --> BR["/01-curriculum/CANONICAL_BUSINESS_RULES.md"]
    X --> TR["/01-curriculum/TRACEABILITY_ID_REGISTRY.md"]
    X --> DD["/01-curriculum/CANONICAL_DATA_DICTIONARY.md"]

Senior Lens

Không dùng “theo ISO”, “theo BPMN”, “theo luật” như dấu chất lượng. Bằng chứng phải khớp phạm vi. ISO/IEC/IEEE 29148:2018 trong source seed chỉ dùng theo abstract và trạng thái thư mục; không tự tạo số điều khoản. BPMN 2.0.2 là nguồn chuẩn cho BPMN; PlantUML activity diagram không thành BPMN vì cùng diễn tả quy trình. Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15, Nghị định 356/2025/NĐ-CP, Luật Kế toán 88/2015/QH13, Nghị định 123/2020/NĐ-CP và Luật An toàn thực phẩm 55/2010/QH12 cần owner pháp lý, kế toán hoặc domain xác minh trước khi biến thành requirement.

Quick Reference

Kiểm tra trước khi nhận test basis	Đạt khi
Rõ nghĩa	Một cách hiểu nghiệp vụ và một expected result
Đủ dữ kiện	Có input, điều kiện, hành động, kết quả, ngoại lệ
Đúng authority	Có nguồn, vai trò phù hợp, trạng thái artifact được nêu đúng
Đúng ký pháp	Tên sơ đồ khớp chuẩn hoặc công cụ đã dùng
Truy vết kín	Nhu cầu, rule, requirement, acceptance criteria, test liên kết được
An toàn governance	Không gọi IN_REVIEW là approved, baselined hay production-ready

11. Senior BA Notes & Rules of Thumb

Senior Lens

Senior BA không chọn test nhiều nhất; chọn bằng chứng đủ mạnh cho rủi ro cần quyết định. Trade-off là đánh đổi có ghi nhận: kiểm tra toàn bộ lô hóa đơn giảm rủi ro sai lệch nhưng tốn thời gian; kiểm tra theo phân vùng dữ liệu giảm chi phí nhưng có thể bỏ sót lỗi ở phân vùng chưa đại diện. Với Nova Foods Trading & Manufacturing là case mô phỏng, dữ liệu tổng hợp, Senior BA phải ghi rõ giả định nào làm cơ sở chọn phạm vi kiểm thử; giả định không phải fact nghiệp vụ.

Tình huống	Trade-off	Ngoại lệ	Quyết định thuộc authority nào
Ưu tiên test luồng xuất hóa đơn	Giá trị tài chính và ảnh hưởng đối soát cao hơn luồng báo cáo nội bộ	Không tự kết luận nghĩa vụ hóa đơn từ Nghị định 123/2020/NĐ-CP	Accounting Owner và Legal Owner xác minh; QA Owner quyết định chiến lược test
Test API đồng bộ tồn kho trước UI	API lỗi có thể lan sang nhiều màn hình; UI lỗi có thể chỉ cục bộ	Không bỏ test UI nếu có yêu cầu trải nghiệm hoặc accessibility	Technical Architect quyết định kiến trúc; QA Owner quyết định độ sâu test
Chấp nhận test data tổng hợp	An toàn hơn dữ liệu cá nhân thật nhưng có thể thiếu hành vi dữ liệu thực	Không đưa dữ liệu cá nhân thật vào môi trường học liệu	Security Owner và Legal Owner xác nhận khi có dữ liệu nhạy cảm
Đóng defect mức thấp	Giảm tồn đọng nhưng có thể che lỗi tích lũy	Không đóng nếu lỗi làm sai số tiền, quyền truy cập, truy xuất nguồn gốc hoặc audit trail	Product/Business Owner quyết định chấp nhận tác động nghiệp vụ; QA Owner xác nhận bằng chứng

Xung đột stakeholder thường không phải “ai đúng”, mà là các bên tối ưu mục tiêu khác nhau. Finance có thể cần kết quả tính tiền chính xác; Operations cần xuất hàng không bị chậm; Technical team cần giới hạn thay đổi để tránh lỗi lan truyền; QA cần bằng chứng tái lập. Senior BA tách yêu cầu khỏi giải pháp: ghi từng lợi ích, rủi ro, tác động, bằng chứng và người có quyền quyết định. Không dùng cuộc họp đông người làm thay cho authority.

Chất lượng bằng chứng	Có thể dùng cho	Không đủ để dùng cho
Test execution có input, bước, actual result, expected result, thời điểm và môi trường	Xác nhận kết quả của test đã chạy	Kết luận quy tắc nghiệp vụ là đúng
Requirement IN_REVIEW có acceptance criteria	Lập test basis tạm thời, có nhãn trạng thái	Gọi là baseline hoặc approved
Ý kiến từ Business Owner	Làm rõ mục tiêu nghiệp vụ	Tự diễn giải pháp luật, kế toán hoặc bảo mật
Văn bản pháp lý trong source seed	Nêu nhu cầu xác minh và rủi ro	Tạo clause, nghĩa vụ chi tiết hoặc cấu hình ERP
Log kỹ thuật và ảnh chụp màn hình	Tái lập defect	Chứng minh toàn bộ hệ thống không có lỗi

Heuristic review: nếu expected result không đo được, test chưa sẵn sàng; nếu defect không tái lập được, ghi điều kiện quan sát và mức tin cậy thay vì suy đoán nguyên nhân; nếu một test case xác nhận đồng thời tiền, quyền truy cập và truy xuất nguồn gốc, tách review theo authority. Red flag gồm: “đã được duyệt” không có approval reference; dùng IN_REVIEW như nguồn chân lý cuối; expected result dựa vào lời kể không có artifact; test data không rõ nguồn; hoặc BA tự chọn cách xử lý khi có tác động pháp lý, kế toán, bảo mật.

Escalate khi sai lệch có thể làm tính sai VND, lộ dữ liệu cá nhân, cấp sai quyền, mất audit trail, làm sai truy xuất thực phẩm, hoặc khi hai authority đưa quyết định mâu thuẫn. Normal rule “test theo requirement hiện hành” không áp dụng khi requirement thiếu authority, mâu thuẫn nguồn canonical, hoặc thay đổi ảnh hưởng luật, kế toán, privacy, food-safety hay security. Khi đó, dừng kết luận pass/fail nghiệp vụ; chỉ báo cáo fact kỹ thuật và chuyển câu hỏi đến owner phù hợp.

Khuyến nghị có thể bảo vệ phải phân biệt fact, inference và uncertainty. Ví dụ ghi: “Fact: test TC-NF-INV-014 với dữ liệu tổng hợp cho tổng đơn 1.250.000 VND trả về giá trị khác expected result. Inference: lỗi có thể nằm ở quy tắc làm tròn hoặc mapping thuế vì chênh lệch xuất hiện sau bước tính tiền. Uncertainty: chưa có rule canonical được Accounting Owner xác nhận. Recommendation: giữ defect mở, gắn Verification required, yêu cầu Accounting Owner xác minh quy tắc trước khi phân loại severity.” Cách ghi này không bịa chắc chắn, vẫn cho decision-maker đủ dữ kiện hành động.

Senior Lens

Senior BA rà test basis trước, không rà test case trước. Test basis là tập requirement, business rule, acceptance criteria, dữ liệu và quyết định làm căn cứ kiểm thử. Nếu test case không truy được về nguồn canonical, kết quả pass không chứng minh đúng nhu cầu.

Heuristic rà soát	Dấu đỏ	Ngưỡng escalation	Ngoại lệ không áp dụng quy tắc thường
Mỗi expected result phải đo được, gồm dữ liệu đầu vào, hành động và kết quả.	“Hệ thống xử lý đúng”, “hiển thị phù hợp”, không có giá trị kiểm tra.	Một acceptance criterion không kiểm thử được sau một vòng làm rõ.	Exploratory testing, kiểm thử khám phá, có thể dùng mục tiêu học hỏi thay expected result cố định; vẫn phải ghi phạm vi và phát hiện.
Dữ liệu test phải đại diện biên hợp lệ, biên không hợp lệ và phân vùng tương đương.	Chỉ test dữ liệu đẹp; dùng số tiền 0 hoặc ngày trống nhưng không nêu ý nghĩa.	Luồng tài chính, tồn kho, truy xuất thực phẩm hoặc dữ liệu cá nhân thiếu test biên.	Prototype chỉ kiểm tra luồng màn hình; không dùng kết quả này để kết luận rule nghiệp vụ đúng.
Phân biệt defect với thay đổi requirement. Defect là hệ thống lệch test basis; change là test basis không còn đáp ứng nhu cầu.	Business Owner nói “sửa theo ý mới” nhưng ticket ghi bug.	Một lỗi yêu cầu đổi rule, quyền, dữ liệu nguồn hoặc tiêu chí chấp nhận.	Lỗi đánh máy không đổi nghĩa, không đổi hành vi, có thể sửa theo kiểm soát tài liệu hiện hành.
Test evidence phải tái lập được: phiên bản, môi trường, dữ liệu tổng hợp, bước chạy, actual result và thời điểm Asia/Ho_Chi_Minh.	Chỉ có ảnh chụp màn hình không nêu dữ liệu đầu vào hoặc build.	Không tái lập được lỗi chặn nghiệm thu, hoặc evidence chứa dữ liệu thật.	Lỗi ngẫu nhiên cần log và tần suất thay vì đòi tái lập 100%; ghi rõ điều kiện quan sát.
Người quyết định mức chấp nhận rủi ro phải đúng thẩm quyền. BA phân tích tác động, không tự chấp nhận rủi ro.	QA bị yêu cầu “pass có điều kiện”; Developer tự quyết ngoại lệ nghiệp vụ.	Tranh chấp làm thay đổi doanh thu, sổ sách, quyền truy cập, dữ liệu cá nhân, an toàn thực phẩm hoặc khả năng thu hồi.	Lỗi giao diện thuần trình bày, không ảnh hưởng accessibility, nghiệp vụ hay dữ liệu, có thể theo ngưỡng chất lượng đã ghi nhận.

Với Nova Foods mô phỏng, dữ liệu tổng hợp, Senior BA dừng kết luận khi nguồn mâu thuẫn. Ví dụ test xác nhận phiếu xuất kho không cho số lượng vượt tồn khả dụng, nhưng CANONICAL_BUSINESS_RULES còn IN_REVIEW và không có rule đã xác nhận. Không gọi đây là defect. Ghi “Verification required”, liên kết nguồn, mô tả tác động và chuyển Business Owner cùng Accounting Owner nếu có ảnh hưởng ghi nhận kế toán.

Ngưỡng escalation không phụ thuộc số defect. Một defect đơn lẻ phải escalation ngay nếu tạo xuất hàng sai lô, mất truy vết, lộ dữ liệu cá nhân, sai quyền phê duyệt, hoặc làm sai số tiền VND. Nhiều defect nhỏ cũng escalation khi cùng nguyên nhân làm test evidence mất tin cậy, như môi trường dùng sai phiên bản hoặc dữ liệu seed không xác định.

Mẫu ghi nhận khuyến nghị: “Khuyến nghị chưa kết luận pass/fail cho test case liên quan xuất kho. Evidence: expected result chưa truy được tới quy tắc canonical đã xác nhận; CANONICAL_BUSINESS_RULES trạng thái IN_REVIEW, v0.9.0, ngày 2026-08-07. Rủi ro: phân loại sai defect thành thay đổi yêu cầu. Quyết định cần: Business Owner xác nhận nhu cầu; Accounting Owner xem xét nếu ảnh hưởng ghi nhận. BA duy trì traceability, không thay thẩm quyền quyết định.”

Senior Lens

Senior BA không viết “đã xác nhận” khi bằng chứng chỉ là trao đổi miệng, ảnh chụp màn hình không có nguồn, hoặc ý kiến từ vai trò không có quyền quyết định. Viết theo cấu trúc: sự thật quan sát được, nguồn, điều chưa biết, ảnh hưởng, khuyến nghị có điều kiện, người cần quyết định. Cách này tách fact khỏi inference (suy luận), nên người đọc kiểm tra lại được.

Trường ghi nhận	Ví dụ Nova Foods mô phỏng, dữ liệu tổng hợp
Fact	Test case TC-SO-014 cho thấy đơn bán SO-NF-000128 vẫn chuyển sang Released khi thiếu mã lô.
Evidence	Nhật ký chạy test ngày 2026-08-07, môi trường mô phỏng; kết quả Failed; không có quyết định nghiệp vụ đính kèm.
Unknown	Chưa xác minh mã lô là bắt buộc tại thời điểm phát hành đơn hay chỉ bắt buộc khi xuất kho.
Impact	Nếu bắt buộc tại Released, test expected result và rule cần sửa; nếu chỉ tại xuất kho, lỗi có thể không tồn tại ở bước này.
Recommendation	Giữ defect ở trạng thái cần làm rõ; không kết luận sai nghiệp vụ. Đề nghị Business Owner xác nhận điểm kiểm soát, rồi QA cập nhật test basis theo quyết định ghi nhận.
Decision authority	Business Owner quyết định policy vận hành; QA Lead quyết định test basis đủ điều kiện; BA ghi traceability.

Ngôn ngữ phải phản ánh độ chắc chắn. Dùng “bằng chứng hiện có cho thấy”, “giả định dự án”, “Verification required”, “nếu Business Owner xác nhận X thì đề nghị Y”. Không dùng “hệ thống phải”, “đúng quy định”, “đã được duyệt” khi chưa có requirement canonical, nguồn chính thức được xác minh, hoặc quyết định từ owner có thẩm quyền.

Mức bằng chứng	Cách ghi khuyến nghị	Không được suy ra
Kết quả test lặp lại, requirement canonical rõ	“Khuyến nghị sửa implementation để đáp ứng requirement đã tham chiếu.”	QA có quyền đổi business rule
Requirement mơ hồ, test thất bại	“Khuyến nghị mở clarification; defect chưa phân loại là lỗi hệ thống hay lỗi test.”	Expected result hiện tại là đúng
Yêu cầu chạm dữ liệu cá nhân, kế toán, an toàn thực phẩm	“Verification required từ Legal Owner, Accounting Owner hoặc domain owner trước khi kết luận.”	BA tự diễn giải nghĩa vụ pháp lý
Hai stakeholder mâu thuẫn	“Ghi hai phương án, tác động từng phương án, quyết định cần từ Business Owner.”	Ý kiến người nói lớn hơn là quyết định

Mẫu ghi vào test finding: “TC-SO-014 thất bại trong môi trường mô phỏng ngày 2026-08-07. Evidence: đơn SO-NF-000128 đạt trạng thái Released khi trường LotCode trống. Test basis hiện không xác định thời điểm bắt buộc nhập lô. Vì vậy chưa đủ bằng chứng kết luận defect ứng dụng. Khuyến nghị Business Owner xác nhận quy tắc thời điểm kiểm tra lô; QA Lead cập nhật expected result sau quyết định được ghi nhận. Nova Foods là case study mô phỏng, dữ liệu tổng hợp; không phải xác nhận vận hành hay tuân thủ production.”

12. Associated Template Reference & Completed Artifact

Core

Template là khuôn tệp chuẩn để ghi nhận cùng loại thông tin theo cấu trúc lặp lại. Template không tự tạo requirement, quyết định nghiệp vụ, approval hay baseline. Với Nova Foods Trading & Manufacturing là case study mô phỏng, chỉ dùng dữ liệu tổng hợp; trạng thái corpus là IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Bằng chứng hiện có chỉ xác nhận /01-curriculum/TEMPLATE_MANIFEST.md là manifest template dự kiến. Seed không cung cấp ID hay filename của template testing đã đăng ký. Vì vậy không được tạo chuỗi như TMPL-TEST-001 hoặc tự suy diễn đường dẫn /03-templates/...; việc đó phá vỡ canonical ID và traceability.

Completed artifact là bản đã được điền từ template đã đăng ký, có ID, filename, owner, consumer và trạng thái truy được từ nguồn canonical. Completed artifact không tự xác nhận test đã chạy, defect đã được xử lý, business rule đã được Business Owner phê duyệt, hay hệ thống Nova Foods sẵn sàng production. Với nguồn hiện có, chưa có completed testing artifact được đăng ký và xác minh cho Chapter 18.

Applied

Facts: Chapter dạy Testing Fundamentals for BA cần chỉ người học đến template phù hợp. Current Behavior: corpus có TEMPLATE_MANIFEST, nhưng dữ liệu nguồn không nêu template testing cụ thể hoặc completed artifact testing cụ thể. Underlying Need: tra đúng template và completed artifact đã đăng ký, không biến chapter thành registry mới. Options: dùng template chưa xác minh; chỉ tham chiếu manifest; tự tạo template ID hoặc completed-artifact path. Decision Criteria: ID, filename, owner và trạng thái phải có bằng chứng canonical; nội dung không được hàm ý approval. Decision: chỉ dùng tham chiếu manifest và artifact canonical hiện có; ghi rõ chưa có template testing hoặc completed artifact testing được seed xác nhận. Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì manifest; QA Lead, Business Owner, Architect, Legal Owner, Accounting Owner giữ thẩm quyền theo nội dung. Artifact: /01-curriculum/TEMPLATE_MANIFEST.md. Consequence if Wrong: test case hoặc defect log có thể gắn sai nguồn chân lý, sai owner, hoặc bị hiểu nhầm là mẫu hay artifact đã được phê duyệt.

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

flowchart TB
    A[BA cần artifact testing] --> B{Manifest có bằng chứng canonical cho ID, filename, owner và trạng thái?}
    B -->|Có| C{Loại artifact?}
    C -->|Template| D{Có template testing canonical đã đăng ký?}
    C -->|Completed artifact| E{Có completed artifact testing canonical đã đăng ký?}
    D -->|Có| F[Dùng đúng ID và đường dẫn canonical]
    E -->|Có| F
    D -->|Không| G[Chưa có template testing được seed xác nhận]
    E -->|Không| H[Chưa có completed artifact testing được seed xác nhận]
    B -->|Không| I[Không tạo ID mới hoặc path mới]
    I --> J[Tham chiếu TEMPLATE_MANIFEST]
    G --> J
    H --> J
    F --> K[Không mặc nhiên hàm ý artifact đã được phê duyệt]
    J --> L[Yêu cầu Principal IT Business Analyst / Technical Curriculum Author xác minh manifest]
    K --> M[Cảnh báo: chọn sai nguồn gây sai source of truth, sai owner hoặc hiểu nhầm artifact đã phê duyệt]
    L --> M

Senior Lens

Không dùng template khi mục tiêu chỉ là giải thích khái niệm, đọc test basis, hoặc nêu ranh giới thẩm quyền. Dùng template khi cần ghi nhận có cấu trúc test condition, test case, test result, defect, traceability hoặc review evidence, với điều kiện template đã xuất hiện trong manifest canonical.

Không gọi artifact là completed chỉ vì có nội dung ví dụ, bảng đã điền một phần, hoặc learner đã dùng nó trong bài tập. Chỉ gọi completed artifact khi manifest hoặc template library đã đăng ký ID, filename và location của artifact đó. Khi chưa có đăng ký, BA phải giữ trạng thái “chưa có location đã xác minh”, không tạo bản thay thế để lấp khoảng trống.

Quality gate là điều kiện kiểm tra trước dùng template hoặc completed artifact: ID và filename khớp manifest; metadata còn IN_REVIEW; owner và consumer rõ; trường dữ liệu không chứa dữ liệu thật; expected result truy được requirement hoặc business rule; nội dung pháp lý, kế toán, dữ liệu cá nhân, an toàn thực phẩm giữ nhãn Verification required khi chưa có xác minh từ owner chuyên môn.

Quick Reference

Template ID / artifact ID	Filename canonical	Dùng khi	Không dùng khi	Owner	Consumer	Quality gate
TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Cần tìm template ID, filename, phạm vi, dependency hoặc completed-artifact location đã đăng ký	Cần ghi test case hay defect cụ thể; manifest không thay template thực thi hoặc completed artifact	Principal IT Business Analyst / Technical Curriculum Author	BA, curriculum author, QA reviewer	ID và filename được lấy nguyên dạng; IN_REVIEW không bị gọi là approved hoặc baselined
CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Cần xác nhận chapter, filename handbook và dependency cấp chapter	Cần thay thế test basis, template testing hoặc completed artifact	Principal IT Business Analyst / Technical Curriculum Author	BA, handbook author, QA reviewer	Đường dẫn chapter khớp manifest; không thêm chapter ID tự phát
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Cần kiểm tra định dạng và nguồn của ID traceability	Cần tạo ID chưa đăng ký hoặc xác nhận business rule	Principal IT Business Analyst / Technical Curriculum Author	BA, QA Lead, Architect	ID giữ nguyên canonical; xung đột ID phải escalation
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Cần lập test basis từ business rule canonical	Cần tự diễn giải quy định pháp lý, kế toán hoặc vận hành	Principal IT Business Analyst / Technical Curriculum Author	BA, QA Lead, Business Owner	Rule có ID, nguồn và mức xác minh; nội dung chưa xác minh giữ Verification required
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Cần xác định field, kiểu dữ liệu, ràng buộc logic cho dữ liệu test	Cần suy diễn schema production hoặc dùng dữ liệu thật	Principal IT Business Analyst / Technical Curriculum Author	BA, QA Lead, Architect	Field name và định nghĩa khớp canonical; chỉ dùng dữ liệu tổng hợp
Chưa có ID template testing được seed xác nhận	Chưa có filename template testing được seed xác nhận	Không áp dụng cho đến khi TEMPLATE_MANIFEST đăng ký rõ	Mọi trường hợp cần tự đặt ID, filename hoặc owner	Không xác định từ bằng chứng hiện có	Không xác định từ bằng chứng hiện có	Dừng dùng; escalation Principal IT Business Analyst / Technical Curriculum Author để đối chiếu manifest
Chưa có ID completed testing artifact được seed xác nhận	Chưa có filename hoặc location completed testing artifact được seed xác nhận	Không áp dụng cho đến khi TEMPLATE_MANIFEST hoặc template library đăng ký rõ	Mọi trường hợp cần tự tạo filled artifact, artifact ID, filename, path hoặc trạng thái	Không xác định từ bằng chứng hiện có	Không xác định từ bằng chứng hiện có	Không liên kết artifact; escalation Principal IT Business Analyst / Technical Curriculum Author để đối chiếu manifest

Quick Reference

Checklist này tra cứu đủ nội dung chapter, không thay thế /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TEMPLATE_MANIFEST.md hoặc registry canonical. Bằng chứng: các artifact nguồn đều IN_REVIEW, v0.9.0, ngày 2026-08-07; vì vậy không được gọi bất kỳ tệp nào là baseline, approved hoặc production-ready.

Mục tra cứu	Cần xác nhận	Nguồn/vị trí canonical	Kết quả cần thấy
Danh tính chapter	Tên, số section, slug	/02-handbook/18-testing-fundamentals-for-ba.md	18 Testing Fundamentals For Ba; section 12-templates-reference
Cấu trúc bắt buộc	Đủ 12 H2 blueprint	/01-curriculum/CHAPTER_MANIFEST.md	Section 12 tên đúng 12. Associated Template Reference & Completed Artifact
Ngữ cảnh case	Nova Foods là mô phỏng; dữ liệu tổng hợp; vi-VN, Asia/Ho_Chi_Minh, VND	/01-curriculum/CHAPTER_MANIFEST.md	Không có dữ liệu doanh nghiệp thật hoặc kết luận vận hành thật
Thuật ngữ testing	Test basis, test case, expected result, defect theo ngữ cảnh học liệu	https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf	Thuật ngữ dùng nhất quán; không gán yêu cầu pháp lý
Liên kết requirement	Requirement, acceptance criterion, business rule, data field có ID canonical khi đã đăng ký	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Không tự đặt ID hoặc đổi chuỗi ID canonical
Quy tắc nghiệp vụ	Rule được dẫn chiếu, không sao chép thành nguồn chân lý thứ hai	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Rule chưa xác minh giữ nhãn Verification required hoặc project assumption
Dữ liệu kiểm thử	Tên trường, kiểu dữ liệu, ràng buộc logic tra từ nguồn dữ liệu canonical	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Dữ liệu ví dụ là synthetic; không suy diễn schema triển khai
Template phù hợp	ID, filename, phạm vi template phải có trong manifest	/01-curriculum/TEMPLATE_MANIFEST.md	Chỉ tham chiếu template đã đăng ký; không tạo tên tệp thay thế
Completed artifact	Artifact ID, filename, location, owner, consumer và trạng thái phải có trong manifest hoặc template library	/01-curriculum/TEMPLATE_MANIFEST.md	Chỉ liên kết artifact đã đăng ký; không gọi ví dụ học liệu là completed artifact
Nguồn ngoài	Phân loại primary source và giới hạn sử dụng	/00-research/00_SOURCE_MAP.md	Không bịa trang, điều khoản, trích dẫn hoặc nghĩa vụ tuân thủ
Trạng thái quản trị	IN_REVIEW, v0.9.0, 2026-08-07	Metadata artifact nguồn	Không diễn giải thành approval hoặc baseline
Artifact đã điền	Đường dẫn và ID phải tồn tại trong manifest/template library trước khi liên kết	/01-curriculum/TEMPLATE_MANIFEST.md	Không có location đã xác minh trong dependency được cung cấp

Vị trí filled Nova Foods artifact: chưa được đăng ký trong nguồn dependency đã xác minh. Không được tự tạo đường dẫn như /03-templates/..., ID template, artifact ID, filename, hoặc tệp completed artifact. Lý do: TEMPLATE_MANIFEST là nguồn kiểm soát cho template dự kiến; seed không cung cấp entry template, completed artifact, hay location artifact đã điền cho chapter này.

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

flowchart TB
    A["Chapter: /02-handbook/18-testing-fundamentals-for-ba.md"] --> B["CHAPTER_MANIFEST:<br/>xác minh slug, đủ 12 H2 và tên H2 12"]
    B --> C["TRACEABILITY_ID_REGISTRY:<br/>tra ID canonical"]
    C --> D["ISTQB CTFL v4.0.1:<br/>kiểm tra thuật ngữ testing nhất quán;<br/>không suy diễn nghĩa vụ pháp lý"]
    D --> E["CANONICAL_BUSINESS_RULES:<br/>tra rule được dẫn chiếu"]
    E --> R{"Rule đã xác minh?"}
    R -- "Không" --> RX["Giữ nhãn:<br/>Verification required hoặc project assumption"]
    R -- "Có" --> F["CANONICAL_DATA_DICTIONARY:<br/>tra data field và ràng buộc"]
    RX --> F
    F --> G["Giữ ranh giới Nova Foods:<br/>mô phỏng; dữ liệu synthetic;<br/>không suy diễn schema triển khai"]
    G --> H["00_SOURCE_MAP.md:<br/>phân loại nguồn và giới hạn sử dụng"]
    H --> I["Giữ trạng thái nguồn:<br/>IN_REVIEW, v0.9.0, 2026-08-07"]
    I --> J{"TEMPLATE_MANIFEST<br/>có template entry đã xác minh?"}
    I --> K{"TEMPLATE_MANIFEST hoặc template library<br/>có completed artifact entry đã xác minh?"}

    J -- "Có" --> JL["Template: dùng ID, filename và phạm vi<br/>theo entry canonical"]
    J -- "Không" --> JN["Template: không liên kết;<br/>không tự tạo ID, filename hoặc path"]

    K -- "Có" --> KL["Completed artifact: dùng Artifact ID, filename,<br/>location, owner, consumer, trạng thái theo entry"]
    K -- "Không" --> KN["Completed artifact: không liên kết;<br/>chưa có location đã xác minh;<br/>không tự tạo ID, filename hoặc path"]

    JL --> Z["Kết quả: chỉ liên kết entry đã xác minh"]
    JN --> Z
    KL --> Z
    KN --> Z

Quy tắc tra cứu: chapter chỉ dẫn chiếu sang nguồn canonical; không chép lại registry đầy đủ. Khi manifest chưa nêu template hoặc filled artifact, kết quả đúng là ghi nhận “chưa có location đã xác minh”, không suy đoán tệp thay thế.

Core

Rà soát liên tệp là đối chiếu cùng một thông tin giữa các artifact kiểm soát trước handoff. Mục tiêu không phải chứng minh Nova Foods đã đúng hoặc được phê duyệt. Mục tiêu là phát hiện mâu thuẫn trước khi tài liệu testing biến giả định thành test basis, tức tập đầu vào dùng để thiết kế kiểm thử. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; mọi kết luận pháp lý, kế toán, an toàn thực phẩm, bảo mật và vận hành thực phải giữ nhãn Verification required khi chưa có chủ thể có thẩm quyền xác minh.

Applied

Trường	Nội dung
Facts	Chapter 18 tham chiếu testing terminology từ ISTQB CTFL Syllabus v4.0.1; corpus hiện IN_REVIEW, v0.9.0, ngày 2026-08-07.
Current Behavior	CHAPTER_MANIFEST, TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY đều mô tả artifact kế hoạch, chưa baseline, chưa approval.
Underlying Need	Không để test case, expected result hoặc defect severity suy diễn thành quy tắc ERP Nova Foods đã xác nhận.
Options	(1) Handoff không ghi vấn đề; (2) Ghi vấn đề nhưng tự kết luận; (3) Ghi evidence, giữ nhãn xác minh, chuyển đúng owner.
Decision Criteria	Bảo toàn canonical ID/path; không vượt thẩm quyền; không gọi IN_REVIEW là approved; không biến nguồn chuẩn thành nghĩa vụ pháp lý chưa xác minh.
Decision	Chọn phương án 3.
Authority	Principal IT Business Analyst / Technical Curriculum Author điều phối gói handoff; chuyên gia theo bảng dưới xác minh nội dung thuộc thẩm quyền.
Artifact	/02-handbook/18-testing-fundamentals-for-ba.md, liên kết kiểm tra với các artifact canonical nêu trong bảng.
Consequence if Wrong	Learner dùng test basis sai; traceability đứt; giả định mô phỏng bị hiểu là quyết định production hoặc nghĩa vụ pháp lý.

Senior Lens

Kiểm tra liên tệp	Evidence phải thấy	Kết quả hiện tại	Open issue / Verification required	Escalation owner
Quản trị chapter	/01-curriculum/CHAPTER_MANIFEST.md ghi IN_REVIEW, v0.9.0, chưa baseline, chưa approval	Khớp metadata corpus	Không được gọi chapter completed artifact là approved hoặc baselined	Principal IT Business Analyst / Technical Curriculum Author
Template và completed artifact	/01-curriculum/TEMPLATE_MANIFEST.md có template ID, filename, phạm vi; nếu có completed artifact thì có ID, filename và location	Chưa có evidence template testing hoặc completed testing artifact trong micro-batch	Verification required: Principal IT Business Analyst / Technical Curriculum Author đối chiếu manifest trước khi liên kết hay dùng artifact	Principal IT Business Analyst / Technical Curriculum Author
Nguồn testing	ISTQB CTFL Syllabus v4.0.1, URL đã xác minh trong 00_SOURCE_MAP	Thuật ngữ testing có nguồn	Xác minh câu diễn đạt không gán clause, page hoặc yêu cầu ngoài syllabus	QA Reviewer
Định danh truy vết	/01-curriculum/TRACEABILITY_ID_REGISTRY.md là nguồn canonical cho ID	Chưa có evidence ID test cụ thể trong micro-batch	Không tạo hoặc đổi ID requirement, rule, data hay test tự do	Principal IT Business Analyst / Technical Curriculum Author
Quy tắc nghiệp vụ	/01-curriculum/CANONICAL_BUSINESS_RULES.md là catalog kế hoạch	Không có rule Nova Foods được xác nhận để dùng làm expected result	Verification required: Business Owner xác nhận rule trước khi dùng cho test nghiệp vụ	Business Owner
Dữ liệu kiểm thử	/01-curriculum/CANONICAL_DATA_DICTIONARY.md là nguồn canonical logic data	Case chỉ dùng dữ liệu tổng hợp	Verification required: field, format, retention, classification và masking trước test có dữ liệu cá nhân	Data Owner; Security Owner; Legal Owner
Pháp lý và tuân thủ	Nguồn luật trong /00-research/00_SOURCE_MAP.md có safe use boundary	Không có diễn giải pháp lý cụ thể	Verification required: mọi yêu cầu privacy, hóa đơn, kế toán, truy xuất thực phẩm phải do chủ thể chuyên môn xác nhận	Legal Owner; Accounting Owner; Compliance Owner; Food Safety Owner
Kiến trúc và tích hợp	Không có interface contract hoặc kiến trúc Nova Foods được xác nhận trong input	Không được suy diễn API, quyền, retry, timeout, integration flow	Verification required: test integration chỉ lập sau khi Architect xác nhận interface boundary	Solution Architect
Bảo mật	OWASP ASVS 5.0.0 và OWASP API Security Top 10 2023 chỉ là nguồn industry practice	Không được tuyên bố compliant	Verification required: test security scope, threat và acceptance evidence	Security Owner

Handoff chỉ đạt điều kiện quản trị khi mọi mâu thuẫn có evidence, owner và nhãn trạng thái. Open issue chưa được xử lý không bị xóa để làm tài liệu gọn hơn; nó đi cùng handoff. IN_REVIEW giữ nguyên nghĩa đang xem xét, không phải xác nhận người dùng, baseline, compliance hay quyền production.