19 Black Box Testing Techniques For Ba

Metadata quản trị chapter

Trường kiểm soát	Giá trị
Artifact ID	HB-19
Tên tệp được kiểm soát	/02-handbook/19-black-box-testing-techniques-for-ba.md
Owner	Chưa có owner được ghi nhận; chưa xác định người chịu trách nhiệm nội dung cho artifact HB-19
Trạng thái	IN_REVIEW
Phiên bản	v0.9.0
Ngày cập nhật	2026-08-07
Múi giờ	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 cho thuật ngữ testing và kỹ thuật black-box
Phân loại nguồn	Nguồn chuẩn đào tạo testing; không phải quy định pháp lý, không xác nhận cấu hình ERP thực tế
Baseline	Chưa có baseline reference tại v0.9.0
Approval	Chưa có approval reference được ghi nhận
Giới hạn sử dụng	Học liệu BA; không thay thế quyết định QA, Business Owner, Architect, Security, Legal, Accounting hoặc quyền dùng production

1. Concept l? g??

Core

Black-box testing là kiểm thử hộp đen: kiểm tra hệ thống từ bên ngoài, dựa trên thứ người dùng hoặc hệ thống khác gửi vào và thứ hệ thống trả ra. Người kiểm thử không cần biết mã nguồn, cấu trúc bảng dữ liệu, thuật toán, hay cách lập trình bên trong. Tên “hộp đen” mô tả góc nhìn: bên trong hộp không quan sát; hành vi tại ranh giới vào-ra mới được đánh giá.

Từ điểm bắt đầu tuyệt đối, một chức năng phần mềm có thể xem là quy tắc biến đổi: nhận input (đầu vào), áp dụng điều kiện nghiệp vụ, rồi tạo output (đầu ra). Black-box testing hỏi: “Với đầu vào này và quy tắc đã được xác định, kết quả có đúng không?” Nó không hỏi: “Lệnh if, hàm, API nội bộ, hay truy vấn DB đã viết thế nào?” Lý do: BA cần xác minh yêu cầu nghiệp vụ được thể hiện đúng ở hành vi quan sát được, không cần thay vai trò lập trình viên đánh giá thiết kế mã.

Test basis là cơ sở kiểm thử: artifact dùng để suy ra điều kiện kiểm thử và kết quả mong đợi. Với BA, test basis thường là business rule, requirement, use case, user story, acceptance criteria, wireframe, data dictionary, hoặc hợp đồng API. Nếu test basis không nói rõ quy tắc, tester không có căn cứ khách quan để kết luận đúng hoặc sai. Vì vậy, black-box testing không thay thế việc làm rõ requirement; nó phơi ra chỗ requirement thiếu, mơ hồ, hoặc mâu thuẫn.

Test condition là điều kiện cần kiểm tra, ví dụ “hệ thống chỉ cho phép ngày giao hàng không sớm hơn ngày đặt hàng”. Test case là tình huống kiểm thử có dữ liệu đầu vào, bước thực hiện, và expected result. Expected result là kết quả mong đợi rút ra từ test basis, không phải phỏng đoán của người test. Actual result là kết quả quan sát khi chạy. Khi actual result khác expected result, đó là defect hoặc sai lệch cần được phân tích; bằng chứng trước hết là liên kết giữa test case và test basis.

Các kỹ thuật black-box giúp BA chọn dữ liệu kiểm thử có mục đích thay vì thử ngẫu nhiên. Chúng tập trung vào giá trị hợp lệ và không hợp lệ, nhóm dữ liệu có hành vi tương đương, điểm biên, tổ hợp điều kiện, chuyển trạng thái, và quy tắc quyết định. Mục tiêu không phải chạy mọi giá trị có thể có; mục tiêu là chọn tập kiểm thử nhỏ nhưng đủ mạnh để phát hiện sai lệch quan trọng theo yêu cầu đã biết.

Ranh giới concept: chapter này nói về kỹ thuật thiết kế kiểm thử dựa trên hành vi và yêu cầu nhìn thấy được. Không bao gồm white-box testing dựa trên cấu trúc mã, unit test của lập trình viên, kiểm thử hiệu năng, penetration test, audit tuân thủ, hoặc quyết định phát hành production. Các hoạt động đó có thể dùng cùng artifact đầu vào, nhưng cần kỹ năng, công cụ, bằng chứng và thẩm quyền riêng.

Core

Black-box testing (kiểm thử hộp đen) kiểm tra hệ thống qua hành vi quan sát được: đưa dữ liệu hoặc sự kiện vào, rồi đối chiếu kết quả thực tế với kết quả mong đợi từ requirement, business rule, acceptance criteria hoặc test basis. Người kiểm thử không cần biết mã nguồn, thuật toán hay cấu trúc bảng dữ liệu bên trong. Theo cách dùng của ISTQB CTFL, đây là nhóm kỹ thuật thiết kế test dựa trên đặc tả và hành vi bên ngoài.

Thuật ngữ	Nghĩa ngắn gọn	Vai trò trong kiểm thử hộp đen
Actor	Tác nhân khởi tạo tương tác: người dùng, vai trò hệ thống, hệ thống ngoài hoặc lịch chạy tự động.	Xác định ai hoặc cái gì thực hiện thao tác. Không tự suy ra quyền của actor nếu test basis chưa nêu.
Action	Hành động actor thực hiện, như nhập, chọn, gửi, xác nhận, hủy.	Tạo kích thích cho hệ thống xử lý. Action phải mô tả được thao tác quan sát được.
Object	Đối tượng chịu tác động, như đơn bán hàng, lô hàng, phiếu nhập, trường số lượng.	Giới hạn đúng dữ liệu hoặc thực thể cần kiểm tra.
Outcome	Kết quả quan sát được sau action: thông báo, trạng thái, giá trị, bản ghi, quyền truy cập hoặc dữ liệu gửi đi.	Là cơ sở kết luận pass/fail. Outcome phải kiểm chứng được, không dùng nhận xét mơ hồ như “hệ thống chạy đúng”.
Input	Dữ liệu, điều kiện hoặc sự kiện đưa vào hệ thống.	Dùng chọn lớp dữ liệu hợp lệ, không hợp lệ và biên.
Expected result	Kết quả mong đợi đã truy được về test basis.	Chuẩn đối chiếu; không phải suy đoán của tester.
Actual result	Kết quả thực tế khi chạy test.	Bằng chứng để ghi pass, fail hoặc blocked.
Test case	Trường hợp kiểm thử có tiền điều kiện, input, bước chạy và expected result.	Đóng gói kiểm tra để chạy lặp lại và truy vết.
Test basis	Nguồn làm căn cứ thiết kế test: requirement, rule, acceptance criteria, mockup hoặc interface contract.	Nguồn chân lý cho expected result.
BBT	Viết tắt của Black-Box Testing.	Nhãn nhóm kỹ thuật; không phải một test case riêng.

Mẫu tư duy tối thiểu là: Actor thực hiện Action trên Object, hệ thống tạo Outcome. Ví dụ mô phỏng Nova Foods Trading & Manufacturing, dữ liệu tổng hợp: nhân viên Kho thực hiện action “nhập số lượng nhận hàng” trên object “dòng lô hàng nhận” với input 0; outcome cần kiểm tra là phản hồi ERP theo test basis đang áp dụng. Đây là kiểm thử hộp đen vì người kiểm thử chỉ xác định input và quan sát outcome; không kiểm tra câu lệnh SQL, hàm tính toán, cấu trúc API hay mã ERP bên trong.

Ranh giới khái niệm: kiểm thử hộp đen trả lời “với điều kiện này, hệ thống có thể hiện hành vi yêu cầu không?”. Nó không tự chứng minh chất lượng mã nguồn, hiệu năng tải lớn, an toàn bảo mật, tuân thủ pháp lý, tính đúng của quy tắc nghiệp vụ chưa được xác nhận, hoặc tính chính xác của cấu hình production. Nova Foods trong ví dụ là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp; không phải bằng chứng về ERP thực tế hay phê duyệt nghiệp vụ.

Applied

Ví dụ tối thiểu, Nova Foods Trading & Manufacturing mô phỏng: nhân viên kho nhập mã lô LOT-SYN-001 khi xác nhận nhận hàng. Hệ thống ERP cho phép giá trị gồm 1–12 ký tự chữ hoa, số và dấu gạch nối. Black-box testing kiểm tra hành vi tại giao diện hoặc API dựa trên đặc tả đầu vào và kết quả mong đợi; không xem mã nguồn, cấu trúc bảng DB hay thuật toán kiểm tra.

Thành phần	Nội dung mô phỏng, dữ liệu tổng hợp
Actor	Nhân viên kho, người gửi dữ liệu nhận hàng
Action	Nhập mã lô rồi chọn xác nhận
Object	Trường Lot Code của phiếu nhận hàng
Outcome mong đợi	Mã hợp lệ được chấp nhận; mã rỗng, dài quá 12 ký tự hoặc có ký tự không cho phép bị từ chối kèm thông báo lỗi
Test basis	Quy tắc mô phỏng: Lot Code bắt buộc; 1–12 ký tự; chỉ A-Z, 0-9, -
Kỹ thuật black-box phù hợp	Equivalence Partitioning: chia nhóm hợp lệ và không hợp lệ; Boundary Value Analysis: kiểm tra độ dài 0, 1, 12, 13

BA không cần biết hệ thống dùng biểu thức chính quy, hàm kiểm tra nào, hay lưu Lot Code trong bảng nào. Bằng chứng: các chi tiết đó thuộc thiết kế nội bộ; người dùng và người kiểm thử quan sát được giá trị nhập cùng phản hồi hệ thống. Vì vậy, test case black-box phải nêu điều kiện đầu vào và kết quả quan sát được, không nêu cách lập trình phải dùng.

Ranh giới concept	Bao gồm	Loại trừ
Góc nhìn	Hành vi quan sát được từ bên ngoài	Logic mã nguồn, thuật toán, câu lệnh SQL, cấu trúc DB
Căn cứ	Requirement, business rule, acceptance criteria, API contract, mockup đã được cung cấp	Suy đoán yêu cầu chưa ghi nhận
Mục tiêu	Phát hiện sai khác giữa hành vi thực tế và kết quả mong đợi	Chứng minh code tối ưu, an toàn tuyệt đối hoặc không có mọi lỗi
Kết quả	Test condition, test case, dữ liệu test, expected result, defect evidence	Phê duyệt requirement, baseline, quyết định production

Mã lô, quy tắc và phản hồi trên chỉ là giả định học liệu cho Nova Foods mô phỏng, dữ liệu tổng hợp. Không phải quy tắc truy xuất thực phẩm, cấu hình ERP, hay nghĩa vụ pháp lý. Nếu ví dụ được dùng để suy ra yêu cầu truy xuất nguồn gốc thực tế, cần xác minh với domain owner và legal/compliance owner trước khi tạo rule hoặc test basis có tính bắt buộc.

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

Core

Kiểm thử hộp đen (black-box testing) tồn tại để kiểm tra hành vi nhìn thấy được của hệ thống mà không phụ thuộc vào mã nguồn, cấu trúc DB hay thuật toán nội bộ. Người dùng ERP nhận kết quả từ dữ liệu nhập, quyền thao tác, quy tắc nghiệp vụ, API và thông báo lỗi. Nếu BA không chuyển các điều kiện quan sát được này thành test condition và expected result, đội phát triển có thể hoàn thành chức năng theo một cách hiểu khác với nhu cầu nghiệp vụ.

Rủi ro chính là mơ hồ requirement. Câu “hệ thống kiểm tra mã lô” không nói rõ giá trị nào hợp lệ, lúc nào kiểm tra, hệ thống phải chặn hay cảnh báo, và kết quả nào người dùng quan sát được. Developer có thể cho phép lưu; QA có thể chỉ thử một mã hợp lệ; người dùng vận hành có thể phát hiện lỗi sau khi dữ liệu đã đi vào quy trình tiếp theo. Lỗi khi đó không còn là lỗi một màn hình: có thể kéo theo sửa rule, sửa dữ liệu tổng hợp, cập nhật test case, chạy lại regression test và làm lại tài liệu bàn giao.

ISTQB CTFL Syllabus v4.0.1 dùng black-box techniques để dẫn xuất kiểm thử từ đặc tả và hành vi mong đợi. Với BA, giá trị không nằm ở việc thay QA viết mọi test case. Giá trị nằm ở việc làm test basis đủ rõ để QA, developer và stakeholder cùng kiểm tra cùng một hành vi.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Giả định học liệu: màn hình ghi nhận lô hàng có trường Lot Code; rule mô phỏng yêu cầu trường này bắt buộc, dài từ 1 đến 12 ký tự, chỉ chứa A-Z, 0-9, -.

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

flowchart TB
    A[Người dùng nhập Lot Code] --> B{Bắt buộc; dài 1–12 ký tự; chỉ gồm A-Z, 0-9, -}
    B -->|Hợp lệ| C[Cho phép lưu và hiển thị kết quả thành công]
    B -->|Không hợp lệ| D{Nhóm dữ liệu bị từ chối}
    D -->|Rỗng| E[Không lưu; hiển thị lỗi quan sát được]
    D -->|Dài hơn 12 ký tự| F[Không lưu; hiển thị lỗi quan sát được]
    D -->|Chứa ký tự ngoài A-Z, 0-9, -| G[Không lưu; hiển thị lỗi quan sát được]

Khi không dùng tư duy hộp đen, BA có thể bàn về “hàm validate” hoặc “cột DB” thay vì hành vi cần kiểm tra. Đây là lệch phạm vi: code và DB là thiết kế nội bộ; hành vi nhận hoặc từ chối dữ liệu mới là cam kết có thể quan sát. Hậu quả dự án là test không phủ các nhóm dữ liệu sai như rỗng, dài 13 ký tự, hoặc chứa ký tự ngoài tập cho phép. Lỗi chỉ lộ khi người dùng nhập dữ liệu thực tế trong môi trường vận hành mô phỏng.

Rủi ro bị ngăn chặn	Cơ chế black-box	Bằng chứng reasoning
Requirement mơ hồ	Nêu input, điều kiện, expected result	Hai người chỉ có thể kiểm tra nhất quán khi cùng thấy rõ dữ liệu và phản hồi cần có
Rework muộn	Phát hiện sai khác trước khi chấp nhận chức năng	Sai khác giữa expected result và actual result được ghi nhận trước khi lan sang quy trình sau
QA chỉ kiểm happy path	Dùng phân vùng tương đương và giá trị biên	Một ví dụ hợp lệ không đại diện cho dữ liệu rỗng, sai ký tự, quá ngắn hoặc quá dài
Tranh cãi trách nhiệm	Liên kết test condition với test basis	Defect có thể đối chiếu về rule, acceptance criteria hoặc API contract đã cung cấp
Governance yếu	Không suy diễn rule từ thiết kế nội bộ	BA giữ ranh giới giữa yêu cầu quan sát được và quyết định kỹ thuật của Architect/developer

Senior Lens

Black-box testing không chứng minh hệ thống không có lỗi. Nó tạo bằng chứng có cấu trúc rằng hành vi đã kiểm tra khớp hoặc không khớp test basis. Vì vậy, không được gọi một chức năng là “đúng hoàn toàn” chỉ vì vài test case chạy đạt. Phạm vi kiểm tra phải gắn với rule, điều kiện đầu vào và kết quả mong đợi đã ghi nhận.

BA cần dừng suy diễn khi test basis không xác định được kết quả mong đợi. Ví dụ, nếu requirement chỉ ghi “kiểm tra mã lô” nhưng không xác định cho phép ký tự nào, không thể tự chọn biểu thức kiểm tra rồi gọi đó là requirement Nova Foods. Cách xử lý đúng là ghi nhận khoảng mơ hồ để Business Owner hoặc domain owner làm rõ; sau đó QA mới có căn cứ tạo kiểm thử.

Quick Reference

Câu hỏi BA phải trả lời	Mục đích ngăn lỗi
Người dùng hoặc hệ thống bên ngoài đưa vào dữ liệu gì?	Xác định input có thể kiểm tra
Điều kiện nào làm dữ liệu hợp lệ hoặc không hợp lệ?	Loại bỏ diễn giải khác nhau
Hệ thống phải cho phép, từ chối hay cảnh báo?	Xác định hành vi quan sát được
Người dùng thấy kết quả nào?	Tạo expected result kiểm chứng được
Test basis nằm ở artifact nào?	Giữ traceability, tránh suy đoán từ code

Applied

Nova Foods Trading & Manufacturing là case mô phỏng, dữ liệu tổng hợp. Tình huống dùng màn hình tạo phiếu nhận hàng. Quy tắc minh họa: trường Số lượng nhận chỉ chấp nhận số nguyên từ 1 đến 500; đây là test basis giả định học liệu, không phải quy tắc vận hành Nova Foods.

Trạng thái	Cách kiểm thử	Dữ liệu nhập	Hệ quả quan sát được
Trước khi dùng kỹ thuật hộp đen	Tester chỉ thử một giá trị “có vẻ hợp lệ”	100	Phiếu được tạo. Chưa có bằng chứng cho giá trị biên, số âm, 0, 501, số thập phân hoặc ký tự.
Sau khi dùng phân vùng tương đương	Chia dữ liệu thành nhóm hợp lệ và không hợp lệ có hành vi dự kiến giống nhau	100, 0, 501, 12.5, ABC	Mỗi nhóm có ít nhất một đại diện. Lỗi chấp nhận 0 hoặc 12.5 trở thành lỗi quan sát được, không còn là suy đoán.
Sau khi dùng phân tích giá trị biên	Kiểm tra sát ranh giới vì lỗi điều kiện thường nằm tại điểm chuyển trạng thái	0, 1, 500, 501	Xác nhận hệ thống nhận 1 và 500; từ chối 0 và 501 với phản hồi phù hợp. Nếu kết quả khác, BA truy ngược test basis thay vì tự sửa yêu cầu.

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

flowchart TB
    A[Nhập Số lượng nhận] --> B{Kiểm tra theo test basis}
    B -->|1 đến 500, số nguyên| C[Cho tạo phiếu nhận]
    B -->|Số âm, 0, trên 500, thập phân, ký tự| D[Từ chối và báo lỗi]

Khác biệt trước/sau là bằng chứng kiểm thử. Trước đó, “phiếu tạo được với 100” chỉ chứng minh một đường đi hợp lệ. Sau đó, tập test mô tả rõ lớp dữ liệu nào hệ thống phải xử lý và cho thấy kết quả thực tế tại từng ranh giới. Nhờ vậy, lỗi không bị nhầm thành thao tác người dùng, lỗi giao diện, hay thay đổi ngầm của quy tắc.

Nếu không kiểm thử hộp đen theo lớp và biên, đội phát hiện muộn rằng hệ thống nhận dữ liệu không mong muốn hoặc chặn dữ liệu hợp lệ. Hệ quả thấy được: phiếu nhận có giá trị không dùng được, người dùng phải hủy hoặc sửa giao dịch, QA mở defect thiếu phạm vi rõ ràng, BA phải làm rõ lại test basis. Kỹ thuật này không quyết định quy tắc nghiệp vụ; nó biến quy tắc đã có thành các đầu vào và kết quả có thể kiểm tra.

Core

Trong black-box testing, BA phải tách loại phát biểu trước khi biến nó thành test condition (điều kiện cần kiểm thử). Nếu không tách, câu nói trong họp dễ bị ghi thành business rule, rồi QA kiểm thử một điều chưa được quyết định. Rủi ro là rework, tranh chấp phạm vi và traceability sai: test có kết quả “pass” nhưng hệ thống vẫn không đáp ứng nhu cầu thật.

Loại	Định nghĩa	Bằng chứng tối thiểu	Có được viết thành expected result?
Verified fact	Sự kiện đã đối chiếu được với nguồn hoặc artifact kiểm soát.	URL nguồn chính thức, dữ liệu quan sát được, hoặc artifact canonical có trạng thái phù hợp.	Có, nếu fact liên quan hành vi cần kiểm thử.
Stakeholder input	Ý kiến, nhu cầu, cách làm hiện tại do stakeholder cung cấp.	Người nói, vai trò, ngày ghi nhận, ngữ cảnh.	Chưa. Cần phân tích hoặc quyết định.
Project assumption	Điều tạm giả định để tiếp tục phân tích khi thiếu dữ kiện.	Lý do giả định, ảnh hưởng, owner xác minh, điều kiện hết hiệu lực.	Chỉ cho test tạm; phải gắn nhãn assumption.
Decision	Lựa chọn giữa các phương án theo tiêu chí và thẩm quyền xác định.	Phương án, tiêu chí, người có thẩm quyền, artifact ghi nhận.	Có, sau khi decision được ghi nhận hợp lệ.
Verification-required claim	Phát biểu có thể ảnh hưởng pháp lý, kế toán, thuế, an toàn thực phẩm, bảo mật hoặc vận hành nhưng chưa đối chiếu nguồn/thẩm quyền.	Câu hỏi xác minh, nguồn cần kiểm tra, owner phù hợp.	Không. Không được biến thành rule hay expected result.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Với chức năng ERP tạo phiếu xuất kho cho đơn bán mô phỏng SO-NF-2026-081, BA ghi nhận các phát biểu sau:

Nhãn	Nội dung	Cơ sở phân loại	Xử lý trong test basis
Fact đã xác minh	/01-curriculum/CHAPTER_MANIFEST.md có Status IN_REVIEW, Version v0.9.0, ngày 2026-08-07.	Có artifact kiểm soát được cung cấp trực tiếp.	Không suy ra approval hay baseline.
Stakeholder input	Quản lý kho mô phỏng nói: “Kho thường xuất hết tồn trước.”	Đây là mô tả thực hành từ một vai trò, chưa chứng minh là quy tắc ERP.	Ghi nguồn input; hỏi phạm vi, ngoại lệ, ưu tiên lô.
Project assumption	Khi chưa có catalog quy tắc được xác nhận, giả định phiếu xuất chỉ tạo khi tồn khả dụng đủ số lượng yêu cầu.	Cần giả định để minh họa test; chưa có decision hoặc rule canonical được xác nhận.	Gắn ASSUMPTION; không gọi là yêu cầu chính thức.
Decision	Chưa có quyết định về xuất một phần đơn hàng mô phỏng.	Không có artifact quyết định hay thẩm quyền ghi nhận trong đầu vào.	Không tạo expected result cho partial shipment.
Verification required	“Xuất kho bắt buộc theo FIFO để tuân thủ pháp luật.”	Phát biểu kết hợp nghiệp vụ kho với kết luận pháp lý; seed không xác minh nghĩa vụ FIFO.	Chuyển Legal Owner và Business Owner xác minh; không tạo test pass/fail.

Facts: IN_REVIEW không phải APPROVED hoặc BASELINED; điều này được nêu trong các artifact dependency. Current Behavior: stakeholder input và giả định thường bị chép chung vào test case. Underlying Need: test chỉ kiểm tra hành vi có nguồn và trạng thái rõ. Options: coi mọi phát biểu là rule; hoặc gắn nhãn nguồn và trạng thái. Decision Criteria: có bằng chứng, có thẩm quyền, có ảnh hưởng đến expected result. Decision: dùng nhãn năm loại trước khi tạo test condition. Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì traceability; Business Owner, Legal Owner, Accounting Owner, Architect hoặc QA xác nhận nội dung thuộc thẩm quyền của họ. Artifact: /02-handbook/19-black-box-testing-techniques-for-ba.md, liên kết quản trị tới TRACEABILITY_ID_REGISTRY khi ID được đăng ký. Consequence if Wrong: QA có thể xác nhận sai hành vi, đội delivery sửa lại sau review, hoặc tài liệu học liệu bị hiểu nhầm là quy định vận hành.

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

flowchart TD
    A["Phát biểu đầu vào"] --> P["Principal IT Business Analyst hoặc Technical Curriculum Author ghi nguồn, trạng thái; liên kết ID khi đã đăng ký"]
    P --> D{"Là lựa chọn được thẩm quyền phù hợp ghi nhận?"}
    D -->|"Có"| E["Decision"]
    D -->|"Không"| PS{"Là partial shipment chưa có quyết định?"}

    PS -->|"Có"| ND["Không tạo expected result cho partial shipment"]
    PS -->|"Không"| V{"Là phát biểu thực tế được artifact có thẩm quyền xác nhận?"}
    V -->|"Có"| F["Verified fact"]
    V -->|"Không"| S{"Stakeholder cung cấp phát biểu?"}

    S -->|"Có"| I["Stakeholder input"]
    I --> Q["Ghi nguồn và hỏi phạm vi, ngoại lệ, ưu tiên lô"]
    Q --> X{"Cần Owner chuyên môn xác minh?"}
    X -->|"Không"| B["Giữ nhãn gốc trong test basis"]
    X -->|"Có"| C["Verification-required claim"]

    S -->|"Không"| X2{"Cần Owner chuyên môn xác minh?"}
    X2 -->|"Có"| C
    X2 -->|"Không"| N{"Cần giả định để phân tích?"}
    N -->|"Có"| U["Project assumption"]
    N -->|"Không"| NV["Chưa xác minh; không tạo expected result"]

    C --> O["Chuyển Business Owner, Legal Owner, Accounting Owner, Architect hoặc QA phù hợp"]
    O --> OC{"Owner đã xác nhận nội dung?"}
    OC -->|"Không"| NV
    OC -->|"Có"| R["Ghi nguồn và trạng thái xác nhận"]
    R --> G{"Đã thành rule hoặc decision có thẩm quyền và đủ expected result?"}
    G -->|"Không"| NV
    G -->|"Có"| T

    F --> T{"Có chi phối hành vi cần kiểm tra?"}
    E --> T
    T -->|"Có"| TC["Tạo test condition"]
    T -->|"Không"| B

    U --> UT["Tạo test tạm có nhãn ASSUMPTION"]
    TC --> B
    UT --> B

    P -.->|"Nếu bỏ kiểm soát"| RISK["Rủi ro false pass, false fail và rework"]

Senior Lens

Không nâng cấp stakeholder input thành fact chỉ vì nhiều người lặp lại. Không nâng cấp assumption thành decision chỉ vì team đã code theo assumption. Không dùng cụm “đã được phê duyệt” khi artifact nguồn còn IN_REVIEW. Chuỗi suy luận phải thấy được: phát biểu nào, nguồn nào, ai có thẩm quyền, trạng thái nào, rồi mới đến expected result.

Quick Reference

Câu hỏi kiểm tra	Nếu “không”	Nhãn an toàn
Có nguồn kiểm soát hoặc quan sát đối chiếu được?	Không gọi là fact.	Stakeholder input hoặc assumption
Có người có thẩm quyền ghi nhận lựa chọn?	Không gọi là decision.	Assumption hoặc verification-required claim
Claim có nói về nghĩa vụ pháp lý, kế toán, thuế, an toàn thực phẩm hoặc bảo mật?	Không có xác minh chuyên môn.	Verification required
Có thể nêu expected result mà không tự suy diễn?	Không.	Không tạo test case pass/fail

3. V? tr? trong Lifecycle

Core

Black-box testing là kiểm thử hành vi quan sát được từ bên ngoài, không dựa vào cấu trúc mã nguồn. Vì expected result chỉ đáng tin khi có test basis, kỹ thuật này không bắt đầu ở lúc QA chạy test. Nó đi xuyên suốt Lifecycle: Discovery tạo vấn đề và ranh giới; Analysis biến ranh giới thành rule, dữ liệu và acceptance criteria; Delivery biến chúng thành phần mềm; Testing đối chiếu hành vi thực tế; Release kiểm tra điều kiện đưa bản phát hành ra môi trường; Operations dùng lỗi thực tế để bổ sung rủi ro và điều kiện kiểm thử.

Giai đoạn	Entry gate chính xác	Hoạt động black-box của BA	Exit gate chính xác
Discovery	Có vấn đề nghiệp vụ, mục tiêu và phạm vi mô phỏng Nova Foods	Nhận diện actor, sự kiện, kết quả nghiệp vụ, ngoại lệ thấy được	Có phạm vi hành vi; chưa gọi là rule đã phê duyệt
Analysis	Có phạm vi hành vi và nguồn đầu vào truy vết được	Tách input domain, rule, trạng thái, boundary, expected result	Mỗi test condition truy đến fact, decision, assumption hoặc verification-required claim
Delivery	Có requirement và test condition đủ rõ để build	Làm rõ câu hỏi khi thiết kế không thể quyết định hành vi từ artifact	Build trả về bản triển khai và thay đổi đã ghi nhận
Testing	Có test basis, môi trường và dữ liệu tổng hợp	QA áp dụng equivalence partitioning, boundary value analysis, decision table hoặc state transition theo test condition	Mỗi kết quả Pass, Fail hoặc Blocked có evidence; lỗi được liên kết test condition
Release	Có kết quả test, lỗi còn mở và tiêu chí release đã ghi nhận	Kiểm tra không có điều kiện nghiệp vụ chưa xác minh bị diễn giải thành Pass	Có quyết định release thuộc thẩm quyền; IN_REVIEW không phải approval
Operations	Có sự cố, phản hồi hoặc số liệu vận hành quan sát được	Phân loại hành vi mới thành defect, gap, assumption sai hoặc nhu cầu thay đổi	Insight quay lại Discovery hoặc Analysis với evidence; không sửa expected result im lặng

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

flowchart TB
    D[Discovery<br/>Vấn đề và phạm vi]
    A[Analysis<br/>Rule, data, test condition]
    DE[Delivery<br/>Build theo requirement]
    T[Testing<br/>Thực thi black-box]
    R[Release<br/>Đánh giá điều kiện phát hành]
    O[Operations<br/>Quan sát hành vi thực tế]

    D -->|Phạm vi hành vi, input truy vết| A
    A -->|Test basis truy vết được| DE
    DE -->|Bản triển khai, thay đổi, test basis, môi trường, dữ liệu| T
    T -->|Kết quả test, lỗi mở, tiêu chí release| R
    R -->|Quyết định release| O
    O -->|Insight, sự cố có evidence| D
    O -->|Insight có evidence| A

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. Một yêu cầu màn hình tạo đơn bán hàng nêu: số lượng đặt phải lớn hơn 0.

Current Behavior: Nếu BA đợi QA nhận build mới tạo test, QA chỉ thấy một điều kiện “nhập số lượng hợp lệ”. Câu này không chỉ ra 0, số âm, số thập phân, ô trống hay giá trị rất lớn phải cho kết quả nào.

Underlying Need: Tạo test condition trong Analysis trước Delivery. Lý do: các giá trị quanh ranh giới 0 là input khác nhau về mặt hành vi; black-box testing cần expected result trước khi biết mã nguồn xử lý chúng ra sao.

Mục	Nội dung
Options	Chỉ test 1; test -1, 0, 1; hoặc lập đầy đủ partition và boundary theo data type đã xác minh
Decision Criteria	Rule có nói rõ miền giá trị; data type có nguồn; expected result có truy vết; claim pháp lý hoặc kế toán có xác minh chuyên môn
Decision	Tại Analysis, ghi test conditions cho -1, 0, 1 và gắn nguồn rule. Giá trị lớn chỉ thêm khi artifact nêu giới hạn hoặc có evidence kỹ thuật.
Authority	BA phân tích và duy trì traceability. Business Owner xác nhận ý nghĩa nghiệp vụ. Architect xác nhận giới hạn kỹ thuật khi liên quan. QA quyết định thực thi test.
Artifact	Requirement, acceptance criteria, test condition và liên kết traceability trong artifact kiểm soát; trạng thái corpus hiện là IN_REVIEW, version v0.9.0, ngày 2026-08-07.
Consequence if Wrong	Test Pass có thể chỉ chứng minh số 1 hoạt động. Hệ thống vẫn có thể nhận 0 hoặc số âm, tạo lỗi nghiệp vụ sau Release.

Senior Lens

Entry gate không phải cuộc họp đã diễn ra. Entry gate là bằng chứng tối thiểu cho phép giai đoạn sau làm việc mà không tự đoán. Exit gate không phải “đã xong”; nó là điều kiện kiểm tra được để handoff không làm mất ngữ cảnh. Ví dụ, “rule rõ” không đủ mạnh; “test condition 0 có expected result và nguồn rule” mới kiểm tra được.

Không dùng kết quả Testing để hợp thức hóa rule mơ hồ. Nếu build chấp nhận 0 nhưng artifact không nêu hành vi này, kết quả đúng là gap hoặc cần làm rõ, không phải tự đổi expected result thành “chấp nhận 0”. Nếu claim liên quan thuế, 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 chưa được nguồn chính thức và owner có thẩm quyền xác minh, giữ nhãn Verification required; không tạo kết luận Pass/Fail từ claim đó.

Quick Reference

Điểm kiểm	Câu hỏi	Không đạt thì làm gì
Discovery exit	Đã biết ai tương tác, sự kiện nào xảy ra, kết quả nào thấy được?	Quay lại làm rõ phạm vi hành vi
Analysis exit	Test condition có nguồn và expected result không?	Không chuyển sang test execution
Delivery entry	Build team có thể quyết định hành vi mà không suy diễn không?	Nêu câu hỏi cho BA và owner phù hợp
Testing entry	Có dữ liệu tổng hợp, test basis và môi trường không?	Ghi Blocked, không ghi Pass
Release entry	Lỗi còn mở và rủi ro đã thấy rõ không?	Escalate cho thẩm quyền release
Operations exit	Sự cố có evidence và được phân loại không?	Không sửa rule hoặc test case im lặng

Core

Black-box testing là kiểm thử hộp đen: kiểm tra hệ thống qua đầu vào, đầu ra và hành vi quan sát được, không dựa vào mã nguồn. BA không quyết định pass/fail kỹ thuật thay QA; BA giữ ý nghĩa nghiệp vụ của test condition, dữ liệu và expected result. Phân quyền này cần rõ vì cùng lỗi “giảm giá sai” có thể do rule sai, cấu hình sai, dữ liệu sai hoặc mã sai; mỗi nguyên nhân thuộc owner khác.

Handoff	Upstream owner	Nội dung bàn giao	Downstream owner	Giới hạn thẩm quyền	Escalation
Business rule sang test basis	Business Owner, BA	Rule, ví dụ, ngoại lệ, acceptance criteria	QA Lead, QA Tester	BA không tự xác nhận rule là quyết định kinh doanh cuối cùng; QA không tự sửa rule	Rule mâu thuẫn, thiếu ngoại lệ, ảnh hưởng doanh thu: Business Owner
Requirement sang delivery	BA	Traceability ID, test condition, expected result	Developer, Solution Architect	Developer không đổi expected result để hợp mã hiện có	Không khả thi kỹ thuật, ảnh hưởng tích hợp: Solution Architect và BA
Test data sang execution	BA, Data Owner	Dữ liệu tổng hợp, phân loại dữ liệu, điều kiện biên	QA Tester	QA không dùng dữ liệu cá nhân thật; BA không cấp quyền môi trường	Có dữ liệu nhạy cảm hoặc quyền truy cập quá mức: Security Owner
Defect sang quyết định xử lý	QA Lead	Bằng chứng tái hiện, actual result, expected result, mức ảnh hưởng	BA, Developer, Business Owner	QA ghi nhận lỗi; BA làm rõ ý nghĩa; Business Owner quyết định chấp nhận rủi ro nghiệp vụ	Sai giá, thuế, kế toán, an toàn thực phẩm: owner chuyên môn phù hợp

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

flowchart TB
    BO[Business Owner]
    BA[BA]
    DO[Data Owner]
    QA[QA Lead / QA Tester]
    DEV[Developer]
    ARCH[Solution Architect]
    SEC[Security Owner]
    EXP["Owner giá, thuế, kế toán hoặc an toàn thực phẩm"]
    BOB["Boundary: BA không quyết định kinh doanh cuối cùng"]
    QAB["Boundary: QA không tự sửa rule"]
    DEF["Boundary: QA ghi nhận defect; BA làm rõ ý nghĩa"]
    DEVB["Boundary: Developer không đổi expected result để hợp mã"]
    ENV["Boundary: BA không cấp quyền môi trường"]
    PII["Policy: QA không dùng dữ liệu cá nhân thật"]

    BO -->|Rule, ưu tiên, ngoại lệ, acceptance criteria| BA
    BA -->|Traceability ID, test condition, expected result| QA
    BA -->|Traceability ID, test condition, expected result| DEV
    BA -->|Traceability ID, test condition, expected result| ARCH

    BA -->|Dữ liệu tổng hợp, phân loại, điều kiện biên| QA
    DO -->|Dữ liệu tổng hợp, phân loại, điều kiện biên| QA
    BA -.- ENV
    QA -.- PII

    QA -->|Bằng chứng tái hiện, actual result, expected result, mức ảnh hưởng| BA
    QA -->|Bằng chứng tái hiện, actual result, expected result, mức ảnh hưởng| BO
    QA -->|Bằng chứng tái hiện, actual result, expected result, mức ảnh hưởng| DEV
    BA -->|Làm rõ rule hoặc expected result khi defect| QA
    BO -->|Quyết định chấp nhận rủi ro nghiệp vụ| QA

    DEV -->|Không khả thi kỹ thuật, ảnh hưởng tích hợp| ARCH
    DEV -->|Không khả thi kỹ thuật, ảnh hưởng tích hợp| BA
    ARCH -->|Đánh giá giải pháp kỹ thuật| BA

    BA -->|Rule mâu thuẫn, thiếu ngoại lệ, ảnh hưởng doanh thu| BO
    QA -->|Dữ liệu nhạy cảm hoặc quyền truy cập quá mức| SEC
    BA -->|Dữ liệu nhạy cảm hoặc quyền truy cập quá mức| SEC
    DO -->|Dữ liệu nhạy cảm hoặc quyền truy cập quá mức| SEC
    QA -->|Sai giá, thuế, kế toán, an toàn thực phẩm| EXP

    BA -.- BOB
    QA -.- QAB
    QA -.- DEF
    DEV -.- DEVB

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. Test condition TC-NF-ORD-001 kiểm tra đơn bán có tổng tiền hàng 10.000.000 VND và mức giảm giá 10%.

Trường	Nội dung
Current Behavior	ERP mô phỏng trả tổng giảm giá 1.200.000 VND.
Underlying Need	Xác định đây là defect, rule chưa rõ, hay dữ liệu test sai trước khi giao Developer sửa.
Options	1. QA tự ghi lỗi “tính giảm giá sai”. 2. BA đối chiếu expected result với rule nguồn. 3. Developer tự điều chỉnh công thức theo giả định.
Decision Criteria	Expected result phải truy được về rule; người đổi rule phải có thẩm quyền nghiệp vụ; người sửa mã phải nhận bằng chứng tái hiện.
Decision	Chọn phương án 2. BA kiểm tra traceability giữa TC-NF-ORD-001 và rule canonical trước; QA giữ actual result và bước tái hiện. Nếu rule xác nhận mức 10%, QA tạo defect cho Developer.
Authority	Business Owner xác nhận chính sách giảm giá mô phỏng. BA không tự đặt lại mức giảm giá. QA không tự đóng defect vì “có vẻ hợp lý”. Developer không tự đổi expected result.
Artifact	Test condition, test execution record và defect record phải giữ cùng traceability ID đang được đăng ký; không tạo ID biến thể.
Consequence if Wrong	Nếu Developer sửa theo giả định, hệ thống có thể tính sai doanh thu và báo cáo liên quan. Đây là suy luận từ việc tổng giảm giá tác động trực tiếp số tiền đơn hàng, không phải kết luận kế toán hay pháp lý.

Senior Lens

Escalation không phải chuyển trách nhiệm. Escalation là đưa quyết định tới đúng người khi bằng chứng vượt quyền người đang xử lý. BA phải đóng gói: fact quan sát được, artifact nguồn, traceability ID, lựa chọn, tác động và câu hỏi quyết định. BA không được nâng cấp suy đoán thành business rule.

Nếu vấn đề chạm thuế, 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, gắn nhãn Verification required. Lý do: nguồn corpus xác định các lĩnh vực này cần owner có thẩm quyền xác minh; case Nova Foods không phải xác nhận vận hành hay tuân thủ thực tế.

Quick Reference

Tình huống	Owner quyết định	BA làm gì
Expected result thiếu	Business Owner	Nêu khoảng trống, không tự điền rule
Test không tái hiện được	QA Lead	Kiểm tra test data, bước chạy, môi trường
Rule đúng nhưng hệ thống sai	Developer	Sửa kỹ thuật, liên kết defect với test evidence
Giải pháp ảnh hưởng tích hợp	Solution Architect	Đánh giá ràng buộc kỹ thuật
Có dữ liệu nhạy cảm	Security Owner	Dừng dùng dữ liệu đó, ghi nhãn Verification required

Core

Bản đồ vòng đời cho thấy kỹ thuật kiểm thử hộp đen được chuẩn bị trước khi kiểm thử và tiếp tục tạo bằng chứng sau phát hành. “Kiểm thử hộp đen” kiểm tra đầu vào, hành vi quan sát được và đầu ra, không cần suy luận mã nguồn bên trong. Suy luận: yêu cầu mô tả kết quả mong đợi; kỹ thuật hộp đen biến kết quả đó thành điều kiện kiểm tra; vì vậy kỹ thuật phải đi cùng yêu cầu từ lúc hình thành, không chỉ xuất hiện ở giai đoạn Testing.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Sơ đồ không xác nhận quy trình ERP thực tế, baseline, approval hoặc quyền đưa vào production. Trạng thái corpus: IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

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

flowchart TB
    D["Discovery<br/>Nêu vấn đề và kết quả nghiệp vụ"]
    A["Analysis<br/>Làm rõ yêu cầu, quy tắc, dữ liệu và tiêu chí chấp nhận"]
    DV["Delivery<br/>Cấu hình hoặc xây dựng thay đổi"]
    T["Testing<br/>Thiết kế, chạy và ghi nhận kiểm thử hộp đen"]
    R["Release<br/>Đưa thay đổi đã đủ bằng chứng theo quyết định có thẩm quyền"]
    O["Operations<br/>Quan sát hành vi thực tế, lỗi và phản hồi"]

    D --> A --> DV --> T --> R --> O

    A -. "Phân vùng tương đương,<br/>giá trị biên, bảng quyết định,<br/>chuyển trạng thái" .-> T
    T -. "Kết quả, lỗi, độ bao phủ<br/>điều kiện nghiệp vụ" .-> R
    O -. "Sự cố hoặc thay đổi nhu cầu" .-> D
    O -. "Bằng chứng quan sát,<br/>sai lệch kết quả, điều kiện kiểm tra cần cập nhật" .-> A

Quick Reference

Điểm trên bản đồ	Vai trò của kỹ thuật hộp đen	Bằng chứng tối thiểu cần nhìn thấy
Discovery	Chỉ ra hành vi nào cần kiểm chứng về sau	Vấn đề và kết quả mong đợi được diễn đạt quan sát được
Analysis	Chọn kỹ thuật phù hợp dạng logic: ngưỡng dùng giá trị biên; tổ hợp điều kiện dùng bảng quyết định; trạng thái dùng kiểm thử chuyển trạng thái	Requirement, business rule, dữ liệu và acceptance criteria có thể chuyển thành test condition
Delivery	Đối chiếu thay đổi được tạo với hành vi đã mô tả	Phạm vi thay đổi tham chiếu đúng test basis
Testing	Chạy test case từ góc nhìn người dùng hoặc hệ thống gọi API; so sánh actual result với expected result	Test case, test data tổng hợp, kết quả chạy và defect nếu lệch
Release	Dùng bằng chứng kiểm thử làm đầu vào cho quyết định phát hành, không thay thế quyết định đó	Báo cáo kết quả và rủi ro còn lại
Operations	Biến lỗi quan sát được thành đầu vào phân tích vòng tiếp theo	Incident hoặc phản hồi có mô tả hành vi, thời điểm và tác động

Phạm vi sơ đồ: trình tự học liệu để định vị kỹ thuật. Không dùng sơ đồ này để suy ra gate, chủ sở hữu, thẩm quyền handoff hay tiêu chí release; các nội dung đó cần được xác định riêng trong artifact kiểm soát.

4. Input c?n thi?t

Core

Kiểm thử hộp đen cần test basis: tập bằng chứng mô tả hành vi mong đợi để BA suy ra điều kiện kiểm thử, kết quả mong đợi và dữ liệu kiểm thử. Người học không cần biết code, database hay công cụ test. Cần biết ba việc: hệ thống nhận gì, hệ thống phải phản hồi gì, và bằng chứng nào nói điều đó.

Nova Foods Trading & Manufacturing là case study mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Không xem tên quy trình, số tiền, ID hay nội dung trong case study là cấu hình ERP thật, quy định vận hành thật hoặc bằng chứng tuân thủ.

Canonical ID là định danh giữ nguyên qua các artifact. ID giúp truy ngược một test condition về đúng nguồn thay vì dựa vào tên gọi dễ đổi. Ví dụ, CANONICAL_BUSINESS_RULES luôn chỉ catalog quy tắc nghiệp vụ; không đổi thành “Business Rules File” trong test case.

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

flowchart TB
    A["Nguồn<br/>requirement, rule, dữ liệu"]
    B["Test basis<br/>bằng chứng hành vi mong đợi<br/>tham chiếu Canonical ID"]
    C["Điều kiện kiểm thử<br/>tham chiếu Canonical ID"]
    D["Test case<br/>input và expected result"]
    E["Kết quả chạy<br/>pass, fail hoặc blocked"]

    A --> B --> C --> D --> E
    C -. "truy ngược" .-> B

Sơ đồ mô tả luồng bằng chứng học liệu. Nó không cấp thẩm quyền phê duyệt, baseline hay release.

Applied

Facts: Nova Foods mô phỏng cần kiểm thử hành vi tạo đơn bán hàng khi tổng tiền đơn được tính từ số lượng và đơn giá. Không có code nguồn trong phạm vi BA.

Current Behavior: Chưa có bằng chứng được cung cấp rằng ERP mô phỏng đang tính, làm tròn hoặc lưu tổng tiền theo cách nào.

Underlying Need: BA cần gom đúng artifact nguồn để viết kiểm thử quan sát được, không tự đoán công thức hay tự tạo quy tắc.

Options: Dùng mô tả miệng; dùng file không định danh; hoặc dùng artifact được kiểm soát có ID và đường dẫn canonical.

Decision Criteria: Nguồn phải chỉ ra được hành vi, giữ được liên kết truy vết, và không biến giả định thành fact.

Decision: Dùng artifact được kiểm soát làm test basis; ghi rõ phần nào chưa có nội dung nghiệp vụ cụ thể.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết artifact. Business Owner, Accounting Owner, Legal Owner, Architect, Security và QA vẫn giữ thẩm quyền chuyên môn riêng. Không có approval được suy ra.

Artifact: Bảng inventory bên dưới.

Consequence if Wrong: Test case có thể kiểm tra hành vi BA tự tưởng tượng; kết quả pass vẫn không chứng minh ERP đáp ứng nhu cầu nghiệp vụ.

Nhóm đầu vào	Canonical ID hoặc tên giữ nguyên	Tệp canonical	Phân loại nguồn	Dùng để suy ra gì trong kiểm thử hộp đen	Trạng thái nội dung
Danh mục định danh	TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	ID nào được phép tham chiếu và cách giữ liên kết giữa nguồn, điều kiện test, test case	Có metadata quản trị; không phải baseline
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	Điều kiện nghiệp vụ, tổ hợp điều kiện, expected result	Kế hoạch catalog; không được suy ra rule Nova Foods chưa được ghi
Từ điển dữ liệu	CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Controlled planning artifact	Trường dữ liệu, kiểu giá trị, quan hệ dữ liệu và dữ liệu test tổng hợp	Kế hoạch dictionary; chưa là schema triển khai
Kiến trúc học phần	01_CURRICULUM_ARCHITECTURE	/01-curriculum/01_CURRICULUM_ARCHITECTURE.md	Controlled planning artifact	Ranh giới học liệu giữa requirement, acceptance criteria, traceability và testing	IN_REVIEW, v0.9.0
Danh mục chapter	CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Đường dẫn, phạm vi chapter và dependency được phép dùng	IN_REVIEW, v0.9.0
Thuật ngữ kiểm thử	ISTQB CTFL Syllabus v4.0.1	https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf	Verified primary source	Nghĩa thuật ngữ test basis, black-box testing, test condition, test case	Dùng thuật ngữ; không suy ra rule Nova Foods
Nguồn BA	BABOK Guide Version 3	https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/	Verified primary source	Ngữ cảnh phân tích nghiệp vụ, traceability và quản trị yêu cầu	Không bịa trang, mục hoặc điều khoản
Nguồn pháp lý Việt Nam	Luật 91/2025/QH15; Nghị định 356/2025/NĐ-CP; Luật 88/2015/QH13; Nghị định 123/2020/NĐ-CP; Luật 55/2010/QH12	URL chính thức trong verified primary-source seed	Verified official legal source	Bối cảnh cần chuyển sang xác minh chuyên môn khi test liên quan dữ liệu cá nhân, kế toán, hóa đơn hoặc an toàn thực phẩm	Verification required cho mọi diễn giải yêu cầu hệ thống cụ thể
Ví dụ đơn bán hàng Nova Foods	Không có canonical requirement ID được cung cấp	Chưa có tệp canonical được cung cấp	Synthetic learning scenario	Minh họa cách nhận diện đầu vào cần có	Unresolved verification item: cần requirement, rule hoặc acceptance criteria có ID trước khi viết expected result

Senior Lens

Phân biệt evidence (bằng chứng) với assumption (giả định). Evidence có nguồn xác định và cho phép người khác kiểm tra lại. Assumption chỉ là điều BA tạm tin để tiếp tục phân tích; nó không đủ làm expected result. Cầu nối suy luận là: nguồn nói rõ điều kiện và kết quả, nên BA tạo được test condition; nguồn chỉ nêu bối cảnh, nên BA chỉ được ghi câu hỏi hoặc phạm vi kiểm thử, không được tự đặt kết quả.

Một ID bền vững phải được chép nguyên dạng. CHAPTER_MANIFEST khác 01_CURRICULUM_ARCHITECTURE: artifact đầu quản lý danh mục chapter, artifact sau quản lý kiến trúc curriculum. Gộp hai nguồn thành một nhãn “tài liệu curriculum” làm mất đường truy vết và khiến reviewer không biết kết luận dựa vào đâu.

Quick Reference

Cần có trước khi BA thiết kế test	Ý nghĩa từ gốc	Không được thay thế bằng
Hành vi cần kiểm chứng	Mô tả hệ thống phải làm gì khi nhận input	Ý kiến cá nhân hoặc hành vi BA mong muốn
Điều kiện và kết quả mong đợi	Cơ sở so sánh actual result với expected result	Kết quả chạy của lần test trước
Dữ liệu test tổng hợp	Giá trị dùng để kích hoạt điều kiện kiểm thử trong case study	Dữ liệu cá nhân, dữ liệu khách hàng thật hoặc dữ liệu production
Nguồn và canonical ID	Điểm truy ngược về artifact gốc	Tên file nhớ mang máng, ảnh chụp màn hình không định danh
Nhãn chưa xác minh	Báo cho người đọc biết chỗ chưa đủ bằng chứng	Tự điền rule, công thức, ngưỡng hoặc nghĩa vụ pháp lý

Core

Đầu vào kiểm thử hộp đen phải đủ tin cậy trước khi BA thiết kế ca kiểm thử. Kiểm thử hộp đen là kiểm tra hành vi quan sát được từ input, output và quy tắc, không dựa vào mã nguồn. Nếu nguồn không rõ, cũ hoặc vượt thẩm quyền, kết quả kiểm thử chỉ là giả định.

Kiểm tra chất lượng	Cách kiểm tra	Đạt khi	Không đạt
Nhận diện	Có Artifact ID, đường dẫn canonical, version, status	Ví dụ CANONICAL_BUSINESS_RULES, /01-curriculum/CANONICAL_BUSINESS_RULES.md, v0.9.0, IN_REVIEW	Không dùng nguồn không có định danh
Nguồn gốc	Biết tổ chức phát hành và ranh giới dùng	Nguồn chính thức hoặc artifact corpus được kiểm soát	Gắn nhãn Verification required
Tính mới	So sánh ngày cập nhật với ngày kiểm thử 2026-08-07	Không có thay đổi đã biết sau ngày này	Dừng khi nguồn có bản mới chưa đánh giá
Tính nhất quán	Đối chiếu ID, thuật ngữ, rule giữa các artifact	Không mâu thuẫn với canonical source	Dừng và escalation khi mâu thuẫn
Thẩm quyền	Xác định người chịu trách nhiệm xác nhận	BA chỉ tổng hợp; đúng owner xác nhận nội dung chuyên môn	Không suy diễn xác nhận từ IN_REVIEW
Khả năng kiểm thử	Có điều kiện, dữ liệu, kết quả mong đợi quan sát được	Chuyển được thành input và expected result	Ghi Verification required, chưa tạo expected result bắt buộc

Phân loại nguồn quyết định mức độ tin cậy, không quyết định nội dung là đúng cho production. Nguồn primary là chuẩn, luật hoặc đặc tả do tổ chức có thẩm quyền phát hành. Nguồn controlled internal là artifact canonical trong corpus. Nguồn project assumption là giả định học liệu. 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

stateDiagram-v2
    direction TB

    [*] --> Collected

    state "Đã thu thập nguồn" as Collected
    state "Phân loại nguồn" as SourceClass
    state "Kiểm tra nhận diện,\nnguồn gốc, thẩm quyền" as IdentityAuthority
    state "Kiểm tra tính mới\nso với 2026-08-07" as Freshness
    state "Kiểm tra tính nhất quán" as Consistency
    state "Kiểm tra khả năng kiểm thử" as Testability
    state "Verification required\nChưa tạo expected result bắt buộc" as VerificationRequired
    state "Chờ đúng owner chuyên môn\nxác nhận" as AwaitOwnerDecision
    state "Dừng: bản mới chưa đánh giá" as StopNewVersion
    state "Escalation: mâu thuẫn\nvới canonical source" as Escalation
    state "Đủ điều kiện" as Qualified
    state "Sẵn sàng thiết kế test" as TestReady

    Collected --> SourceClass
    SourceClass --> IdentityAuthority: primary, controlled internal,\nhoặc project assumption
    SourceClass --> VerificationRequired: không chính thức, không kiểm soát\nhoặc chưa xác định phân loại
    note right of SourceClass
        Phân loại quyết định mức tin cậy,
        không xác nhận đúng cho production
    end note

    IdentityAuthority --> Freshness: Có ID, đường dẫn canonical,\nversion, status, nguồn gốc,\nranh giới dùng, đúng owner chuyên môn
    IdentityAuthority --> VerificationRequired: Thiếu bằng chứng,\nthẩm quyền hoặc status IN_REVIEW
    note right of IdentityAuthority
        BA chỉ tổng hợp.
        BA không xác nhận nội dung.
        IN_REVIEW không là xác nhận.
    end note

    Freshness --> Consistency: Không có bản mới đã biết
    Freshness --> StopNewVersion: Có bản mới chưa đánh giá
    StopNewVersion --> [*]

    Consistency --> Testability: Không mâu thuẫn canonical source
    Consistency --> Escalation: Mâu thuẫn canonical source

    Testability --> Qualified: Có điều kiện, dữ liệu,\nexpected result quan sát được
    Testability --> VerificationRequired: Chưa kiểm thử được

    VerificationRequired --> IdentityAuthority: Có thông tin mới
    VerificationRequired --> AwaitOwnerDecision: Cần đúng owner chuyên môn xác nhận

    AwaitOwnerDecision --> IdentityAuthority: Owner xác nhận đủ bằng chứng
    AwaitOwnerDecision --> VerificationRequired: Chưa xác nhận hoặc chưa giải quyết

    Escalation --> AwaitOwnerDecision: Chuyển đúng owner chuyên môn xác nhận

    Qualified --> TestReady
    TestReady --> [*]

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. Corpus có 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.

Current Behavior: BA nhận một quy tắc về giá trị hóa đơn từ CANONICAL_BUSINESS_RULES, nhưng chưa có xác nhận từ Accounting Owner hay Legal Owner.

Underlying Need: Cần biết quy tắc này có thể làm test basis, tức căn cứ tạo expected result, hay chỉ được ghi nhận để xác minh.

Thuộc tính	Giá trị mô phỏng
Source classification	controlled internal
Canonical ID	CANONICAL_BUSINESS_RULES
Canonical filename	/01-curriculum/CANONICAL_BUSINESS_RULES.md
Status/version	IN_REVIEW / v0.9.0
Freshness date	2026-08-07
Content owner cần xác minh	Accounting Owner; Legal Owner nếu có diễn giải pháp lý
Verification state	Verification required
Test-input disposition	Không dùng làm expected result bắt buộc

Options: Dùng ngay như quy tắc bắt buộc; dùng như giả định có nhãn; hoặc dừng thiết kế ca kiểm thử liên quan.

Decision Criteria: Chỉ dùng làm expected result bắt buộc khi nguồn có thẩm quyền nội dung, còn hiệu lực tại thời điểm kiểm thử, không mâu thuẫn nguồn canonical, và có điều kiện kiểm thử quan sát được.

Decision: Dừng nhánh kiểm thử giá trị hóa đơn. Giữ tham chiếu CANONICAL_BUSINESS_RULES với nhãn Verification required; không suy diễn nghĩa vụ kế toán hay pháp lý.

Authority: Accounting Owner xác nhận diễn giải kế toán. Legal Owner xác nhận diễn giải pháp lý. Principal IT Business Analyst / Technical Curriculum Author chỉ giữ traceability và trạng thái nguồn.

Artifact: Ghi quyết định trong test-input log của /02-handbook/19-black-box-testing-techniques-for-ba.md; giữ nguyên ID và đường dẫn nguồn.

Consequence if Wrong: Expected result sai có thể báo lỗi giả, bỏ sót lỗi thật, hoặc biến giả định học liệu thành yêu cầu vận hành không có thẩm quyền.

Senior Lens

Điều kiện dừng không phải thất bại BA. Đây là kiểm soát chống tạo kiểm thử có vẻ chính xác nhưng không có căn cứ. Dừng ngay khi gặp một trong các điều kiện sau:

Stop condition	Hành động bắt buộc
Không có canonical ID hoặc đường dẫn kiểm soát	Không đưa vào test basis
Status không chứng minh approval nhưng bị diễn đạt là đã phê duyệt	Sửa nhãn về IN_REVIEW; không suy diễn approval
Nguồn luật, thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm chưa được owner xác minh	Gắn Verification required; escalation đúng owner
Hai nguồn canonical mâu thuẫn	Không tự chọn nguồn “có vẻ mới hơn”; lập vấn đề truy vết
Nguồn chính thức có trạng thái cần rà soát bản mới	Dừng phần bị ảnh hưởng đến khi đánh giá freshness
Quy tắc không chuyển được thành hành vi quan sát được	Chưa thiết kế test case; yêu cầu làm rõ điều kiện và kết quả

Quick Reference

• IN_REVIEW nghĩa là đang xem xét có kiểm soát; không phải APPROVED, BASELINED hay production-ready.
• Nguồn có ID nhưng thiếu owner nội dung vẫn chưa đủ cho expected result bắt buộc.
• Freshness dùng ngày tham chiếu 2026-08-07 theo Asia/Ho_Chi_Minh.
• Nguồn pháp lý chỉ định bối cảnh cần xác minh; không tự tạo yêu cầu ERP hoặc kết luận tuân thủ.
• Nova Foods là mô phỏng giáo dục; mọi giá trị và tình huống ở đây là dữ liệu tổng hợp.

Core

Bảng dưới là bộ đầu vào cho thiết kế kiểm thử hộp đen của Nova Foods Trading & Manufacturing, case mô phỏng giáo dục. Kiểm thử hộp đen kiểm tra hệ thống qua dữ liệu vào, kết quả ra và quy tắc mong đợi; không cần biết mã nguồn. Mỗi dòng phải giữ ID và đường dẫn nguồn để người review truy ngược được lý do chọn ca kiểm thử.

Nhóm đầu vào	Giá trị Nova Foods tổng hợp	Artifact/ID canonical	Phân loại nguồn	Owner nguồn	Freshness tại 2026-08-07	Trạng thái dùng cho kiểm thử	Điểm chưa xác minh
Bối cảnh corpus	Việt Nam, vi-VN, Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND	/01-curriculum/CHAPTER_MANIFEST.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	Cập nhật 2026-08-07, v0.9.0	Dùng để định dạng ngày, giờ, tiền trong dữ liệu test	Không có
Trạng thái quản trị	IN_REVIEW; chưa baseline; chưa có approval	CHAPTER_MANIFEST	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	v0.9.0	Không gọi kết quả test là phê duyệt hay sẵn sàng production	Không có
Danh mục ID truy vết	Quy tắc đặt và kiểm soát ID xuyên artifact	TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author	2026-08-07	Chỉ dùng ID đã đăng ký; không tự tạo ID canonical mới	Cần kiểm tra ID nghiệp vụ cụ thể trước khi lập test case
Quy tắc nghiệp vụ	Catalog quy tắc nghiệp vụ Nova Foods đang được lập kế hoạch	CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author; Business Owner xác nhận nội dung	IN_REVIEW, v0.9.0	Không suy diễn điều kiện hợp lệ, ngưỡng hay công thức từ tên catalog	Verification required: chưa có quy tắc cụ thể được cung cấp cho batch này
Từ điển dữ liệu	Catalog dữ liệu logic Nova Foods đang được lập kế hoạch	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Controlled planning artifact	Principal IT Business Analyst / Technical Curriculum Author; Data Owner xác nhận nội dung	IN_REVIEW, v0.9.0	Không tự gán kiểu dữ liệu, độ dài, miền giá trị hay giá trị mặc định	Verification required: chưa có thuộc tính dữ liệu cụ thể được cung cấp
Nền tảng BA	Thuật ngữ BA, nhiệm vụ, năng lực	BABOK Guide, Version 3	External primary reference	IIBA	URL truy cập 2026-08-07	Dùng giải thích thuật ngữ BA; không thay yêu cầu Nova Foods	Toàn văn có thể cần quyền truy cập
Nền tảng kiểm thử	Thuật ngữ và kỹ thuật hộp đen	ISTQB CTFL Syllabus v4.0.1	External primary reference	ISTQB	URL truy cập 2026-08-07	Dùng thuật ngữ kỹ thuật kiểm thử	Không tạo yêu cầu ERP từ syllabus
Nguồn pháp lý dữ liệu cá nhân	Luật 91/2025/QH15; Nghị định 356/2025/NĐ-CP	URL official trong verified source seed	Official legal source	Quốc hội Việt Nam; Chính phủ Việt Nam	Trạng thái nguồn ghi nhận 2026-08-07	Chỉ đánh dấu nhu cầu review pháp lý khi test đụng dữ liệu cá nhân	Verification required: Legal Owner xác nhận yêu cầu hệ thống áp dụng
Nguồn kế toán và hóa đơn	Luật 88/2015/QH13; Nghị định 123/2020/NĐ-CP	URL official trong verified source seed	Official legal source	Quốc hội Việt Nam; Chính phủ Việt Nam	Trạng thái nguồn ghi nhận 2026-08-07	Không biến diễn giải học liệu thành quy tắc tính toán hay hóa đơn	Verification required: Accounting Owner và Legal Owner xác nhận áp dụng
Nguồn an toàn thực phẩm	Luật 55/2010/QH12	URL official trong verified source seed	Official legal source	Quốc hội Việt Nam	Trạng thái nguồn ghi nhận 2026-08-07	Chỉ làm bối cảnh truy xuất và thu hồi	Verification required: Domain Owner và Legal Owner xác nhận yêu cầu áp dụng
Dữ liệu test minh họa	Mã lô: LO-SYN-260807-01; Số lượng: 120; Đơn giá: 45000 VND; Ngày: 2026-08-07	Không có ID canonical được cấp	Synthetic test data	BA tạo dữ liệu mô phỏng	Tạo cho batch này	Chỉ minh họa dạng dữ liệu đầu vào; không chứng minh rule hợp lệ	Verification required: miền giá trị và kết quả mong đợi chưa có nguồn nghiệp vụ
API và tích hợp	Chưa có endpoint, OpenAPI document, mapping hay hợp đồng tích hợp Nova Foods	Không có artifact được cung cấp	Missing project evidence	Architect hoặc Integration Owner	Không áp dụng	Không thiết kế test API hoặc test tích hợp	Verification required: cần nguồn API canonical trước khi tạo ca test tích hợp

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

flowchart TB
    A[Artifact nguồn canonical] --> B[BA kiểm tra ID đăng ký, đường dẫn nguồn và trạng thái]
    B --> C{ID đăng ký, đường dẫn nguồn và trạng thái cho phép dùng?}
    C -->|Không hoặc thiếu| D[Đánh dấu Verification required]
    D --> E[STOP: chưa lập ca test cần bằng chứng chưa xác minh]
    C -->|Có| F{Có đủ quy tắc nghiệp vụ, thuộc tính và miền dữ liệu canonical, kết quả mong đợi?}
    F -->|Không hoặc thiếu| D
    F -->|Có| G[Thiết kế test hộp đen dự thảo]
    G --> H{Nguồn còn IN_REVIEW hoặc cần Business Owner, Data Owner, Legal Owner, Accounting Owner xác nhận?}
    H -->|Có| I[Giữ trạng thái dự thảo: không phê duyệt, không sẵn sàng production]
    H -->|Không| J[Ca test có đủ bằng chứng để review]

Applied

Facts: Nova Foods là case mô phỏng, mọi dữ liệu dùng trong bảng là tổng hợp. Current Behavior: catalog rule và data dictionary có trạng thái IN_REVIEW, chưa cung cấp rule cụ thể. Underlying Need: BA cần biết nguồn nào đủ để tạo kết quả mong đợi. Options: suy diễn rule từ dữ liệu ví dụ; hoặc dừng phần test phụ thuộc rule. Decision Criteria: nguồn có ID canonical, owner đúng thẩm quyền, nội dung đủ mới và xác minh được. Decision: chỉ dùng dữ liệu ví dụ để minh họa cấu trúc; dừng ca test khẳng định pass/fail nghiệp vụ. Authority: Business Owner, Data Owner, Legal Owner, Accounting Owner hoặc Architect tùy loại rule. Artifact: bảng đầu vào này trong /02-handbook/19-black-box-testing-techniques-for-ba.md. Consequence if Wrong: ca test có thể kiểm tra sai rule, tạo bằng chứng sai và che mất rủi ro production.

Senior Lens

IN_REVIEW là trạng thái tài liệu, không phải bằng chứng rule đúng. Giá trị 120, 45000 VND và LO-SYN-260807-01 chỉ là dữ liệu tổng hợp. Không dùng chúng làm boundary value, equivalence class hoặc expected result khi chưa có nguồn nghiệp vụ xác minh.

Quick Reference

Dùng đầu vào khi có: nguồn rõ, ID giữ nguyên, owner rõ, ngày kiểm tra rõ, nội dung đủ cho kết quả mong đợi. Dừng khi thiếu rule, thiếu định nghĩa dữ liệu, thiếu authority, hoặc nguồn pháp lý bị diễn đạt như nghĩa vụ hệ thống mà chưa có xác nhận chuyên môn.

5. Step-by-step BA Activities

Core

Kiểm thử hộp đen (black-box testing) kiểm tra hành vi quan sát được từ đầu vào, đầu ra và quy tắc đã xác minh; không suy đoán mã nguồn hay cấu hình ERP. Quy trình dưới đây tạo test basis, ca kiểm thử và bàn giao có kiểm soát cho Nova Foods Trading & Manufacturing, case mô phỏng dùng dữ liệu tổng hợp. Trạng thái tài liệu: IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07.

Applied

Facts: /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/CANONICAL_DATA_DICTIONARY.md là nguồn canonical dự kiến nhưng còn IN_REVIEW. Current Behavior: chưa có rule Nova Foods đã baseline hay approved. Underlying Need: BA cần tạo bộ kiểm thử không biến ví dụ thành quy tắc vận hành. Options: viết expected result theo suy đoán; hoặc chỉ lập test basis, đánh dấu Verification required và chặn ca cần rule chưa xác minh. Decision Criteria: nguồn có ID canonical, rule hoặc định nghĩa dữ liệu đủ rõ, owner đúng thẩm quyền, trạng thái và ngày kiểm tra được ghi nhận. Decision: dùng quy trình này; không kết luận pass/fail nghiệp vụ khi thiếu nguồn đủ điều kiện. Authority: Business Owner quyết định quy tắc nghiệp vụ; Data Owner xác nhận nghĩa dữ liệu; QA Owner xác nhận phạm vi kiểm thử; Legal, Accounting, Security hoặc Architect xử lý nội dung thuộc chuyên môn tương ứng. Artifact: /02-handbook/19-black-box-testing-techniques-for-ba.md. Consequence if Wrong: expected result sai có thể tạo bằng chứng kiểm thử sai, bỏ sót lỗi hoặc dẫn nhóm triển khai theo giả định.

1. BA chuẩn bị phạm vi kiểm thử. BA xác định chức năng, actor, kênh nhập liệu, đầu ra và ranh giới không kiểm thử; đối tượng là requirement, acceptance criteria và luồng nghiệp vụ hiện có. Bằng chứng: danh sách phạm vi và nguồn tham chiếu trong working notes của artifact. Quy tắc quyết định: chỉ đưa vào phạm vi khi liên kết được tới nguồn xác định; không dùng mô tả miệng làm rule. Cổng chất lượng: mỗi mục có nguồn, ngày kiểm tra 2026-08-07 và nhãn IN_REVIEW nếu nguồn chưa baseline. Escalation: thiếu phạm vi hoặc owner, chuyển Business Owner và QA Owner để làm rõ.

2. BA kiểm tra test basis. BA đối chiếu requirement với CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; đối tượng là rule, trường dữ liệu, trạng thái và ID liên quan. Bằng chứng: ma trận truy vết nguồn-to-test-basis. Quy tắc quyết định: rule chỉ đủ dùng khi nêu điều kiện, hành vi mong đợi và authority; dữ liệu chỉ đủ dùng khi có nghĩa, kiểu hoặc miền giá trị cần thiết. Cổng chất lượng: không có dòng nào tự gán rule từ số liệu tổng hợp. Escalation: rule nghiệp vụ mơ hồ chuyển Business Owner; định nghĩa dữ liệu mơ hồ chuyển Data Owner; nội dung pháp lý, kế toán, bảo mật hoặc kiến trúc chuyển owner chuyên môn.

3. BA phân vùng đầu vào. BA chia dữ liệu thành lớp tương đương (equivalence partitioning), tức nhóm giá trị được kỳ vọng xử lý cùng cách; đối tượng là từng trường hoặc tổ hợp trường có rule đủ điều kiện. Bằng chứng: bảng lớp hợp lệ, không hợp lệ và lý do phân chia. Quy tắc quyết định: mỗi lớp phải có cùng kết quả mong đợi theo một nguồn; nếu không chứng minh được, không tạo lớp. Cổng chất lượng: lớp không chồng lấp theo rule đang xét và có liên kết nguồn. Escalation: điều kiện giao nhau hoặc ưu tiên rule chưa rõ chuyển Business Owner và QA Owner.

4. BA chọn giá trị biên. BA áp dụng kiểm thử giá trị biên (boundary value analysis), tức kiểm tra ngay tại giới hạn và giá trị sát giới hạn; đối tượng là giới hạn số lượng, ngày, độ dài hoặc trạng thái có nguồn xác minh. Bằng chứng: danh sách giá trị tại biên, dưới biên và trên biên cùng căn cứ. Quy tắc quyết định: chỉ tạo giá trị biên khi giới hạn được nêu rõ trong rule hoặc data definition. Cổng chất lượng: mỗi giá trị có đơn vị, locale vi-VN khi phù hợp và expected result không suy diễn. Escalation: giới hạn tiền tệ VND, thuế, kế toán hoặc thời hạn pháp lý chưa xác minh chuyển Accounting Owner hoặc Legal Owner.

5. BA xây ca kiểm thử. BA ghi precondition, dữ liệu tổng hợp, bước thực hiện, expected result và liên kết test basis; đối tượng là từng hành vi có thể quan sát. Bằng chứng: ca kiểm thử nháp trong artifact làm việc, không tự tạo ID canonical. Quy tắc quyết định: một ca kiểm thử kiểm tra một mục tiêu chính; expected result phải có nguồn hoặc ghi Verification required. Cổng chất lượng: người thực hiện khác vẫn chạy được từ dữ liệu và bước đã ghi; không chứa dữ liệu cá nhân thật. Escalation: ca cần API, phân quyền, tích hợp hoặc xử lý lỗi hệ thống chuyển Architect, Security Owner hoặc QA Owner theo phạm vi.

6. BA tự rà soát tính đầy đủ. BA kiểm tra liên kết từ phạm vi đến test basis, lớp dữ liệu, ca kiểm thử và expected result; đối tượng là bộ ca kiểm thử nháp. Bằng chứng: checklist rà soát và danh sách khoảng trống. Quy tắc quyết định: thiếu nguồn, thiếu expected result hoặc thiếu route xử lý lỗi thì ca chưa sẵn sàng review. Cổng chất lượng: không tuyên bố tuân thủ, approval, baseline hoặc production readiness từ trạng thái IN_REVIEW. Escalation: khoảng trống ảnh hưởng phạm vi phát hành chuyển QA Owner và Business Owner; nguy cơ dữ liệu chuyển Security Owner.

7. BA tổ chức review liên vai trò. BA gửi bộ test basis và ca kiểm thử cho đúng owner; đối tượng là nội dung cần xác nhận, không phải toàn bộ corpus. Bằng chứng: nhận xét, câu hỏi mở, quyết định và owner được ghi nhận trong artifact kiểm soát. Quy tắc quyết định: chỉ owner đúng thẩm quyền mới xác nhận nội dung thuộc phạm vi mình; BA không thay thế kết luận đó. Cổng chất lượng: từng nhận xét được phân loại chấp nhận, từ chối có lý do, hoặc Verification required. Escalation: mâu thuẫn giữa các owner giữ nguyên traceability rồi chuyển cấp điều phối được chỉ định; không tự chọn rule.

8. BA bàn giao có kiểm soát. BA bàn giao phiên bản review cho QA hoặc nhóm nhận đầu ra, kèm phạm vi, nguồn, giả định, khoảng trống và điều kiện chặn thực thi; đối tượng là gói kiểm thử hộp đen. Bằng chứng: danh mục bàn giao trỏ tới /02-handbook/19-black-box-testing-techniques-for-ba.md, trạng thái IN_REVIEW, phiên bản v0.9.0. Quy tắc quyết định: chỉ bàn giao để review hoặc chuẩn bị khi mọi ca được gắn trạng thái đủ thông tin hoặc bị chặn rõ ràng. Cổng chất lượng: gói bàn giao nêu dữ liệu tổng hợp, không có claim user approval và không đổi ID, filename hay phân loại nguồn. Escalation: người nhận yêu cầu dùng ca bị chặn cho quyết định production, dừng và chuyển QA Owner cùng Business Owner.

Senior Lens

BA không “hoàn thành kiểm thử” khi viết ca test. BA hoàn thành phần việc khi nguồn, giả định, người có thẩm quyền và giới hạn sử dụng đều truy được. Ca có nhãn Verification required vẫn hữu ích: nó làm lộ thiếu rule trước khi QA chạy test và trước khi lỗi bị ngụy trang thành kết quả pass/fail.

Quick Reference

Chuỗi tối thiểu: phạm vi rõ, test basis có nguồn, dữ liệu được phân vùng, giá trị biên có căn cứ, expected result truy được, review đúng owner, bàn giao nêu rõ điều kiện chặn. Dừng ngay khi rule, dữ liệu, authority hoặc nghĩa của kết quả mong đợi chưa xác minh.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. BA dùng kỹ thuật kiểm thử hộp đen (black-box testing): thiết kế kiểm thử từ hành vi mong đợi, không suy đoán mã nguồn hay cấu hình ERP.

Bước	Actor	Action trên object	Evidence tạo ra	Decision rule	Quality gate	Escalation route
1. Chuẩn bị test basis	BA	Thu thập requirement, business rule, acceptance criteria, quy trình và định nghĩa dữ liệu liên quan chức năng cần kiểm thử. Object là nguồn kiểm thử (test basis).	Danh sách nguồn, ID nguồn, phiên bản, trạng thái và khoảng trống truy vết.	Chỉ dùng nguồn canonical có ID và trạng thái rõ. Nội dung IN_REVIEW phải gắn nhãn chưa baseline.	Mỗi hành vi cần kiểm thử truy đến ít nhất một nguồn; không có nguồn thì không viết expected result như fact.	Thiếu hoặc mâu thuẫn nguồn: BA lập issue, chuyển Business Owner làm rõ ý nghĩa nghiệp vụ; chuyển Architect khi liên quan tích hợp; chuyển Legal, Accounting, Security khi thuộc thẩm quyền đó.
2. Xác định điều kiện kiểm thử	BA	Tách từng rule thành input, điều kiện trước, xử lý mong đợi và output quan sát được. Object là rule-to-behavior map.	Bảng điều kiện kiểm thử có liên kết source ID.	Một điều kiện chỉ có một kết quả mong đợi có thể quan sát. Nếu một input dẫn nhiều kết quả, phải nêu điều kiện phân nhánh.	Không còn từ mơ hồ như “hợp lệ”, “đầy đủ”, “lớn” mà thiếu tiêu chí đo.	Rule không xác định ngưỡng, quyền, trạng thái hoặc thời điểm hiệu lực: chuyển Business Owner; định dạng/trường dữ liệu chưa rõ: chuyển Data Owner hoặc Architect.
3. Chọn kỹ thuật hộp đen	BA	Chọn phân vùng tương đương (equivalence partitioning), giá trị biên (boundary value analysis), bảng quyết định (decision table), chuyển trạng thái (state transition) hoặc use case testing theo dạng hành vi. Object là từng điều kiện kiểm thử.	Ma trận kỹ thuật–điều kiện–lý do chọn.	Dải giá trị dùng phân vùng và biên; tổ hợp điều kiện dùng bảng quyết định; vòng đời trạng thái dùng chuyển trạng thái.	Kỹ thuật phải bao phủ dạng logic thực tế, không chọn theo thói quen. Lý do chọn phải chỉ ra evidence từ rule hoặc workflow.	Không xác định được mô hình hành vi vì luồng nghiệp vụ thiếu: chuyển Process Owner và Business Owner; trạng thái hệ thống không rõ: chuyển Architect.
4. Thiết kế test condition và test data	BA	Lập điều kiện kiểm thử, dữ liệu đầu vào, tiền điều kiện và expected result. Object là test condition và synthetic test data.	Test condition ID, bộ dữ liệu tổng hợp, expected result, source traceability.	Mỗi phân vùng có ít nhất một đại diện; mỗi biên gồm giá trị dưới biên, tại biên, trên biên khi kiểu dữ liệu cho phép.	Dữ liệu không chứa dữ liệu cá nhân, khách hàng, nhà cung cấp hay giao dịch thật. Mã và số tiền VND chỉ là tổng hợp.	Cần dữ liệu nhạy cảm hoặc quyền truy cập ngoài phạm vi học liệu: dừng dùng dữ liệu đó, chuyển Security Owner và Data Owner.
5. Viết test case	BA	Chuyển test condition thành bước thực thi: precondition, input, action, expected result, postcondition. Object là test case.	Test case có ID, liên kết test basis, dữ liệu, kết quả mong đợi và priority.	Expected result mô tả hành vi thấy được ở UI, API, báo cáo hoặc trạng thái dữ liệu; không mô tả cách code xử lý.	Người khác có thể chạy test case mà không hỏi tác giả về dữ liệu, bước hoặc tiêu chí pass/fail.	Expected result phụ thuộc diễn giải nghiệp vụ chưa chốt: giữ trạng thái blocked, chuyển Business Owner; phụ thuộc contract API: chuyển Architect hoặc API Owner.
6. Rà soát bao phủ và tính kiểm thử	BA cùng QA Reviewer	Đối chiếu test case với rule, acceptance criteria, phân vùng, biên, tổ hợp và trạng thái. Object là traceability matrix.	Ma trận truy vết source ID–condition–test case; danh sách defect thiết kế test.	Một rule quan trọng không có test case là khoảng trống; một test case không có nguồn là giả định phải gắn nhãn hoặc loại bỏ.	Không có orphan test case; không có rule rủi ro cao thiếu negative test.	Tranh chấp mức rủi ro: chuyển Business Owner; thiếu kiểm soát bảo mật: chuyển Security Owner; ảnh hưởng tích hợp: chuyển Architect.
7. Handoff có kiểm soát	BA	Bàn giao test package cho QA hoặc vai trò thực thi được chỉ định, giữ nguyên ID, version và source classification. Object là gói test.	Handoff record gồm phạm vi, file, ID, known gaps, assumption, blocked item và người nhận.	Handoff chỉ xác nhận chuyển giao artifact, không xác nhận approval, baseline, compliance hay production readiness.	Người nhận truy cập được test basis, test case, dữ liệu tổng hợp và quy tắc pass/fail.	Người nhận không tái lập được môi trường hoặc thiếu quyền: chuyển Test Lead; thay đổi requirement sau handoff: mở change record, chuyển Business Owner và BA đánh giá tác động.

Cầu nối suy luận: rule nói “giá trị chỉ được chấp nhận trong khoảng xác định” là evidence về miền input; vì lỗi thường tập trung tại ranh giới miền, BA phải tạo case dưới biên, tại biên và trên biên. Rule nói “chỉ được chuyển trạng thái khi đủ điều kiện” là evidence về vòng đời; vì vậy BA phải kiểm thử cả chuyển trạng thái hợp lệ và chuyển trạng thái bị chặn.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi giá trị dưới đây là dữ liệu tổng hợp. BA dùng kiểm thử hộp đen (black-box testing): đánh giá đầu ra theo đầu vào và quy tắc quan sát được, không dựa vào mã nguồn hay cấu trúc nội bộ ERP.

Mục	Nội dung thực thi
Facts	Đơn bán hàng mô phỏng có tổng tiền hàng 12.000.000 VND; người dùng nhập mã giảm giá NF10.
Current Behavior	Màn hình xác nhận đơn hiển thị giảm giá 1.200.000 VND, tổng thanh toán 10.800.000 VND.
Underlying Need	Cần xác minh ERP áp dụng đúng kết quả nghiệp vụ khi mã giảm giá hợp lệ, không suy diễn cách tính từ mã nguồn.
Options	Kiểm tra một giá trị hợp lệ; kiểm tra giá trị biên; kiểm tra mã không hợp lệ; kiểm tra mã hợp lệ nhưng đơn không đủ điều kiện.
Decision Criteria	Mỗi ca phải có đầu vào xác định, kết quả mong đợi đo được, nguồn quy tắc truy vết được, và không chứa giả định pháp lý hoặc kế toán chưa xác minh.
Decision	BA lập bộ ca kiểm thử theo phân vùng tương đương và phân tích giá trị biên; ưu tiên tình huống làm sai số tiền phải trả.
Authority	Business Owner xác nhận ý nghĩa khuyến mại; QA reviewer xác nhận tính kiểm thử; Accounting Owner hoặc Legal Owner phải xem xét nếu quy tắc ảnh hưởng hạch toán, hóa đơn hoặc nghĩa vụ pháp lý.
Artifact	Bảng thực thi kiểm thử bên dưới, gắn với /01-curriculum/CANONICAL_BUSINESS_RULES.md và /01-curriculum/TRACEABILITY_ID_REGISTRY.md khi các nguồn này có nội dung được kiểm soát phù hợp.
Consequence if Wrong	Khách hàng có thể bị tính sai tiền; doanh nghiệp mô phỏng có thể ghi nhận sai doanh thu hoặc áp dụng ưu đãi sai. Đây là rủi ro nghiệp vụ; không phải kết luận tuân thủ hay quyết định vận hành thực tế.

Bước thực thi	Actor	Thao tác trên đối tượng	Dữ liệu tổng hợp và kết quả mong đợi	Bằng chứng ghi nhận	Quy tắc quyết định
1. Chọn phân vùng hợp lệ	BA	Xác định lớp đầu vào cho mã giảm giá	NF10; đơn 12.000.000 VND; kỳ vọng giảm 1.200.000 VND	Ca kiểm thử, ảnh chụp kết quả, thời điểm theo Asia/Ho_Chi_Minh	Pass khi giảm giá và tổng thanh toán khớp giá trị mong đợi
2. Chọn phân vùng không hợp lệ	BA	Nhập mã không tồn tại	NF99; kỳ vọng không giảm giá và có thông báo lỗi nghiệp vụ rõ ràng	Giá trị hiển thị, thông báo, trạng thái đơn	Pass khi tổng thanh toán giữ 12.000.000 VND và không áp dụng giảm giá
3. Kiểm tra giá trị biên	BA	Nhập đơn tại ngưỡng đủ điều kiện theo quy tắc được cung cấp	Nếu ngưỡng được nêu là 10.000.000 VND, kiểm tra 9.999.999 VND, 10.000.000 VND, 10.000.001 VND	Bảng đầu vào, đầu ra, quy tắc nguồn	Chỉ kết luận khi ngưỡng có nguồn nghiệp vụ; nếu chưa có, ghi Verification required và escalation tới Business Owner
4. Kiểm tra tương tác dữ liệu	BA	Áp mã NF10 lên đơn có sản phẩm bị loại trừ, nếu quy tắc nêu loại trừ	Kỳ vọng theo quy tắc nguồn, không tự đặt tỷ lệ hay danh sách sản phẩm	Ca kiểm thử và tham chiếu quy tắc	Escalation tới Business Owner khi điều kiện loại trừ chưa được xác định
5. Soát xét bàn giao	BA và QA reviewer	Đối chiếu kết quả mong đợi, kết quả thực tế, bằng chứng	Mỗi ca có trạng thái Pass, Fail hoặc Blocked	Test log và danh sách sai lệch	Fail khi đầu ra khác kỳ vọng; Blocked khi thiếu môi trường, dữ liệu hoặc quy tắc nguồn; chuyển đúng vai trò có thẩm quyền

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

flowchart TB
    A[BA tạo ca cơ sở<br/>NF10: giảm 1.200.000 VND<br/>tổng 10.800.000 VND<br/>NF99: không giảm<br/>tổng 12.000.000 VND và có lỗi rõ ràng] --> B{Có quy tắc ngưỡng<br/>được Business Owner xác minh?}

    B -->|Có| C[BA tạo ba ca biên<br/>Nếu ngưỡng là 10.000.000 VND:<br/>9.999.999, 10.000.000, 10.000.001 VND<br/>Nếu ngưỡng khác: dùng giá trị từ quy tắc nguồn]
    B -->|Chưa có| D[Ghi ca biên là Blocked<br/>Verification required<br/>bàn giao Business Owner]
    C --> E[Thêm ca biên có kỳ vọng xác định<br/>vào bộ ca sẵn sàng]
    D --> DL[Lưu trạng thái Blocked<br/>vào test log]

    E --> F{Có quy tắc sản phẩm bị loại trừ<br/>được Business Owner xác minh?}
    DL --> F
    F -->|Có| G[BA tạo ca sản phẩm bị loại trừ<br/>với kỳ vọng theo quy tắc nguồn]
    F -->|Chưa có| H[Ghi ca loại trừ là Blocked<br/>Verification required<br/>bàn giao Business Owner]
    G --> P[Thêm ca loại trừ<br/>vào bộ ca sẵn sàng]
    H --> HL[Lưu trạng thái Blocked<br/>vào test log]
    HL --> P

    P --> J[Với từng ca sẵn sàng<br/>kiểm tra môi trường và dữ liệu]
    J --> K{Đủ môi trường và dữ liệu?}
    K -->|Không| L[Ghi riêng ca là Blocked<br/>bàn giao test log cho QA reviewer]
    K -->|Có| M{Có quy tắc nguồn<br/>truy vết được?}

    M -->|Không| N[Ghi riêng ca là Blocked<br/>Verification required<br/>bàn giao Business Owner]
    M -->|Có| Q[Business Owner xác nhận<br/>ý nghĩa khuyến mại]
    Q --> R{Quy tắc khuyến mại<br/>đã được xác minh?}
    R -->|Chưa| S[Ghi riêng ca là Blocked<br/>bàn giao quy tắc và test log<br/>cho Business Owner]
    R -->|Có| U1{Ảnh hưởng hạch toán?}

    U1 -->|Có| W1[Accounting Owner<br/>xem xét tác động hạch toán]
    U1 -->|Không| U2{Ảnh hưởng hóa đơn?}
    W1 --> X1{Quy tắc hạch toán<br/>đã được xác minh?}
    X1 -->|Chưa| Y1[Ghi riêng ca là Blocked<br/>bàn giao Accounting Owner]
    X1 -->|Có| U2

    U2 -->|Có| W2[Accounting Owner hoặc Legal Owner<br/>xem xét hóa đơn theo phạm vi]
    U2 -->|Không| U3{Ảnh hưởng nghĩa vụ pháp lý?}
    W2 --> X2{Quy tắc hóa đơn<br/>đã được xác minh?}
    X2 -->|Chưa| Y2[Ghi riêng ca là Blocked<br/>bàn giao vai trò xem xét hóa đơn]
    X2 -->|Có| U3

    U3 -->|Có| W3[Legal Owner xem xét<br/>tác động nghĩa vụ pháp lý]
    U3 -->|Không| QA[QA reviewer xác nhận tính kiểm thử<br/>đầu vào xác định và kỳ vọng đo được]
    W3 --> X3{Quy tắc pháp lý<br/>đã được xác minh?}
    X3 -->|Chưa| Y3[Ghi riêng ca là Blocked<br/>bàn giao Legal Owner]
    X3 -->|Có| QA

    QA --> QT{Ca kiểm thử đủ rõ<br/>để thực thi?}
    QT -->|Không| QB[Ghi riêng ca là Blocked<br/>bàn giao danh sách thiếu cho BA<br/>và vai trò có thẩm quyền]
    QT -->|Có| V[BA thực thi ca<br/>trên giao diện ERP mô phỏng]

    V --> EV[Ghi kết quả thực tế, ảnh chụp<br/>trạng thái đơn, thời điểm Asia/Ho_Chi_Minh<br/>và tham chiếu quy tắc nguồn]
    EV --> AA[So sánh kết quả thực tế<br/>với kết quả mong đợi]
    AA --> AB{Kết quả khớp?}

    AB -->|Có| AC[Ghi riêng ca là Pass<br/>lưu test log và bằng chứng]
    AB -->|Không| AE[Ghi riêng ca là Fail<br/>lưu sai lệch và bằng chứng]
    AE --> RISK[Ghi rủi ro nghiệp vụ<br/>tính sai tiền, ghi nhận sai doanh thu<br/>hoặc áp dụng sai ưu đãi<br/>không kết luận tuân thủ]
    RISK --> AF[QA reviewer soát xét sai lệch]
    AF --> AG[Bàn giao theo phạm vi<br/>khuyến mại: Business Owner<br/>hạch toán: Accounting Owner<br/>hóa đơn: Accounting Owner hoặc Legal Owner<br/>nghĩa vụ pháp lý: Legal Owner]

    L --> NEXT{Còn ca chưa xử lý?}
    N --> NEXT
    S --> NEXT
    Y1 --> NEXT
    Y2 --> NEXT
    Y3 --> NEXT
    QB --> NEXT
    AC --> NEXT
    AG --> NEXT

    NEXT -->|Có| J
    NEXT -->|Không| Z[Hoàn tất test log<br/>tổng hợp Pass, Fail, Blocked<br/>bằng chứng, sai lệch và bàn giao]

6. Output thu ???c

Core

Black-box testing tạo artifact để biến quy tắc nghiệp vụ, dữ liệu đầu vào và kết quả mong đợi thành đối tượng có thể kiểm tra. BA không tự xác nhận hệ thống đúng; BA ghi rõ điều cần kiểm tra, căn cứ và trạng thái để QA reviewer hoặc vai trò có thẩm quyền tiếp tục review. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp.

Artifact tạo hoặc cập nhật	Canonical ID / nguồn định danh	Owner duy trì	Status	Nội dung tối thiểu	Nghĩa vụ lịch sử thay đổi
Test condition register	ID từng điều kiện phải được cấp từ TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Điều kiện kiểm tra, kỹ thuật black-box áp dụng, nguồn quy tắc, phạm vi dữ liệu, kết quả mong đợi cấp điều kiện	Ghi ngày 2026-08-07, v0.9.0, người sửa, lý do sửa, ID bị ảnh hưởng
Test case specification	ID từng test case phải được cấp từ TRACEABILITY_ID_REGISTRY	BA; QA reviewer review độc lập	IN_REVIEW	Tiền điều kiện, bước thực hiện, dữ liệu tổng hợp, kết quả mong đợi, tham chiếu test condition và quy tắc nguồn	Không sửa đè kết quả mong đợi cũ; tạo dòng lịch sử nêu thay đổi dữ liệu, bước, rule hoặc expected result
Test data set	ID bộ dữ liệu phải được cấp từ TRACEABILITY_ID_REGISTRY	BA	IN_REVIEW	Giá trị hợp lệ, không hợp lệ, biên, phân vùng tương đương, đơn vị VND khi có tiền tệ, nhãn synthetic data	Ghi nguồn giả định, thay đổi giá trị, lý do và test case chịu ảnh hưởng
Traceability matrix	TRACEABILITY_ID_REGISTRY	Principal IT Business Analyst / Technical Curriculum Author	IN_REVIEW	Liên kết quy tắc nguồn, test condition, test case, dữ liệu và issue nếu phát hiện sai lệch	Ghi mọi liên kết thêm, xóa, đổi; không thay ID canonical bằng tên diễn giải
Test execution log	ID lần chạy phải được cấp từ TRACEABILITY_ID_REGISTRY	QA reviewer; BA cập nhật phần phân tích nghiệp vụ khi được phân công	IN_REVIEW	Test case ID, môi trường mô phỏng, thời điểm Asia/Ho_Chi_Minh, actual result, Pass, Fail hoặc Blocked, bằng chứng	Không đổi trạng thái lịch sử im lặng; bổ sung lần chạy mới hoặc ghi correction có lý do
Issue register	ID issue phải được cấp từ TRACEABILITY_ID_REGISTRY	QA reviewer	IN_REVIEW	Mô tả sai lệch, test case liên quan, expected result, actual result, mức ảnh hưởng, evidence reference, owner xử lý đề xuất	Ghi chuyển trạng thái, người đổi, thời điểm, lý do; không gọi là defect đã xác nhận khi chưa được QA xác nhận

TRACEABILITY_ID_REGISTRY là nguồn kiểm soát định danh. Khi registry chưa cấp ID cho bản ghi mới, artifact ghi Verification required — chưa cấp canonical ID; không tự tạo biến thể ID cục bộ rồi gọi là canonical.

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

flowchart TB
    A[Quy tắc nguồn hoặc giả định có nhãn]
    R[TRACEABILITY_ID_REGISTRY<br/>Nguồn kiểm soát canonical ID]

    subgraph ID_CONTROL["Kiểm soát ID cho mỗi bản ghi"]
        direction TB
        M[Mỗi bản ghi artifact]
        Q{Registry đã cấp canonical ID<br/>cho bản ghi này?}
        CID[Dùng canonical ID từ registry]
        V[Giá trị ID khi registry chưa cấp:<br/>Verification required — chưa cấp canonical ID]

        M --> Q
        R --> Q
        Q -->|Có| CID
        Q -->|Chưa| V
    end

    I[Mọi artifact<br/>Status: IN_REVIEW]

    subgraph PREP["Chuẩn bị và duy trì artifact"]
        direction TB
        P[Principal IT Business Analyst / Technical Curriculum Author]
        BA[BA]

        B[Test condition register<br/>2026-08-07 · v0.9.0<br/>người sửa · lý do · ID bị ảnh hưởng]
        C[Test case specification<br/>Không sửa đè expected result<br/>tạo dòng lịch sử thay đổi]
        D[Test data set<br/>nguồn giả định · nhãn synthetic data<br/>ghi thay đổi, lý do và test case bị ảnh hưởng]
        G[Traceability matrix<br/>dùng canonical ID<br/>ghi liên kết thêm, xóa hoặc đổi]

        P -->|Duy trì| B
        P -->|Duy trì| G
        BA -->|Chuẩn bị| C
        BA -->|Chuẩn bị| D

        A --> B
        B --> C
        C --> D

        A --> G
        B --> G
        C --> G
        D --> G
        R -->|Nguồn định danh| G
    end

    subgraph QA_BOUNDARY["QA reviewer — review độc lập và sở hữu artifact thực thi"]
        direction TB
        QA[QA reviewer]
        E[Test execution log<br/>lần chạy mới hoặc correction có lý do<br/>không đổi trạng thái lịch sử im lặng]
        O{Kết quả lần chạy}
        PASS[Pass]
        FAIL[Fail]
        BLOCKED[Blocked]
        F[Issue register<br/>chưa gọi defect đã xác nhận trước QA xác nhận<br/>ghi chuyển trạng thái, người đổi, thời điểm, lý do]

        QA -->|Review độc lập| C
        QA -->|Sở hữu| E
        QA -->|Sở hữu| F
        BA -->|Cập nhật phần phân tích nghiệp vụ<br/>khi được phân công| E

        C -->|Test case được thực hiện| E
        D -->|Dữ liệu được sử dụng| E
        E --> O
        O -->|Pass| PASS
        O -->|Fail| FAIL
        O -->|Blocked| BLOCKED
        FAIL -->|Ghi nhận sai lệch| F
    end

    E --> G
    F --> G

    B -.-> M
    C -.-> M
    D -.-> M
    E -.-> M
    F -.-> M
    G -.-> M

    I -.-> B
    I -.-> C
    I -.-> D
    I -.-> E
    I -.-> F
    I -.-> G

Applied

Facts: Nova Foods là mô phỏng, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND. Chưa có approval reference hoặc baseline reference.

Current Behavior: BA áp dụng phân vùng tương đương và giá trị biên cho quy tắc giảm giá đơn hàng. Quy tắc nguồn chưa được xác nhận là quy định vận hành thực tế.

Underlying Need: Người review cần phân biệt rõ giữa test case, dữ liệu test, lần chạy test và issue. Nếu gộp chúng, thay đổi một giá trị biên có thể làm mất dấu test case và kết quả đã ghi.

Options:
1. Ghi tất cả trong một bảng.
2. Tách sáu artifact theo bảng Core.
3. Chỉ giữ test case, bỏ traceability và execution log.

Decision Criteria: Giữ được liên kết nguồn đến kết quả; không biến giả định thành fact; truy được thay đổi; không suy diễn approval.

Decision: Chọn phương án 2. Bằng chứng: mỗi đầu ra có owner, nội dung và lịch sử thay đổi khác nhau; một bảng không giữ rõ trách nhiệm và trạng thái của từng đối tượng.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì metadata và traceability. Business Owner xác minh rule nghiệp vụ khi cần. QA reviewer xác minh kết quả thực thi và issue. Không vai trò nào được suy diễn từ IN_REVIEW là đã phê duyệt.

Artifact: Cập nhật TRACEABILITY_ID_REGISTRY; tạo hoặc cập nhật test condition register, test case specification, test data set, traceability matrix, test execution log và issue register tại IN_REVIEW.

Consequence if Wrong: Test case có thể dùng dữ liệu không truy được nguồn; Fail có thể bị hiểu sai thành rule sai; thay đổi có thể xóa mất bằng chứng review.

Senior Lens

Một artifact chỉ có ích khi trả lời được bốn câu: kiểm tra cái gì, dựa vào đâu, dùng dữ liệu nào, ai đã ghi thay đổi nào. “Expected result” không phải ý kiến của BA. Nó phải liên kết tới quy tắc nghiệp vụ, requirement, acceptance criterion hoặc giả định có nhãn Verification required.

Không đưa dữ liệu cá nhân, khách hàng thật, hóa đơn thật hoặc cấu hình ERP thật vào test data set. Dữ liệu Nova Foods chỉ là synthetic data. Mọi chi tiết thuế, kế toán, quyền riêng tư, an toàn thực phẩm hoặc truy xuất nguồn gốc chưa đối chiếu nguồn chính thức hiện hành phải ghi Verification required và chuyển đúng owner chuyên môn.

Quick Reference

Quy tắc	Áp dụng
Một bản ghi, một ID canonical	Cấp từ TRACEABILITY_ID_REGISTRY; không tự đổi định dạng
Một thay đổi, một dòng lịch sử	Ghi ngày, version, người sửa, lý do, artifact bị ảnh hưởng
IN_REVIEW không phải approval	Không gọi artifact là approved, baselined, compliant hoặc production-ready
Expected result cần căn cứ	Liên kết rule, requirement, acceptance criterion hoặc giả định có nhãn
Synthetic data only	Không dùng dữ liệu Nova Foods thật hoặc dữ liệu cá nhân thật

Core

Đầu ra của kiểm thử hộp đen (black-box testing) phải cho người đọc thấy liên kết đủ từ hành vi mong đợi đến dữ liệu kiểm thử và kết quả quan sát. Kiểm thử hộp đen đánh giá hệ thống qua input, xử lý quan sát được và output; không dựa vào mã nguồn. Vì vậy, mỗi test case cần ghi rõ điều kiện, dữ liệu, bước chạy, kết quả mong đợi và bằng chứng kết quả thực tế.

Thành phần anatomy	Nội dung bắt buộc	Mục đích truy vết
Test case ID	Mã duy nhất của test case	Phân biệt từng kiểm thử
Test objective	Hành vi nghiệp vụ cần kiểm tra	Cho biết lý do tồn tại của test
Test basis	Requirement, business rule, acceptance criterion hoặc screen/API contract nguồn	Chứng minh expected result không phải suy đoán
Technique	Equivalence Partitioning, Boundary Value Analysis, Decision Table hoặc State Transition Testing	Giải thích cách chọn dữ liệu
Preconditions	Trạng thái, quyền, dữ liệu nền trước khi chạy	Giúp tái lập kết quả
Test data	Giá trị input cụ thể, dữ liệu tổng hợp	Cho phép chạy lại cùng tình huống
Steps	Thao tác theo thứ tự	Loại bỏ diễn giải khác nhau
Expected result	Kết quả hệ thống phải hiển thị, lưu, chặn hoặc tính	Tiêu chí đối chiếu
Actual result	Kết quả quan sát khi thực thi	Ghi nhận sự thật kiểm thử
Evidence reference	Ảnh chụp, log, request/response hoặc liên kết bằng chứng	Hỗ trợ review
Defect reference	ID lỗi nếu actual result khác expected result	Nối test với xử lý sai lệch

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

flowchart TB
    subgraph DESIGN["Thiết kế test case"]
        ID[Test case ID] --> OBJ[Test objective]
        OBJ --> BASIS[Test basis]
        BASIS --> TECH[Technique được chọn]
        TECH --> DATA[Test data]
        BASIS --> EXPECTED[Expected result]
    end

    PRE[Preconditions] --> RUN[Thực thi Test steps]
    DATA --> RUN
    STEPS[Test steps] --> RUN

    RUN --> ACTUAL[Actual result]
    ACTUAL --> EVIDENCE[Evidence reference]
    EXPECTED --> CMP{Đối chiếu kết quả}
    ACTUAL --> CMP

    CMP -->|Expected result = Actual result| PASS[Pass]
    CMP -->|Expected result != Actual result| FAIL[Fail]
    FAIL -->|Nếu ghi nhận lỗi| DEFECT[Defect reference]

Applied

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

Mục	Nội dung
Facts	Đơn bán hàng mô phỏng SO-NF-20260807-001 có số lượng đặt 101 thùng sản phẩm SP-NF-APPLEJUICE-1L. Tồn kho khả dụng mô phỏng là 100 thùng.
Current Behavior	Màn hình tạo đơn hiện cho lưu đơn khi số lượng đặt lớn hơn tồn kho khả dụng.
Underlying Need	Hệ thống cần chặn xác nhận số lượng vượt tồn kho khả dụng để tránh tạo cam kết giao hàng không có hàng. Đây là giả định dự án mô phỏng, không phải quy tắc vận hành Nova Foods thực tế.
Options	Kiểm thử một giá trị hợp lệ; kiểm thử một giá trị vượt tồn; kiểm thử ba điểm biên 99, 100, 101.
Decision Criteria	Cần phát hiện lỗi tại ranh giới tồn kho; dữ liệu ít; kết quả dễ lặp lại; bao phủ cả giá trị hợp lệ và không hợp lệ.
Decision	Dùng Boundary Value Analysis, tức phân tích giá trị biên: kiểm thử ngay dưới, đúng tại và ngay trên ngưỡng 100.
Authority	Business Owner và QA reviewer cần xác nhận quy tắc tồn kho mô phỏng trước khi dùng làm quy tắc vận hành. Micro-example này không ghi nhận approval.
Artifact	Bộ test case mô phỏng TC-NF-INV-001 đến TC-NF-INV-003, liên kết test basis BR-NF-INV-001 ở mức giả định học liệu.
Consequence if Wrong	Nếu expected result sai, test có thể báo lỗi giả hoặc bỏ sót việc nhận đơn vượt tồn; kế hoạch giao hàng và dữ liệu tồn kho mô phỏng sẽ bị hiểu sai.

Test case ID	Phân vùng/biên	Preconditions	Test data	Steps	Expected result	Actual result mẫu	Evidence reference
TC-NF-INV-001	Dưới biên: 99	Sản phẩm SP-NF-APPLEJUICE-1L có tồn kho khả dụng 100 thùng; người dùng mô phỏng có quyền tạo đơn	Đơn SO-NF-20260807-001; số lượng 99 thùng; đơn vị thùng	1. Mở tạo đơn bán hàng. 2. Chọn sản phẩm. 3. Nhập 99. 4. Lưu đơn.	Hệ thống cho lưu đơn; số lượng 99 không vượt 100.	Chưa thực thi trong micro-example.	Chưa có bằng chứng thực thi.
TC-NF-INV-002	Tại biên: 100	Sản phẩm SP-NF-APPLEJUICE-1L có tồn kho khả dụng 100 thùng; người dùng mô phỏng có quyền tạo đơn	Đơn SO-NF-20260807-002; số lượng 100 thùng; đơn vị thùng	1. Mở tạo đơn bán hàng. 2. Chọn sản phẩm. 3. Nhập 100. 4. Lưu đơn.	Hệ thống cho lưu đơn; số lượng bằng tồn kho khả dụng.	Chưa thực thi trong micro-example.	Chưa có bằng chứng thực thi.
TC-NF-INV-003	Trên biên: 101	Sản phẩm SP-NF-APPLEJUICE-1L có tồn kho khả dụng 100 thùng; người dùng mô phỏng có quyền tạo đơn	Đơn SO-NF-20260807-003; số lượng 101 thùng; đơn vị thùng	1. Mở tạo đơn bán hàng. 2. Chọn sản phẩm. 3. Nhập 101. 4. Lưu đơn.	Hệ thống không cho lưu đơn và hiển thị thông báo số lượng vượt tồn kho khả dụng. Nội dung thông báo cụ thể cần được xác định trong test basis.	Chưa thực thi trong micro-example.	Chưa có bằng chứng thực thi.

Senior Lens

Ba test case trên không chứng minh toàn bộ chức năng tồn kho đúng. Chúng chỉ bao phủ một biến: số lượng đặt so với tồn kho khả dụng 100. Evidence là kỹ thuật đã chọn chỉ thay đổi giá trị tại biên; không kiểm tra đồng thời kho khác, đơn vị quy đổi, giữ hàng, đơn song song hoặc thời điểm cập nhật tồn. Các biến đó cần test basis riêng trước khi mở rộng bộ test.

Không thay cụm “chưa thực thi” bằng kết quả giả. Actual result và evidence chỉ tồn tại sau lần chạy có thể tái lập. Nếu chưa có môi trường hoặc dữ liệu phù hợp, artifact vẫn nêu rõ khoảng trống bằng trạng thái thực tế thay vì suy diễn pass hoặc fail.

Quick Reference

Kiểm tra anatomy	Đạt khi
Truy vết	Mỗi test case chỉ rõ test basis và kỹ thuật chọn dữ liệu
Tái lập	Preconditions, test data và steps đủ để người khác chạy lại
Đối chiếu	Expected result đo được, không dùng từ mơ hồ như “xử lý đúng”
Trung thực bằng chứng	Actual result, evidence và defect chỉ ghi sau thực thi
Phạm vi	Mỗi test case nêu đúng biến đang kiểm tra, không suy rộng kết luận

Cổng chất lượng trước downstream review

Core

Cổng chất lượng (quality gate) là tập tiêu chí kiểm tra đủ tối thiểu trước khi chuyển output kiểm thử hộp đen sang người review tiếp theo. Cổng không phê duyệt nội dung, không baseline, không xác nhận sẵn sàng production. Bằng chứng: toàn corpus đang IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; metadata hiện hành không có approval reference hay baseline reference.

Output chỉ được gắn Ready for downstream review khi mọi tiêu chí bắt buộc đạt và mọi điểm chưa xác minh được gắn nhãn rõ. Nếu thiếu một tiêu chí, giữ trạng thái IN_REVIEW; không suy diễn rule, không tự sửa nguồn canonical.

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

stateDiagram-v2
    direction TB
    [*] --> IN_REVIEW
    IN_REVIEW --> IN_REVIEW: Thiếu tiêu chí bắt buộc hoặc điểm chưa xác minh chưa được gắn nhãn
    IN_REVIEW --> Ready_for_downstream_review: Mọi tiêu chí bắt buộc đạt và mọi điểm chưa xác minh được gắn nhãn rõ
    Ready_for_downstream_review: Ready for downstream review
    Ready_for_downstream_review --> IN_REVIEW: Có thay đổi nguồn hoặc phát hiện lỗi

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Mục	Nội dung
Facts	BA tạo output kiểm thử hộp đen cho luồng tạo đơn bán hàng. Input tham chiếu CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY; cả ba đang IN_REVIEW, v0.9.0.
Current Behavior	Output có test case và expected result, nhưng một expected result không chỉ ra rule hoặc field nguồn. Reviewer không thể kiểm tra reasoning bridge.
Underlying Need	Downstream reviewer cần tái tạo được quan hệ: nguồn canonical xác định điều kiện, kỹ thuật hộp đen tạo phân vùng hoặc biên, test case chứng minh expected result.
Options	1. Chuyển review khi nội dung đọc được. 2. Chuyển review khi đủ traceability, dữ liệu, expected result và lịch sử thay đổi.
Decision Criteria	Không có ID tự tạo; mọi suy luận có evidence bridge; dữ liệu tổng hợp; không gọi là approved, baselined, compliant hoặc production-ready; trạng thái corpus giữ IN_REVIEW.
Decision	Chọn phương án 2. Test case thiếu liên kết nguồn hoặc thiếu expected result không qua gate.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì quản trị artifact. Business Owner, QA reviewer, Architect, Legal Owner, Accounting Owner xác nhận phần thuộc thẩm quyền riêng khi cần; không vai trò nào được ngầm coi là đã chấp thuận.
Artifact	Output kiểm thử hộp đen, trạng thái IN_REVIEW, kèm change-history entry ngày 2026-08-07 theo Asia/Ho_Chi_Minh.
Consequence if Wrong	Reviewer có thể review nhầm giả định thành rule; lỗi biên dữ liệu hoặc expected result sai đi xuống QA, gây rework và mất traceability.

Senior Lens

Output chuyển review	Gate bắt buộc	Bằng chứng đạt gate	Không đạt khi
Test condition	Nêu điều kiện nghiệp vụ, kỹ thuật hộp đen dùng, nguồn canonical, phạm vi dữ liệu	Điều kiện liên kết được tới rule, data field hoặc requirement nguồn; reasoning bridge nêu vì sao chọn phân vùng, giá trị biên, bảng quyết định hoặc chuyển trạng thái	Chỉ có mô tả chung như “kiểm tra dữ liệu hợp lệ”
Test case	Có precondition, input tổng hợp, bước thực hiện, expected result kiểm tra được, traceability	Người khác có thể chạy lại cùng input và so sánh kết quả với expected result	Expected result mơ hồ, không đo được, hoặc chứa giả định không gắn nguồn
Test data	Không chứa dữ liệu cá nhân thật, dữ liệu tài chính thật, bí mật vận hành thật; giá trị phù hợp vi-VN và VND khi có tiền	Nhãn “synthetic data only”; giá trị biên và phân vùng được nhận diện	Sao chép dữ liệu production, hoặc không biết dữ liệu đại diện cho phân vùng nào
Defect record	Phân biệt actual result và expected result; tái hiện được; liên kết test case và nguồn	Bước tái hiện, môi trường mô phỏng, bằng chứng, mức ảnh hưởng được ghi; chưa kết luận nguyên nhân gốc nếu chưa điều tra	Gọi lỗi là “đã fix”, “đã chấp nhận”, hoặc gán nguyên nhân không có bằng chứng
Test execution result	Ghi kết quả quan sát, thời điểm, người ghi nhận, liên kết test case; không đổi expected result để khớp actual result	Kết quả có Pass, Fail, Blocked hoặc trạng thái đã định nghĩa trong artifact; Blocked nêu điều kiện chặn	Chỉ ghi “đã test”, hoặc che Fail bằng sửa nội dung test case
Test summary	Tổng hợp phạm vi đã chạy, chưa chạy, fail, blocked, rủi ro và giới hạn	Số liệu truy ngược tới execution result; kết luận chỉ nói mức độ sẵn sàng để review	Tuyên bố quality sign-off, approval, compliance hoặc production readiness

Change-history obligation: mỗi output cập nhật phải ghi version, ngày 2026-08-07 hoặc ngày cập nhật thực tế, múi giờ Asia/Ho_Chi_Minh, người ghi nhận, thay đổi và lý do. Không sửa im lặng. Nếu nguồn canonical đổi, output liên quan quay lại IN_REVIEW để đánh giá tác động.

Quick Reference

Checklist trước downstream review:

• [ ] Status output là IN_REVIEW; không dùng APPROVED, BASELINED, production-ready.
• [ ] Mọi expected result có nguồn canonical hoặc nhãn Verification required.
• [ ] Kỹ thuật hộp đen có reasoning bridge từ điều kiện nguồn tới dữ liệu kiểm thử.
• [ ] Dữ liệu Nova Foods là mô phỏng, tổng hợp; không chứa dữ liệu thật.
• [ ] ID và đường dẫn nguồn giữ nguyên, gồm CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY, TRACEABILITY_ID_REGISTRY.
• [ ] Change history ghi đủ người ghi nhận, thời điểm Asia/Ho_Chi_Minh, thay đổi và lý do.
• [ ] Điểm pháp lý, kế toán, thuế, bảo mật, an toàn thực phẩm chưa xác minh mang nhãn Verification required.
• [ ] Reviewer nhận đủ artifact và bằng chứng để kiểm tra, nhưng việc chuyển review không cấu thành phê duyệt.

7. Who consumes those outputs?

Core

Đầu ra kiểm thử hộp đen là gói bằng chứng để vai trò khác kiểm tra cùng một hành vi từ góc nhìn khác. Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu đều tổng hợp; mọi artifact giữ trạng thái IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, múi giờ Asia/Ho_Chi_Minh. Gói không tự tạo phê duyệt, baseline, xác nhận tuân thủ hay quyền triển khai production.

Consumer	Output nhận	Cách dùng
Developers	Test condition, test case, expected result, execution result Fail	Đối chiếu hành vi code với điều kiện kiểm thử; tái tạo lỗi bằng input, precondition, bước chạy và expected result.
QA	Test basis, test condition, test case, test data, execution result, test summary	Kiểm tra độ bao phủ, tính truy vết và tính chạy lại được; phân biệt lỗi sản phẩm, lỗi test case, lỗi môi trường, thiếu dữ liệu.
Architect	Test condition liên quan tích hợp, test data, execution result, test summary	Xem hành vi qua ranh giới ERP, API, quyền truy cập, dữ liệu và phụ thuộc kỹ thuật; nhận diện tác động kiến trúc giữa thành phần.
PM/Product Owner	Test summary, execution result, traceability	Nhìn phạm vi đã kiểm, chưa kiểm, Fail, Blocked và rủi ro theo yêu cầu hoặc backlog item; dùng để điều phối review phạm vi.
Business Owner	Test case nghiệp vụ, expected result, test summary	Kiểm tra test có phản ánh quy tắc và kết quả nghiệp vụ mong muốn hay không; nhận biết vùng quy tắc còn chưa được xác minh.
Operations	Test case luồng vận hành, test data, execution result	Đối chiếu thao tác dự kiến với điểm bàn giao, ngoại lệ và dữ liệu vận hành mô phỏng; phát hiện bước không thực hiện được trong luồng làm việc.
Specialist owners	Test condition và expected result thuộc chuyên môn	Legal, Accounting, Security, Food Safety hoặc Data Owner xem phần thuộc phạm vi chuyên môn; xác định nội dung nào còn Verification required.

Test condition là điều kiện cần kiểm, ví dụ “số lượng nhận hàng bằng 0”. Test case là kịch bản chạy cụ thể gồm input, bước và expected result. Test summary là tổng hợp phạm vi, trạng thái chạy và giới hạn; nó không thay thế bằng chứng chi tiết của từng test case.

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

flowchart TB
    BA[BA]

    subgraph PKG["Gói bằng chứng kiểm thử hộp đen"]
        META["Trạng thái IN_REVIEW · phiên bản v0.9.0<br/>2026-08-07 · Asia/Ho_Chi_Minh"]
        LIMIT["Không tự tạo phê duyệt, baseline,<br/>xác nhận tuân thủ hoặc quyền triển khai production"]

        REQ[Yêu cầu hoặc backlog item]
        TB[Test basis]
        CON[Test condition]
        TC["Test case<br/>input · precondition · bước chạy"]
        TD[Test data]
        ER[Expected result]
        RUN["Thực thi test case<br/>và đối chiếu expected result"]
        XR["Execution result<br/>Fail · Blocked · trạng thái khác"]
        TR[Traceability]
        CMP["Đối chiếu yêu cầu hoặc backlog item<br/>với execution result"]
        DONE[Phạm vi đã thực thi]
        UNDONE[Phạm vi chưa thực thi]
        RISK[Rủi ro theo yêu cầu hoặc backlog item]
        TS["Test summary<br/>phạm vi · trạng thái chạy · giới hạn"]

        TB -->|dẫn xuất| CON
        CON -->|cụ thể hóa| TC

        REQ --> TR
        CON --> TR
        TC -->|độ bao phủ| TR
        XR --> TR

        TC --> RUN
        TD --> RUN
        ER --> RUN
        RUN --> XR

        TR --> CMP
        XR --> CMP
        CMP -->|có execution result| DONE
        CMP -->|chưa có execution result| UNDONE
        CMP -->|nhận diện| RISK

        DONE -->|phạm vi đã kiểm| TS
        UNDONE -->|phạm vi chưa kiểm| TS
        XR -->|Fail, Blocked và trạng thái chạy| TS
        RISK --> TS
    end

    BA -->|cung cấp| TB
    BA -->|cung cấp| CON
    BA -->|cung cấp| TC
    BA -->|cung cấp| TD
    BA -->|cung cấp| ER
    BA -->|cung cấp| TR

    subgraph USE["Vai trò sử dụng và giá trị nhận được"]
        DEV["Developers<br/>tái tạo lỗi và đối chiếu hành vi code"]
        QA["QA<br/>kiểm tra bao phủ, truy vết, khả năng chạy lại<br/>và phân loại nguyên nhân lỗi"]
        ARC["Architect<br/>xem ranh giới ERP, API, quyền truy cập,<br/>dữ liệu và phụ thuộc kỹ thuật"]
        PO["PM/Product Owner<br/>điều phối review phạm vi"]
        BO["Business Owner<br/>kiểm tra quy tắc và kết quả nghiệp vụ"]
        OPS["Operations<br/>phát hiện bước không thực hiện được"]
        SPO["Specialist owners<br/>review nội dung thuộc chuyên môn"]
        VR[Verification required]
    end

    CON --> DEV
    TC -->|input, precondition và bước chạy| DEV
    ER -->|kết quả mong muốn| DEV
    XR -->|Fail để tái tạo lỗi| DEV

    TB --> QA
    CON --> QA
    TC --> QA
    TD --> QA
    ER --> QA
    XR -->|phân biệt lỗi sản phẩm, test case,<br/>môi trường hoặc thiếu dữ liệu| QA
    TS --> QA

    CON -->|điều kiện tích hợp| ARC
    TD -->|dữ liệu qua ranh giới| ARC
    XR -->|tác động giữa thành phần| ARC
    TS --> ARC

    TR -->|theo yêu cầu hoặc backlog item| PO
    XR -->|Fail và Blocked| PO
    TS -->|đã kiểm, chưa kiểm và rủi ro| PO

    TC -->|kịch bản nghiệp vụ| BO
    ER -->|kết quả nghiệp vụ mong muốn| BO
    TS -->|vùng quy tắc chưa được xác minh| BO

    TC -->|luồng vận hành và điểm bàn giao| OPS
    TD -->|dữ liệu vận hành mô phỏng| OPS
    XR -->|ngoại lệ và bước không thực hiện được| OPS

    CON -->|thuộc chuyên môn| SPO
    ER -->|thuộc chuyên môn| SPO
    SPO -->|nội dung chưa xác minh| VR

    META -. áp dụng cho toàn bộ gói .-> TB
    LIMIT -. ranh giới của toàn bộ gói .-> TS

Applied

Facts: Nova Foods mô phỏng có test case cho chức năng ghi nhận nhận hàng. Input tổng hợp gồm PO-NF-2026-001, mã nguyên liệu RM-SUGAR-001, số lượng nhận 0, đơn vị KG. Expected result ghi: hệ thống từ chối hoàn tất nhận hàng khi số lượng nhận bằng 0. Execution result là Fail: màn hình cho phép lưu phiếu nhận hàng.

Current Behavior: Developers nhận Fail để tái tạo lỗi. QA nhận cùng test case để kiểm tra dữ liệu, bước chạy và expected result còn đúng nguồn hay không. Architect nhận kết quả khi lỗi liên quan luồng giữa màn hình nhận hàng và dịch vụ tồn kho. PM/Product Owner nhận test summary để thấy phạm vi bị ảnh hưởng. Business Owner nhận expected result để xem điều kiện “không nhận 0 kg” có đúng ý nghĩa nghiệp vụ mô phỏng. Operations nhận bước thao tác để xác định điểm nghẽn tại quầy nhận hàng. Accounting hoặc Food Safety Owner chỉ nhận phần liên quan khi quy tắc có tác động chuyên môn.

Underlying Need: Mỗi consumer phải nhận cùng ID test case và cùng execution result. Lý do: nếu một vai trò chỉ nhận ảnh chụp lỗi, còn vai trò khác nhận expected result đã sửa, hai bên không còn kiểm tra cùng một bằng chứng.

Options: Gửi riêng test summary; gửi test case chi tiết; gửi cả hai. Test summary cho góc nhìn phạm vi, nhưng không đủ tái tạo lỗi. Test case chi tiết cho tái tạo lỗi, nhưng không cho thấy mức độ ảnh hưởng tổng thể. Vì vậy gói handoff gồm test case chi tiết và test summary liên kết.

Decision Criteria: Consumer cần tái tạo hành vi nhận test case, test data và execution result. Consumer cần đánh giá phạm vi nhận test summary và traceability. Consumer chuyên môn chỉ nhận artifact có điều kiện thuộc lĩnh vực của họ.

Decision: Phân phối theo mục đích sử dụng, không phân phối một bản tóm tắt chung thay cho bằng chứng chi tiết.

Authority: Micro-batch này chỉ mô tả người tiêu thụ artifact. Không xác định quyền phê duyệt, quyền chấp nhận rủi ro hoặc quyền quyết định quy tắc Nova Foods.

Artifact: Test condition, test case, test data, execution result và test summary giữ liên kết tới CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY và TRACEABILITY_ID_REGISTRY khi các nguồn này được tham chiếu.

Consequence if Wrong: Developer có thể sửa triệu chứng thay vì lỗi. QA có thể chạy lại với dữ liệu khác. Business Owner có thể nhận báo cáo thiếu expected result. Operations có thể phát hiện muộn thao tác không khả thi. Specialist owner có thể không thấy điểm cần kiểm tra chuyên môn.

Senior Lens

Không phải mọi consumer cần mọi chi tiết. Developer cần dữ liệu tái tạo. PM/Product Owner cần ảnh hưởng và trạng thái. Business Owner cần ý nghĩa nghiệp vụ. Architect cần ranh giới thành phần. Gửi đúng mức chi tiết giảm diễn giải sai nhưng không được cắt đứt traceability.

Phân phối artifact không chuyển thẩm quyền. Ví dụ, test case tham chiếu một quy tắc có thể liên quan kế toán, pháp lý, bảo mật hoặc an toàn thực phẩm. Consumer đọc artifact không biến quy tắc đó thành nội dung đã xác minh. Giữ nhãn Verification required nếu nguồn chuyên môn chưa được xác minh.

Quick Reference

Output	Consumer chính	Consumer phụ
Test condition	QA, Business Owner, specialist owners	Developers, Architect
Test case và expected result	QA, Developers, Business Owner, Operations	Architect, specialist owners
Test data	QA, Developers	Architect, Operations
Execution result	QA, Developers, PM/Product Owner	Architect, Business Owner, Operations
Test summary	PM/Product Owner, QA	Business Owner, Architect, Operations, specialist owners
Traceability	QA, PM/Product Owner	Developers, Business Owner, Architect

Quyết định, bằng chứng và điểm phải chuyển cấp

Trong Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, đầu ra kiểm thử hộp đen gồm điều kiện kiểm thử, lớp tương đương, giá trị biên, ca kiểm thử, kết quả thực thi và bằng chứng lỗi. Mỗi đầu ra chỉ hỗ trợ quyết định khi liên kết được với requirement hoặc quy tắc nguồn. IN_REVIEW, v0.9.0, ngày 2026-08-07 không phải bằng chứng phê duyệt, baseline hay quyền triển khai.

Người nhận	Có thể quyết định	Bằng chứng cần có	Phải chuyển cấp khi
Developers	Sửa mã, từ chối lỗi là không tái hiện được, hoặc yêu cầu làm rõ hành vi	Ca kiểm thử có bước tái hiện; input tổng hợp; expected result; actual result; môi trường; liên kết requirement	Expected result không có nguồn canonical; lỗi gợi ý thay đổi quy tắc nghiệp vụ; sửa ảnh hưởng dữ liệu, bảo mật hoặc tích hợp
QA	Ghi nhận lỗi, phân loại mức ảnh hưởng, chạy hồi quy, hoặc chặn kết quả test	Test basis; kỹ thuật hộp đen đã dùng; kết quả pass/fail; ảnh chụp hoặc log tổng hợp; truy vết ca test	Không xác định được oracle, tức nguồn xác định kết quả đúng; lỗi lặp nhưng điều kiện không ổn định; nghi ngờ rò rỉ dữ liệu
Architect	Chấp nhận hướng khắc phục kỹ thuật trong phạm vi kiến trúc, hoặc yêu cầu thiết kế lại	Luồng lỗi; API contract nếu có; tác động module; lỗi đồng thời; giới hạn hiệu năng hoặc bảo mật	Thay đổi interface, schema, quyền truy cập, tích hợp hoặc quyết định công nghệ vượt phạm vi sprint
PM/Product Owner	Ưu tiên sửa, điều chỉnh phạm vi phát hành, hoặc chấp nhận rủi ro đã được chủ sở hữu nêu rõ	Mức ảnh hưởng người dùng; số ca bị ảnh hưởng; liên kết mục tiêu phát hành; bằng chứng tái hiện	Cần đổi requirement, cam kết phát hành, chi phí, thời hạn hoặc rủi ro chưa có chủ sở hữu quyết định
Business Owner	Xác định hành vi nghiệp vụ mong muốn khi nhiều diễn giải cùng hợp lý	Requirement, quy tắc từ CANONICAL_BUSINESS_RULES, ví dụ dữ liệu tổng hợp, tác động quy trình	Liên quan giá bán, chính sách khách hàng, phê duyệt nghiệp vụ hoặc quy tắc chưa được ghi nhận canonical
Operations	Quyết định chuẩn bị vận hành mô phỏng, giám sát, xử lý sự cố và điều kiện rollback	Kịch bản lỗi; ảnh hưởng batch; cảnh báo; khả năng khôi phục; dữ liệu tổng hợp trước và sau xử lý	Có nguy cơ mất dữ liệu, gián đoạn dịch vụ, sai lệch tồn kho hoặc cần thao tác production
Specialist owners: Accounting, Legal, Security, Food Safety	Xác nhận cần kiểm chứng chuyên môn, không xác nhận thay BA	Điều kiện test, dữ liệu bị ảnh hưởng, nguồn luật hoặc chuẩn, giả định dự án được gắn nhãn Verification required	Liên quan kế toán, thuế, dữ liệu cá nhân, hóa đơn, an toàn thực phẩm, truy xuất nguồn gốc hoặc lỗ hổng bảo mật

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

flowchart TB
    T[Test result] --> E[Evidence package: reproducible steps; synthetic input; expected and actual results; environment; requirement traceability]
    E --> O{QA: canonical expected result exists?}

    O -- No --> UO[QA records unresolved oracle]
    UO --> BO[Business Owner clarifies business behavior]
    BO --> CR[Authorized requirement owner or BA records canonical source]
    CR --> TB[QA updates test basis]
    TB --> O

    O -- Yes --> ST{QA: condition stable and reproducible?}
    ST -- No --> US[QA records unstable condition and reviews reproducibility evidence]
    US --> E
    ST -- Yes --> RS{QA: pass or fail?}

    RS -- Pass --> OK[QA records pass result]
    RS -- Fail --> DF[QA records defect, impact, and evidence]

    DF --> PMD{Release priority, scope, commitment, cost, deadline, or owned risk decision needed?}
    PMD -- Yes --> PM[PM/Product Owner prioritizes or decides scope, release, or risk]
    PMD -- No --> SD
    PM --> SD

    SD{Accounting, tax, personal data, invoices, legal, security, food safety, or traceability question?}
    SD -- Yes --> SO[Relevant specialist owner: Verification required]
    SD -- No --> AD
    SO --> AD

    AD{Interface, schema, access rights, integration, or technology change?}
    AD -- Yes --> AR[Architect accepts technical direction or requires redesign]
    AD -- No --> OD
    AR --> OD

    OD{Data loss, service disruption, inventory mismatch, or operations risk?}
    OD -- Yes --> OP[Operations assesses monitoring, recovery, and rollback]
    OD -- No --> DR
    OP --> PA{Production action or rollback needed?}
    PA -- Yes --> BL[Block production action; escalate to authorized production or operations authority]
    PA -- No --> DR

    DR[Developer reviews defect]
    DR --> NR{Developer disputes reproducibility?}
    NR -- Yes --> UD[QA records unresolved disagreement and reviews reproducibility evidence]
    UD --> E
    NR -- No --> CL{Developer needs behavior clarification?}
    CL -- Yes --> UO
    CL -- No --> FX[Developer fixes]
    FX --> RG[QA runs regression]
    RG --> RS

Quy tắc chuyển cấp: BA không tự chọn expected result khi requirement mơ hồ. Bằng chứng là cầu nối: nếu ca kiểm thử nhập quantity = 0, hệ thống từ chối, nhưng nguồn không nói 0 hợp lệ hay không hợp lệ, kết quả “fail” chưa chứng minh lỗi phần mềm. Nó chứng minh khoảng trống yêu cầu; Business Owner phải làm rõ, rồi QA cập nhật test basis.

Câu hỏi làm rõ bắt buộc khi handoff: “Expected result này dựa trên requirement hoặc quy tắc canonical nào?”; “Đây là lỗi triển khai hay thiếu quyết định nghiệp vụ?”; “Ai có thẩm quyền xác định giá trị biên này?”; “Sửa lỗi có đổi API, dữ liệu, quyền truy cập hoặc luồng vận hành không?”; “Có nghĩa vụ pháp lý, kế toán, bảo mật hoặc an toàn thực phẩm cần Verification required không?”

Core

Handoff là chuyển giao đầu ra kiểm thử hộp đen (black-box testing: kiểm tra theo hành vi quan sát được, không xét mã nguồn) cho vai trò dùng nó quyết định. Nhầm lẫn thường xảy ra khi người nhận coi test case là quyết định nghiệp vụ, hoặc coi kết quả chạy test là bằng chứng kiến trúc hay tuân thủ. Với Nova Foods Trading & Manufacturing mô phỏng, dữ liệu tổng hợp, mỗi câu hỏi phải chỉ rõ artifact, quy tắc, dữ liệu, môi trường và người có thẩm quyền trả lời.

Nhầm lẫn giao nhận	Rủi ro	Câu hỏi làm rõ chính xác
Developer hiểu expected result là thiết kế kỹ thuật bắt buộc	Code theo suy đoán, sai rule nghiệp vụ	“Expected result này truy vết tới business rule, acceptance criterion, hay giả định test nào? Vui lòng cung cấp ID canonical.”
QA hiểu dữ liệu biên là dữ liệu production	Test sai phạm vi hoặc lộ dữ liệu	“Giá trị biên này là dữ liệu tổng hợp cho test hay giá trị nghiệp vụ đã được xác nhận? Artifact nguồn là gì?”
PM/Product Owner coi test pass là chấp thuận nghiệp vụ	Pass chỉ chứng minh ca test chạy đúng với test basis hiện có	“Những acceptance criterion nào đã được kiểm tra, và criterion nào chưa có test basis hoặc chưa được quyết định?”
Architect nhận lỗi giao diện nhưng thiếu luồng tích hợp	Không đánh giá được contract, timeout, lỗi liên hệ thống	“Lỗi này xảy ra trước hay sau điểm gọi API? Request, response, mã HTTP và correlation ID mô phỏng là gì?”
Operations coi lỗi test là hướng dẫn vận hành	Runbook sai, xử lý sự cố sai thẩm quyền	“Đây là hành vi mong đợi của hệ thống hay thủ tục vận hành cần xác nhận? Ai sở hữu quy trình xử lý ngoại lệ?”
Specialist owner nhận quy tắc có yếu tố pháp lý, kế toán, an toàn thực phẩm nhưng không có nguồn xác minh	Quyết định vượt thẩm quyền BA hoặc QA	“Nội dung nà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ào?”

Applied

Facts: Test case tổng hợp TC-NF-ORD-014 kiểm tra đơn bán hàng Nova Foods mô phỏng có số lượng 0, kỳ vọng hệ thống từ chối lưu. Developer hỏi có được tự đặt thông báo lỗi “Số lượng phải lớn hơn 0” không.

Current Behavior: Test case chỉ ghi “không cho lưu”; không có ID business rule, không có bản thiết kế thông báo, không có phân biệt giữa nhập tay và API.

Underlying Need: QA cần hành vi kiểm thử được; Developer cần điều kiện xử lý; Product Owner cần quyết định trải nghiệm; Architect cần biết API contract có bị ảnh hưởng.

Options: Giữ test case mơ hồ; Developer tự chọn thông báo; BA làm rõ test basis trước khi phát triển.

Decision Criteria: Điều kiện phải truy vết được; thông báo không tự tạo rule mới; khác biệt UI/API phải được chỉ rõ; người có thẩm quyền quyết định nội dung nghiệp vụ.

Decision: Gắn trạng thái clarification required cho TC-NF-ORD-014; không suy diễn thông báo hay mã lỗi từ câu “không cho lưu”.

Authority: Product Owner hoặc Business Owner quyết định hành vi nghiệp vụ và thông điệp; Architect xác nhận contract API; QA cập nhật test case theo quyết định được ghi nhận. BA bảo toàn truy vết, không tự phê duyệt.

Artifact: Câu hỏi giao nhận ghi trong test clarification log liên kết TC-NF-ORD-014: “Khi số lượng bằng 0, hệ thống phải chặn tại UI, API, hay cả hai? Kết quả mong đợi gồm mã lỗi, nội dung hiển thị, trường bị đánh dấu và rule ID nào?”

Consequence if Wrong: Developer có thể chặn UI nhưng API vẫn nhận 0; QA báo pass ở UI; đơn hàng lỗi vẫn vào hệ thống qua tích hợp. Bằng chứng hiện có chỉ nêu “không cho lưu”, nên không đủ kết luận phạm vi chặn.

Senior Lens

Không dùng câu “đã hiểu” làm bằng chứng handoff. Dùng câu hỏi có thể trả lời bằng artifact. Nếu câu trả lời đổi rule, phạm vi API, dữ liệu cá nhân, hạch toán, truy xuất nguồn gốc thực phẩm, hoặc quyền vận hành, escalation tới owner chuyên môn. IN_REVIEW và v0.9.0 không phải approval, baseline, xác nhận tuân thủ hay quyền triển khai.

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

flowchart TB
    A[Test case hoặc defect] --> B{Có rule và expected result truy vết được?}
    B -- Có --> C[Consumer xác nhận phạm vi sử dụng artifact]
    B -- Không --> D[BA ghi clarification question]
    D --> E[Owner có thẩm quyền trả lời clarification]
    E --> F{Câu trả lời làm đổi rule, phạm vi API, dữ liệu cá nhân, hạch toán, truy xuất nguồn gốc thực phẩm hoặc quyền vận hành?}
    F -- Có --> G[Owner chuyên môn đánh giá và ghi quyết định vào artifact liên kết]
    F -- Không --> H[Cập nhật artifact liên kết]
    G --> C
    H --> C
    C --> I[`IN_REVIEW` và `v0.9.0` không là approval, baseline, xác nhận tuân thủ hoặc quyền triển khai]
    I --> J{Theo phạm vi có cần approval, baseline hoặc xác nhận tuân thủ?}
    J -- Có --> K{Đã có approval, baseline hoặc xác nhận tuân thủ bắt buộc?}
    K -- Không --> L[Dừng handoff: thiếu approval, baseline hoặc xác nhận tuân thủ]
    K -- Có --> M{Phạm vi có hoạt động triển khai?}
    J -- Không áp dụng --> M
    M -- Không --> N[Consumer thực hiện quyết định trong phạm vi vai trò]
    M -- Có --> O{Quyền triển khai đã được owner có thẩm quyền cấp?}
    O -- Không --> P[Không được triển khai]
    O -- Có --> Q[Người có quyền triển khai thực hiện triển khai]

Quick Reference

Khi nhận bàn giao	Hỏi trước khi hành động
Expected result	“Nguồn canonical và ID truy vết là gì?”
Dữ liệu test	“Dữ liệu này tổng hợp hay có ràng buộc bảo mật nào?”
Lỗi tích hợp	“Điểm gọi, request, response, mã HTTP và thời điểm tái hiện là gì?”
Rule có yếu tố chuyên ngành	“Ai có thẩm quyền xác nhận, và nguồn chính thức nào cần Verification required?”
Test pass	“Pass cho test case nào; acceptance criterion nào vẫn chưa được kiểm tra?”

8. Detailed Worked Example

Core

Ví dụ này dùng kiểm thử hộp đen (black-box testing): BA và QA quan sát input, output, thông báo lỗi và trạng thái lưu, không suy đoán mã nguồn. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu dưới đây là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Trạng thái corpus: IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07; không phải baseline, approval hay cấu hình ERP thực tế.

Applied

Facts: Bằng chứng đầu vào là câu hỏi làm rõ đã ghi cho ORD-014: “Khi số lượng bằng 0, hệ thống phải chặn tại UI, API, hay cả hai? Kết quả mong đợi gồm mã lỗi, nội dung hiển thị, trường bị đánh dấu và rule ID nào?” Câu hỏi này chứng minh rule hiện chưa đủ test basis: chưa xác định lớp chặn, mã lỗi, rule ID, hay kết quả lưu. Không có nguồn nào trong gói hiện tại xác nhận một business rule Nova Foods đã được phê duyệt.

Trường	Giá trị quan sát mô phỏng
Đối tượng	Dòng hàng đơn bán Sales Order Line
Giao dịch	Tạo đơn bán
Dữ liệu hàng	FG-NUOC-MAM-500ML
Tên hàng	Nước mắm Nova 500 ml
Đơn giá	45000 VND
Số lượng nhập	0
Thành tiền tính từ input	0 VND
Kênh quan sát	Màn hình tạo đơn bán và API tạo đơn
Rule liên quan	ORD-014
Phân loại nguồn	Evidence cần làm rõ; không phải canonical business rule
Dữ liệu cá nhân	Không dùng
Yếu tố pháp lý, thuế, kế toán	Không suy diễn; Verification required nếu scope sau này chạm các lĩnh vực này

Current Behavior: Với cùng input số lượng 0, màn hình mô phỏng cho phép người dùng bấm lưu. Hệ thống gửi request API. API trả HTTP 201 Created; đơn và dòng hàng được tạo với số lượng 0, thành tiền 0 VND. Đây là hành vi quan sát để thiết kế test, không phải kết luận rằng hành vi đúng.

Bước	Hành động	Input hoặc output quan sát	Bằng chứng
1	Người dùng mở tạo đơn bán	Form có trường quantity	Quan sát UI mô phỏng
2	Người dùng thêm FG-NUOC-MAM-500ML	quantity = 0, unitPrice = 45000	Test data tổng hợp
3	Người dùng bấm lưu	UI không đánh dấu lỗi trường số lượng	Quan sát UI mô phỏng
4	UI gọi API	Payload bên dưới	Quan sát network mô phỏng
5	API xử lý	HTTP 201 Created	Response mô phỏng
6	Hệ thống lưu dòng đơn	quantity = 0, lineAmount = 0	Bản ghi mô phỏng sau lưu

{
  "salesOrderNo": "SO-20260807-001",
  "orderDate": "2026-08-07",
  "currency": "VND",
  "lines": [
    {
      "itemCode": "FG-NUOC-MAM-500ML",
      "quantity": 0,
      "unitPrice": 45000
    }
  ]
}

{
  "status": 201,
  "salesOrderNo": "SO-20260807-001",
  "lineCount": 1,
  "totalAmount": 0,
  "currency": "VND"
}

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

flowchart TB
    U[Người dùng<br/>quantity = 0] --> S[Bấm lưu đơn bán]
    S --> U1

    subgraph UI[UI tạo đơn bán]
        direction TB
        U1[Không đánh dấu lỗi<br/>trường quantity]
        U2[POST API tạo đơn bán]
        U1 --> U2
    end

    subgraph API[API tạo đơn bán]
        direction TB
        A1[Nhận request]
        A2[Trả HTTP 201 Created]
        A1 --> A2
    end

    subgraph DB[Lưu trữ quan sát sau lưu]
        direction TB
        D1[Dòng đơn<br/>quantity = 0<br/>lineAmount = 0 VND]
        D2[Đơn bán<br/>totalAmount = 0 VND]
        D1 --> D2
    end

    U2 --> A1
    A2 -. Bản ghi quan sát sau lưu .-> D1

Underlying Need: Dấu hiệu cần làm rõ là input 0 đi xuyên từ UI tới API và tạo dữ liệu. Bằng chứng là HTTP 201 Created cùng bản ghi dòng đơn có số lượng bằng 0. Tuy nhiên, bằng chứng này chỉ chứng minh hành vi hiện tại. Nó không chứng minh 0 phải bị chặn, phải được phép cho dòng khuyến mại, hay phải xử lý khác theo loại đơn. Cần Business Owner xác định ý nghĩa nghiệp vụ của số lượng 0; cần Architect hoặc API owner xác định boundary UI/API nếu rule được xác nhận.

Senior Lens

Không đổi “hành vi hiện tại” thành “expected result”. Test hộp đen cần tách fact khỏi phán đoán: input là 0; output quan sát là 201 Created; kết luận đúng/sai chưa tồn tại vì ORD-014 chưa có rule canonical và authority xác nhận. Không gán rule ID mới, không ghi approval, không suy diễn nghĩa vụ kế toán hay hóa đơn từ ví dụ này.

Quick Reference

Thành phần	Giá trị dùng trong case
Case	Nova Foods mô phỏng, dữ liệu tổng hợp
Rule đang làm rõ	ORD-014
Biên giá trị quan sát	quantity = 0
Hành vi UI hiện tại	Không báo lỗi
Hành vi API hiện tại	HTTP 201 Created
Kết quả lưu hiện tại	Một dòng hàng, số lượng 0, thành tiền 0 VND
Trạng thái quyết định	Chưa có authorized decision

Applied

Bối cảnh: 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. Mục tiêu: dùng phân vùng tương đương (equivalence partitioning: chia đầu vào thành nhóm dự kiến cho cùng kết quả) và phân tích giá trị biên (boundary value analysis: kiểm tra sát ngưỡng) cho chức năng tạo phiếu nhận nguyên liệu.

Mục	Giá trị
Scenario ID cục bộ	NF-S08-RCV-001
Chức năng	Tạo Goods Receipt cho nguyên liệu bột mì
Người dùng mô phỏng	Nhân viên Kho nguyên liệu
Ngày giờ test	2026-08-07, Asia/Ho_Chi_Minh
Tiền tệ ngữ cảnh	VND
Nguồn phân loại	Project assumption; không phải quy tắc pháp lý, kế toán, an toàn thực phẩm hay cấu hình production
Artifact đích	/02-handbook/19-black-box-testing-techniques-for-ba.md
Trạng thái corpus	IN_REVIEW, v0.9.0

Facts

Fact ID cục bộ	Dữ kiện tổng hợp	Bằng chứng trong case
NF-F-001	Đơn mua PO-NF-260807-001 đặt 100 kg bột mì RM-FLOUR-001.	Dữ liệu đầu vào scenario.
NF-F-002	Kho chỉ được nhận số lượng lớn hơn 0 và không vượt số lượng chưa nhận của đơn mua.	Mục tiêu ngăn nhận âm, bằng 0 hoặc nhận vượt đơn.
NF-F-003	Số lượng đã nhận trước đó của PO-NF-260807-001 là 0 kg. Số lượng còn được nhận là 100 kg.	100 - 0 = 100; biên trên hiện hành là 100 kg.
NF-F-004	Hệ thống nhận trường receivedQuantityKg dạng số nguyên kg.	Payload mô phỏng bên dưới.
NF-F-005	Case không đánh giá thuế, hạch toán, hóa đơn, hạn dùng, chất lượng hay truy xuất lô.	Các chủ đề đó không có dữ kiện nguồn và không được suy diễn.

Payload mô phỏng:

{
  "purchaseOrderId": "PO-NF-260807-001",
  "materialId": "RM-FLOUR-001",
  "receivedQuantityKg": 100,
  "uom": "KG",
  "warehouseId": "WH-RM-HCM-001"
}

Current Behavior

Hành vi hiện tại được giả định để tạo test basis: màn hình cho nhập receivedQuantityKg; hệ thống lưu phiếu nhận khi số lượng là số nguyên từ 1 đến 100. Giá trị ngoài khoảng bị từ chối và không tạo phiếu nhận. Dữ kiện NF-F-002 và NF-F-003 dẫn tới ba phân vùng: không hợp lệ <= 0, hợp lệ 1..100, không hợp lệ > 100.

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

flowchart TB
    A[Nhập receivedQuantityKg] --> B{Số nguyên?}
    B -- Không --> X[Từ chối: định dạng không hợp lệ]
    B -- Có --> C{Từ 1 đến 100 kg?}
    C -- Có --> D[Tạo Goods Receipt]
    C -- Không --> Y[Từ chối: ngoài phạm vi 1 đến 100]

Underlying Need

Nhu cầu gốc không phải “test các số ngẫu nhiên”. Nhu cầu là chứng minh hệ thống phân biệt đúng ba lớp đầu vào có hậu quả nghiệp vụ khác nhau. Nếu nhận 101 kg, tồn kho mô phỏng tăng nhiều hơn số lượng đơn mua còn mở. Nếu nhận 0 hoặc số âm, phiếu nhận không phản ánh hàng vật lý. Vì NF-F-003 xác định biên trên 100 kg, BA phải kiểm tra sát hai phía của biên này.

Options

Option	Thiết kế test	Bao phủ	Hạn chế
OPT-1	Test ngẫu nhiên 50 kg và 150 kg.	Có một giá trị hợp lệ, một giá trị vượt.	Bỏ sót biên 0, 1, 100, 101.
OPT-2	Chỉ dùng phân vùng tương đương: -1, 50, 101.	Mỗi phân vùng một đại diện.	Không chứng minh lỗi so sánh tại biên.
OPT-3	Kết hợp phân vùng tương đương và giá trị biên: -1, 0, 1, 50, 99, 100, 101.	Bao phủ ba phân vùng và biên dưới, biên trên.	Nhiều test hơn OPT-1, OPT-2.

Decision Criteria

Criterion ID cục bộ	Tiêu chí	Cách đánh giá
NF-DC-001	Phát hiện lỗi > so với >=, < so với <=.	Phải có 0, 1, 100, 101.
NF-DC-002	Mỗi phân vùng đầu vào có ít nhất một test.	Phải có giá trị âm, hợp lệ giữa khoảng, vượt 100.
NF-DC-003	Kết quả quan sát được, không suy diễn xử lý nội bộ.	Chỉ kiểm tra phản hồi và có/không có phiếu nhận.
NF-DC-004	Không mở rộng sang rule chưa có dữ kiện.	Không test giá, thuế, hạn dùng, lô.

Decision

Khuyến nghị BA: chọn OPT-3. Lý do: OPT-3 thỏa NF-DC-001 đến NF-DC-004; hai option còn lại không đủ bằng chứng về lỗi tại ngưỡng.

Đây là khuyến nghị học liệu, chưa là quyết định được ủy quyền. Không có approval, baseline hay xác nhận cấu hình Nova Foods thật.

Test ID cục bộ	receivedQuantityKg	Phân vùng	Kết quả mong đợi
NF-TC-001	-1	Không hợp lệ: nhỏ hơn 1	Từ chối; không tạo Goods Receipt.
NF-TC-002	0	Biên dưới không hợp lệ	Từ chối; không tạo Goods Receipt.
NF-TC-003	1	Biên dưới hợp lệ	Chấp nhận; tạo Goods Receipt 1 kg.
NF-TC-004	50	Hợp lệ trong khoảng	Chấp nhận; tạo Goods Receipt 50 kg.
NF-TC-005	99	Cận trên hợp lệ	Chấp nhận; tạo Goods Receipt 99 kg.
NF-TC-006	100	Biên trên hợp lệ	Chấp nhận; tạo Goods Receipt 100 kg.
NF-TC-007	101	Biên trên không hợp lệ	Từ chối; không tạo Goods Receipt.

Authority

Nội dung	Vai trò có thẩm quyền cần xác nhận	Trạng thái
Biên nhận tối đa bằng số lượng đơn mua còn mở	Business Owner hoặc Warehouse Process Owner	Verification required
Kiểu dữ liệu số nguyên kg	Solution Architect hoặc System Owner	Verification required
Kết quả test và bằng chứng thực thi	QA Owner	Verification required
Khuyến nghị OPT-3	BA ghi nhận khuyến nghị; không thay quyền quyết định	IN_REVIEW

Artifact

Artifact test basis cục bộ gồm Facts NF-F-001 đến NF-F-005, criteria NF-DC-001 đến NF-DC-004, và test cases NF-TC-001 đến NF-TC-007 trong section này của /02-handbook/19-black-box-testing-techniques-for-ba.md. Các ID cục bộ chỉ phục vụ scenario giáo dục; không thay thế ID canonical trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md.

Consequence if Wrong

Nếu chỉ test 50 kg, lỗi từ chối 100 kg có thể đi production mà không bị phát hiện; kho không nhận đủ đơn mua hợp lệ. Nếu hệ thống chấp nhận 101 kg, tồn kho mô phỏng và số lượng đã nhận vượt đơn mua 1 kg. Nếu hệ thống chấp nhận 0 kg, phiếu nhận tồn tại nhưng không đại diện hàng nhận thực tế. Vì mỗi lỗi xuất phát tại ngưỡng, test biên là bằng chứng trực tiếp hơn test ngẫu nhiên.

Applied

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; toàn bộ dữ liệu dưới đây là dữ liệu tổng hợp, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ VND. Trạng thái tài liệu nguồn: IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Không có baseline, approval, quyết định vận hành hay xác nhận production.

Trường	Giá trị đầy đủ
Case ID	NOVA-BBT-EX-001
Chức năng	Ghi nhận xuất kho nguyên liệu cho lệnh sản xuất
Màn hình giả định	ERP > Sản xuất > Xuất nguyên liệu
Người dùng mô phỏng	WH_USER_01 — Nhân viên kho
Kho xuất	WH-RM-HCM — Kho nguyên liệu TP.HCM
Lệnh sản xuất	MO-2026-000184
Mã nguyên liệu	RM-SUGAR-001
Đơn vị tính	KG
Tồn khả dụng trước giao dịch	1,250.00 KG
Số lượng yêu cầu sản xuất	500.00 KG
Dữ liệu nhạy cảm	Không dùng dữ liệu cá nhân, khách hàng, tài chính thực tế

Facts

Fact ID	Sự kiện tổng hợp	Bằng chứng trong case
FACT-001	Người dùng nhập số lượng xuất kho.	Payload có trường issueQuantity.
FACT-002	Hệ thống biết tồn khả dụng của mã hàng tại kho.	Dữ liệu case ghi 1,250.00 KG.
FACT-003	Số lượng hợp lệ phải lớn hơn 0.	Xuất 0 KG không tạo chuyển động tồn kho có ý nghĩa.
FACT-004	Số lượng hợp lệ không vượt tồn khả dụng.	Xuất vượt tồn tạo tồn âm ngoài giả định case.
FACT-005	Mã lệnh sản xuất, kho và nguyên liệu phải tồn tại.	Payload dùng ba khóa nghiệp vụ.

Current Behavior

Hành vi hiện tại của case: hệ thống chỉ kiểm tra trường số lượng có phải số hay không. Hệ thống vẫn nhận 0, số âm và số lượng lớn hơn tồn khả dụng. Bằng chứng là ba payload sau đều nhận HTTP 201 Created trong mô phỏng hiện trạng.

Test ID	issueQuantity	Tồn khả dụng	Kết quả hiện tại mô phỏng	Lỗi nghiệp vụ
BBT-001	500.00	1,250.00	201 Created	Không
BBT-002	0.00	1,250.00	201 Created	Tạo giao dịch không có lượng xuất
BBT-003	-10.00	1,250.00	201 Created	Có thể tăng tồn kho khi xuất âm
BBT-004	1,250.01	1,250.00	201 Created	Có thể tạo tồn khả dụng âm

Underlying Need

Nhu cầu gốc: chặn dữ liệu đầu vào làm sai tồn kho trước khi ghi giao dịch. Cầu nối suy luận: FACT-003 loại 0 và số âm; FACT-004 giới hạn số lượng theo tồn khả dụng. Đây là nhu cầu kiểm thử hộp đen: kiểm tra đầu vào, đầu ra và quy tắc quan sát được; không suy đoán mã nguồn hay cấu trúc DB.

Rule Set

Rule ID	Quy tắc case mô phỏng	Phân loại nguồn	Trạng thái thẩm quyền
BR-NOVA-ISSUE-001	issueQuantity phải là số thập phân có tối đa 2 chữ số sau dấu phẩy.	Project assumption	Chưa được phê duyệt
BR-NOVA-ISSUE-002	issueQuantity phải lớn hơn 0.00.	Project assumption	Chưa được phê duyệt
BR-NOVA-ISSUE-003	issueQuantity không vượt availableQuantity của cùng warehouseCode và itemCode.	Project assumption	Chưa được phê duyệt
BR-NOVA-ISSUE-004	Khi vi phạm quy tắc, hệ thống không tạo chứng từ xuất kho.	Project assumption	Chưa được phê duyệt
BR-NOVA-ISSUE-005	Đơn vị tiền tệ VND không áp dụng cho số lượng kho; số lượng dùng UOM=KG.	Data-domain convention của case	Chưa được phê duyệt

Các ID BR-NOVA-ISSUE-* chỉ là ID case mô phỏng trong mục này. Chúng không thay thế nội dung hay ID đã được kiểm soát trong /01-curriculum/CANONICAL_BUSINESS_RULES.md.

Options And Decision Criteria

Option ID	Phương án	Ưu điểm	Hạn chế
OPT-001	Chỉ kiểm tra kiểu dữ liệu số.	Ít thay đổi.	Không chặn 0, số âm, vượt tồn.
OPT-002	Kiểm tra số lượng tại giao diện.	Phản hồi sớm cho người dùng.	API vẫn nhận dữ liệu sai nếu bị gọi trực tiếp.
OPT-003	Kiểm tra tại API trước khi tạo giao dịch; giao diện hiển thị lỗi từ API.	Bảo vệ mọi kênh gọi API; kết quả nhất quán.	Cần xác định rõ mã lỗi API.

Criterion ID	Tiêu chí	OPT-001	OPT-002	OPT-003
DC-001	Chặn số lượng <= 0	Không đạt	Đạt một phần	Đạt
DC-002	Chặn xuất vượt tồn	Không đạt	Đạt một phần	Đạt
DC-003	Bảo vệ API	Không đạt	Không đạt	Đạt
DC-004	Có thể kiểm thử hộp đen qua request/response	Đạt	Đạt một phần	Đạt

Khuyến nghị BA: chọn OPT-003, vì chỉ phương án này đạt đủ DC-001 đến DC-004. Đây là khuyến nghị phân tích, không phải quyết định đã được ủy quyền.

Decision: chưa có quyết định được ủy quyền. CHAPTER_MANIFEST, CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY đều ở IN_REVIEW; không có tham chiếu approval hoặc baseline.

Authority ID	Vai trò cần quyết định	Quyết định cần ghi nhận	Trạng thái
AUTH-BO-001	Business Owner mô phỏng	Xác nhận quy tắc xuất không vượt tồn.	Chưa ghi nhận
AUTH-ARCH-001	Solution Architect mô phỏng	Xác nhận điểm kiểm tra tại API.	Chưa ghi nhận
AUTH-QA-001	QA Lead mô phỏng	Xác nhận bộ test là đủ cho phạm vi.	Chưa ghi nhận

API Payload And Expected Responses

{
  "productionOrderCode": "MO-2026-000184",
  "warehouseCode": "WH-RM-HCM",
  "itemCode": "RM-SUGAR-001",
  "issueQuantity": 500.00,
  "uom": "KG",
  "transactionDateTime": "2026-08-07T09:15:00+07:00"
}

{
  "transactionCode": "ISS-2026-000731",
  "productionOrderCode": "MO-2026-000184",
  "warehouseCode": "WH-RM-HCM",
  "itemCode": "RM-SUGAR-001",
  "issueQuantity": 500.00,
  "uom": "KG",
  "availableQuantityBefore": 1250.00,
  "availableQuantityAfter": 750.00,
  "status": "POSTED"
}

{
  "errorCode": "ISSUE_QUANTITY_INVALID",
  "message": "Số lượng xuất phải lớn hơn 0.00 KG.",
  "field": "issueQuantity"
}

{
  "errorCode": "INSUFFICIENT_AVAILABLE_QUANTITY",
  "message": "Số lượng xuất 1250.01 KG vượt tồn khả dụng 1250.00 KG.",
  "field": "issueQuantity"
}

Black-Box Scenarios

Test ID	Kỹ thuật hộp đen	Input issueQuantity	Kết quả mong đợi	Rule trace
BBT-005	Phân vùng tương đương	500.00	HTTP 201; availableQuantityAfter=750.00; tạo transactionCode.	BR-NOVA-ISSUE-001 đến BR-NOVA-ISSUE-004
BBT-006	Giá trị biên	0.00	HTTP 422; ISSUE_QUANTITY_INVALID; không tạo chứng từ.	BR-NOVA-ISSUE-002, BR-NOVA-ISSUE-004
BBT-007	Phân vùng tương đương	-0.01	HTTP 422; ISSUE_QUANTITY_INVALID; không tạo chứng từ.	BR-NOVA-ISSUE-002, BR-NOVA-ISSUE-004
BBT-008	Giá trị biên	0.01	HTTP 201; tồn sau xuất 1,249.99 KG.	BR-NOVA-ISSUE-001 đến BR-NOVA-ISSUE-004
BBT-009	Giá trị biên	1,250.00	HTTP 201; tồn sau xuất 0.00 KG.	BR-NOVA-ISSUE-003, BR-NOVA-ISSUE-004
BBT-010	Giá trị biên	1,250.01	HTTP 422; INSUFFICIENT_AVAILABLE_QUANTITY; không tạo chứng từ.	BR-NOVA-ISSUE-003, BR-NOVA-ISSUE-004
BBT-011	Phân vùng tương đương	500.123	HTTP 422; lỗi định dạng số lượng; không tạo chứng từ.	BR-NOVA-ISSUE-001, BR-NOVA-ISSUE-004

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

flowchart TB
    A[WH_USER_01 nhập payload xuất kho<br/>issueQuantity] --> B{Tối đa 2 chữ số<br/>thập phân?}

    B -- Không --> F[HTTP 422: lỗi định dạng số lượng<br/>Không tạo chứng từ]
    B -- Có --> C{Lớn hơn<br/>0.00 KG?}

    C -- Không --> G[HTTP 422: ISSUE_QUANTITY_INVALID<br/>Không tạo chứng từ]
    C -- Có --> D{Không vượt<br/>availableQuantity?}

    D -- Không --> H[HTTP 422: INSUFFICIENT_AVAILABLE_QUANTITY<br/>Không tạo chứng từ]
    D -- Có --> I[Tạo chứng từ<br/>transactionCode]
    I --> J[Cập nhật tồn khả dụng]
    J --> K[HTTP 201: POSTED]

Artifact ID	Artifact	Đường dẫn kiểm soát	Mục đích truy vết	Trạng thái
CANONICAL_BUSINESS_RULES	Catalog quy tắc nghiệp vụ canonical	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Nơi phải đăng ký quy tắc nếu được chấp thuận sau này.	IN_REVIEW
CANONICAL_DATA_DICTIONARY	Từ điển dữ liệu logic canonical	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Nơi phải định nghĩa trường issueQuantity, availableQuantity, uom.	IN_REVIEW
TRACEABILITY_ID_REGISTRY	Registry ID canonical	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Nơi kiểm tra hoặc đăng ký ID chính thức.	IN_REVIEW
NOVA-BBT-EX-001	Worked example cục bộ	/02-handbook/19-black-box-testing-techniques-for-ba.md	Minh họa kỹ thuật kiểm thử hộp đen.	IN_REVIEW

Nếu chọn sai OPT-001 hoặc không kiểm thử BBT-006 đến BBT-010, hệ thống có thể ghi nhận xuất 0 KG, xuất âm hoặc xuất vượt tồn. Hậu quả là số liệu tồn kho mô phỏng sai, kế hoạch sản xuất dùng dữ liệu sai, và truy vết nguyên liệu bị giảm độ tin cậy. Đây là hệ quả nghiệp vụ suy ra từ FACT-003 và FACT-004, không phải kết luận tuân thủ pháp lý hay xác nhận vận hành thực tế.

9. Related Concepts & Dependencies

Core

Kiểm thử hộp đen phụ thuộc vào test basis: tập artifact mô tả hành vi mong đợi, không cần biết mã nguồn. BA không chép quy tắc, định nghĩa dữ liệu, hay ID vào chapter này. BA đặt liên kết đến nguồn canonical, vì một nội dung có nhiều bản sao sẽ tạo nhiều “sự thật”.

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: IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07, locale vi-VN, múi giờ Asia/Ho_Chi_Minh, tiền tệ mô phỏng VND.

Loại dependency	Nguồn canonical	Vai trò với kiểm thử hộp đen	Không làm trong chapter này
Quy tắc nghiệp vụ	CANONICAL_BUSINESS_RULES tại /01-curriculum/CANONICAL_BUSINESS_RULES.md	Cung cấp điều kiện hợp lệ, không hợp lệ, ngưỡng, kết quả mong đợi.	Viết lại hoặc tự xác nhận quy tắc Nova Foods.
Dữ liệu logic	CANONICAL_DATA_DICTIONARY tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md	Cung cấp nghĩa trường, kiểu dữ liệu, đơn vị đo, miền giá trị.	Đổi nghĩa issueQuantity, availableQuantity, uom.
ID bền vững	TRACEABILITY_ID_REGISTRY tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md	Kiểm tra ID artifact và ID truy vết trước khi liên kết.	Tự tạo ID canonical mới trong handbook.
Template	TEMPLATE_MANIFEST tại /01-curriculum/TEMPLATE_MANIFEST.md	Xác định template dự kiến cho test artifact.	Gọi template là đã tạo, baseline, hoặc approved.
Cấu trúc chapter	CHAPTER_MANIFEST tại /01-curriculum/CHAPTER_MANIFEST.md	Giữ filename và phạm vi chapter.	Đổi tên /02-handbook/19-black-box-testing-techniques-for-ba.md.

Applied

Facts: NOVA-BBT-EX-001 dùng dữ liệu tổng hợp về xuất nguyên liệu: issueQuantity, availableQuantity, uom; ví dụ chứng từ ISS-2026-000731.

Current Behavior: Ví dụ kiểm thử kiểm tra số lượng xuất lớn hơn 0.00 KG, có tối đa hai chữ số thập phân, và không vượt tồn khả dụng.

Underlying Need: Người đọc cần biết mỗi điều kiện kiểm thử lấy từ đâu, để phân biệt ví dụ học liệu với quy tắc nguồn.

Options: (1) chép toàn bộ quy tắc và định nghĩa dữ liệu vào chapter; (2) chỉ ghi ID nguồn; (3) ghi ID, đường dẫn canonical, và phạm vi sử dụng.

Decision Criteria: Không tạo nguồn sự thật thứ hai; giữ ID bền vững; người đọc tìm được nguồn; không tuyên bố approval hoặc baseline.

Decision: Chọn phương án 3. NOVA-BBT-EX-001 chỉ minh họa cách thiết kế kiểm thử; CANONICAL_BUSINESS_RULES giữ quy tắc; CANONICAL_DATA_DICTIONARY giữ nghĩa dữ liệu; TRACEABILITY_ID_REGISTRY giữ quyền kiểm soát ID.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết quản trị. Business Owner, QA, Architect, Legal, Accounting, Security không được thay thế bằng ví dụ handbook.

Artifact: /02-handbook/19-black-box-testing-techniques-for-ba.md, mục 9; liên kết đến ba artifact canonical nêu trên.

Consequence if Wrong: Chép quy tắc vào NOVA-BBT-EX-001 biến ví dụ thành bản sao cạnh tranh. Người đọc có thể kiểm thử theo câu chữ cũ dù catalog canonical đã khác.

Senior Lens

ID bền vững nhận diện đối tượng qua thời gian; filename nhận diện vị trí tệp. Hai thứ không thay thế nhau. Ví dụ, NOVA-BBT-EX-001 là ID ví dụ cục bộ; /02-handbook/19-black-box-testing-techniques-for-ba.md là vị trí chapter. Khi cần xác minh ID mới hoặc liên kết mới, kiểm tra TRACEABILITY_ID_REGISTRY trước. Không suy ra rằng ID đã đăng ký là requirement đã phê duyệt.

Chapter này liên kết đến mục 4 cho đầu vào, mục 5 cho hoạt động BA, mục 6 cho đầu ra, và mục 8 cho ví dụ chi tiết. Liên kết này là dependency học tập: kỹ thuật hộp đen cần requirement, business rule, acceptance condition và dữ liệu làm cơ sở. Nó không biến chapter thành nguồn canonical của requirement hay dữ liệu.

Quick Reference

Cần tham chiếu	Dùng	Lý do
Quy tắc kiểm thử	CANONICAL_BUSINESS_RULES	Một nơi giữ logic nghiệp vụ.
Tên và nghĩa trường	CANONICAL_DATA_DICTIONARY	Một nơi giữ mô hình dữ liệu logic.
ID mới hoặc ID nghi ngờ	TRACEABILITY_ID_REGISTRY	Tránh trùng, sai định dạng, sai chủ sở hữu.
Template test dự kiến	TEMPLATE_MANIFEST	Tránh tự đặt tên template.
Filename và phạm vi chapter	CHAPTER_MANIFEST	Giữ cấu trúc corpus ổn định.

Core

Traceability là khả năng lần ngược từ test case (TC, ca kiểm thử) đến nhu cầu nghiệp vụ và lần xuôi từ nhu cầu đến bằng chứng kiểm thử. Mỗi liên kết giữ nguyên ID đã đăng ký trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md; bảng này không tạo ID mới, không thay thế nguồn chân lý canonical, và không xác nhận Nova Foods mô phỏng đã được phê duyệt.

Liên kết	Nguồn canonical phải tham chiếu	Mục đích kiểm thử black-box	Bằng chứng cần có
NEED → REQ	NEED và REQ đã đăng ký trong TRACEABILITY_ID_REGISTRY	Chứng minh yêu cầu hệ thống phục vụ nhu cầu, không chỉ mô tả màn hình	ID NEED, ID REQ, quan hệ đã ghi nhận
REQ → BR	REQ trong registry; BR trong /01-curriculum/CANONICAL_BUSINESS_RULES.md	Xác định quy tắc nghiệp vụ tạo phân vùng tương đương hoặc giá trị biên	ID REQ, ID BR, điều kiện và kết quả mong đợi
REQ → AC	REQ và AC đã đăng ký trong registry	Biến yêu cầu thành tiêu chí chấp nhận có thể quan sát	ID REQ, ID AC, kết quả pass/fail
REQ/BR → DATA/API	REQ, BR trong registry; định nghĩa dữ liệu tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md; hợp đồng API tại artifact API được đăng ký	Xác định input, output, kiểu dữ liệu, mã lỗi và ràng buộc tích hợp	ID DATA hoặc API, trường dữ liệu, HTTP response nếu áp dụng
AC/DATA/API → TC	TC đã đăng ký trong registry	Chứng minh test case kiểm tra hành vi bên ngoài theo acceptance criteria (AC, tiêu chí chấp nhận)	ID AC, DATA/API, ID TC, expected result
TC → Test evidence	Kho bằng chứng test được đăng ký	Chứng minh kết quả chạy test, không suy diễn từ việc TC tồn tại	ID TC, thời điểm Asia/Ho_Chi_Minh, kết quả, bằng chứng tham chiếu

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

flowchart TB
    N[NEED đã đăng ký] --> R[REQ đã đăng ký]
    R --> B[BR canonical]
    R --> A[AC đã đăng ký]
    R --> D[DATA<br/>Data Dictionary canonical]
    B --> D
    R --> P[API<br/>Artifact API đã đăng ký]
    B --> P
    A --> T[TC đã đăng ký]
    D --> T
    P --> T
    T --> E[Test evidence]

Applied

Facts: Nova Foods Trading & Manufacturing là case mô phỏng giáo dục, dữ liệu tổng hợp, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07. Một TC kiểm tra tạo đơn bán hàng chỉ đáng tin khi truy được AC, quy tắc giá hoặc tồn kho nếu có, dữ liệu đầu vào, và API nếu luồng gọi tích hợp.

Current Behavior: BA ghi “kiểm tra tạo đơn thành công” trong TC nhưng không ghi NEED, REQ, BR, AC hay DATA/API. Bằng chứng chỉ cho biết màn hình hiển thị thành công.

Underlying Need: QA cần phân biệt lỗi UI với lỗi quy tắc, dữ liệu hoặc API. Suy luận: cùng một thông báo thành công không chứng minh hệ thống áp dụng đúng ràng buộc nghiệp vụ; vì vậy TC phải giữ liên kết đến test basis.

Options: (1) Liên kết TC trực tiếp với REQ. (2) Liên kết TC với AC, đồng thời nối AC về REQ và nối TC tới BR, DATA/API khi chúng ảnh hưởng expected result. (3) Sao chép toàn bộ rule và schema vào TC.

Decision Criteria: Không trùng nguồn canonical; truy ngược được nguyên nhân khi test fail; QA chạy test không phải đoán dữ liệu; thay đổi rule phát hiện được TC bị ảnh hưởng.

Decision: Chọn phương án (2). TC giữ các ID tham chiếu và expected result ngắn; nội dung đầy đủ của BR chỉ nằm tại /01-curriculum/CANONICAL_BUSINESS_RULES.md, dữ liệu logic chỉ nằm tại /01-curriculum/CANONICAL_DATA_DICTIONARY.md.

Authority: Principal IT Business Analyst / Technical Curriculum Author duy trì liên kết và metadata. Business Owner, QA, Architect, Security, Legal hoặc Accounting Owner xác nhận nội dung thuộc thẩm quyền của họ khi được kích hoạt. Không có approval hay baseline được suy ra từ bảng traceability.

Artifact: Ma trận traceability dùng cột NEED ID, REQ ID, BR ID, AC ID, DATA/API ID, TC ID, Expected Result, Evidence Reference, Status. Mỗi ô ID chỉ nhận chuỗi đã tồn tại trong TRACEABILITY_ID_REGISTRY.

Consequence if Wrong: TC có thể pass dù AC bị thiếu, rule sai, API trả dữ liệu sai kiểu, hoặc test dùng dữ liệu không hợp lệ. Đội dự án mất khả năng đánh giá phạm vi regression khi một REQ hoặc BR đổi.

Senior Lens

Liên kết không phải quan hệ một-một. Một NEED có thể dẫn đến nhiều REQ; một BR có thể chi phối nhiều AC và TC; một TC có thể kiểm tra nhiều AC chỉ khi expected result tách được pass/fail. Nếu một TC kiểm tra hai AC nhưng chỉ có một kết quả chung, lỗi không xác định được AC nào hỏng. Tách TC hoặc ghi bằng chứng riêng theo AC.

Không dùng ID để ngụ ý thẩm quyền. Liên kết BR → TC cho biết TC đang kiểm tra rule được tham chiếu; nó không xác nhận rule đúng pháp lý, kế toán, an toàn thực phẩm hay phù hợp production. Với dữ liệu cá nhân, thuế, kế toán, hóa đơn hoặc truy xuất thực phẩm, giữ nhãn Verification required cho đến khi owner có thẩm quyền xác minh nguồn chính thức.

Quick Reference

Quy tắc	Áp dụng
Không tạo ID trong handbook	Chỉ dùng ID đã đăng ký tại /01-curriculum/TRACEABILITY_ID_REGISTRY.md
Không sao chép canonical content	Tham chiếu CANONICAL_BUSINESS_RULES và CANONICAL_DATA_DICTIONARY
TC phải có test basis	Tối thiểu AC; thêm BR và DATA/API khi chúng đổi expected result
Không có liên kết, không có coverage claim	TC độc lập không chứng minh REQ hoặc AC được kiểm thử
IN_REVIEW không phải approved	Không gọi traceability là baseline, approval hoặc production-ready

Core

Lan truyền thay đổi là chuỗi tác động khi nguồn phụ thuộc đổi. Ví dụ, catalog quy tắc đổi ý nghĩa một điều kiện; requirement, acceptance criterion, dữ liệu kiểm thử và test case dùng điều kiện đó phải được xem lại. Lý do: các artifact sau không tự biết nguồn trước đã đổi.

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

flowchart TB
    A[Nguồn phụ thuộc thay đổi] --> B[Phân tích tác động]
    B --> C[Xem lại requirement và acceptance criterion]
    C --> D[Xem lại DATA/API và dữ liệu kiểm thử]
    D --> E[Xem lại test case]
    E --> F[Chạy lại test case]
    F --> G[Cập nhật bằng chứng truy vết]

Thay đổi im lặng là thay đổi không có version, lịch sử, liên kết tác động hoặc thông báo review. Nó phá vỡ tính truy vết: test case có thể vẫn chạy và đạt, nhưng đang chứng minh hành vi cũ. Kết quả “PASS” khi đó không chứng minh ERP Nova Foods mô phỏng đáp ứng nhu cầu hiện hành.

Applied

Mục	Nội dung
Facts	/01-curriculum/CANONICAL_DATA_DICTIONARY.md đổi định nghĩa logic của trường ngày hết hạn lô hàng trong Nova Foods mô phỏng. Dữ liệu là tổng hợp.
Current Behavior	Test case đang dùng dữ liệu ngày cũ và kiểm tra hệ thống chấp nhận hoặc từ chối theo định nghĩa cũ.
Underlying Need	Giữ liên kết đúng giữa nguồn dữ liệu canonical, requirement, acceptance criterion và bằng chứng kiểm thử.
Options	Giữ test cũ; sửa test trực tiếp; hoặc ghi nhận thay đổi tại nguồn canonical rồi phân tích toàn bộ liên kết bị ảnh hưởng.
Decision Criteria	Có lịch sử thay đổi; giữ ID hiện hữu; xác định artifact bị ảnh hưởng; không tự tạo quy tắc nghiệp vụ mới; có người đúng thẩm quyền xem xét khi thay đổi liên quan pháp lý, kế toán, an toàn thực phẩm hoặc bảo mật.
Decision	Dùng nguồn canonical làm điểm bắt đầu. Đánh dấu test case và dữ liệu kiểm thử là cần review, không kết luận pass hoặc fail theo định nghĩa cũ.
Authority	Principal IT Business Analyst / Technical Curriculum Author duy trì traceability. Business Owner, Data Owner, QA, Architect, Legal, Accounting hoặc Security xác nhận phần thuộc thẩm quyền họ khi cần.
Artifact	Ghi thay đổi và phạm vi tác động trong /01-curriculum/CANONICAL_DATA_DICTIONARY.md; đối chiếu ID trong /01-curriculum/TRACEABILITY_ID_REGISTRY.md.
Consequence if Wrong	Test vẫn xanh nhưng kiểm tra sai định nghĩa ngày hết hạn. Báo cáo chất lượng, dữ liệu tích hợp và quyết định phát hành có thể dựa trên bằng chứng không còn hợp lệ.

Senior Lens

Không sửa TC trước rồi coi thay đổi đã xử lý. Cách đó chỉ che đứt gãy giữa nguồn và bằng chứng. Trình tự an toàn: xác định artifact canonical đổi gì, so sánh ý nghĩa trước và sau, tìm tất cả liên kết bị ảnh hưởng, rồi quyết định từng liên kết cần sửa, ngừng dùng, hay giữ nguyên với lý do ghi nhận.

Nếu /01-curriculum/CANONICAL_BUSINESS_RULES.md đổi mà REQ, AC hoặc test data không được rà soát, lỗi thường không nằm ở câu lệnh test. Lỗi nằm ở test basis, tức cơ sở mà kiểm thử dựa vào. Theo thuật ngữ ISTQB, black-box testing kiểm tra hành vi từ đặc tả; đặc tả đổi im lặng làm oracle kiểm thử, tức tiêu chí kết luận đúng hoặc sai, trở nên cũ.

IN_REVIEW, v0.9.0, ngày 2026-08-07 không phải baseline hay approval. Vì vậy, thay đổi trong corpus hiện tại phải được ghi nhận như thay đổi đang xem xét; không được gọi là quy tắc Nova Foods đã phê duyệt hoặc cấu hình ERP production.

Quick Reference

Dấu hiệu	Cái gì hỏng	Hành động tối thiểu
Nguồn canonical đổi ID hoặc ý nghĩa	Liên kết traceability trỏ sai hoặc mơ hồ	Giữ ID ổn định nếu ý nghĩa còn cùng đối tượng; nếu không, ghi quan hệ thay thế trong registry
Business rule đổi	Requirement và AC có thể kiểm tra sai	Rà soát mọi requirement và AC tham chiếu rule
Data/API đổi kiểu, miền giá trị hoặc bắt buộc nhập	Test data, contract test và TC lỗi thời	Đối chiếu dữ liệu test với nguồn dữ liệu/API hiện hành
TC đổi nhưng nguồn không đổi	Bằng chứng test có thể tự diễn giải yêu cầu	Kiểm tra TC có vượt quá canonical source không
Không có lịch sử thay đổi	Không xác định được phạm vi tác động	Dừng kết luận chất lượng; lập impact analysis trước khi chạy lại test

10. Common Mistakes & Anti-patterns

Core

Black-box testing kiểm tra hành vi quan sát được từ bên ngoài hệ thống, dựa trên test basis, tức requirement, business rule, acceptance criteria hoặc đặc tả giao diện/API. Lỗi phổ biến không phải chỉ là viết sai test case; lỗi thường bắt đầu khi nhóm chọn sai hoặc thiếu cơ sở kiểm thử.

Sai lầm	Dấu hiệu quan sát được	Nguyên nhân gốc	Hành động sửa
Chỉ kiểm tra luồng thành công	TC chỉ có dữ liệu hợp lệ; không có dữ liệu biên, sai định dạng hoặc thiếu trường bắt buộc	Người mới đồng nhất “chạy được” với “đúng”	Dùng equivalence partitioning, tức chia nhóm dữ liệu được kỳ vọng xử lý giống nhau, và boundary value analysis, tức kiểm tra sát ngưỡng
Viết TC từ màn hình thay vì rule	TC ghi “bấm Lưu thấy thông báo” nhưng không nêu điều kiện nghiệp vụ	Nhầm UI với hành vi cần xác minh	Liên kết TC tới REQ, AC hoặc rule canonical trước khi chọn bước UI
Dùng dữ liệu ngẫu nhiên	Giá trị test không nêu ý nghĩa; kết quả không tái lập	Không lập test data có kiểm soát	Ghi rõ input, trạng thái trước test, expected result và mã dữ liệu tổng hợp
Gộp nhiều điều kiện trong một TC	Một TC đổi đồng thời số lượng, đơn giá, quyền và trạng thái đơn	Không cô lập biến kiểm tra	Tách mỗi điều kiện quyết định thành TC riêng; chỉ gộp khi cần xác minh tương tác đã được nêu trong test basis
Đóng TC khi hệ thống “trông hợp lý”	Expected result dùng từ “đúng”, “hợp lệ”, “hiển thị bình thường”	Không có oracle kiểm thử, tức tiêu chí xác định pass/fail	Thay bằng kết quả đo được: trạng thái, giá trị, thông báo, bản ghi hoặc phản hồi API cụ thể
Bỏ qua trạng thái trước test	TC không nói đơn hàng đang Draft, Confirmed hay Cancelled	Nhóm xem dữ liệu như dữ liệu tĩnh; ERP là hệ thống có trạng thái	Ghi precondition và trạng thái đầu vào; kiểm tra chuyển trạng thái hợp lệ, không chỉ trường dữ liệu
QA tự suy diễn rule còn thiếu	TC tự đặt ngưỡng, quyền hoặc công thức chưa có nguồn	Áp lực tiến độ thay thế quyết định có thẩm quyền	Ghi gap, liên kết nguồn hiện có, chuyển Business Owner hoặc owner phù hợp xác nhận; không biến giả định thành expected result

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

flowchart TB
    A[Test basis có nguồn truy vết] --> B[Chọn kỹ thuật black-box]
    B --> C[Thiết kế TC, expected result và dữ liệu tổng hợp]
    C --> D[Liên kết TC tới REQ, AC hoặc rule canonical]
    D --> E{Expected result có oracle?}
    E -- Có --> F[Chạy test]
    F --> G[Ghi Pass hoặc Fail]
    E -- Không --> H[Ghi gap và nguồn hiện có]
    H --> I[Chuyển Business Owner hoặc owner phù hợp xác nhận]
    I --> J{Rule hoặc expected result đã xác nhận?}
    J -- Có --> C
    J -- Không --> K[Dừng kết luận]

Applied

Facts: Nova Foods là case mô phỏng giáo dục, dùng dữ liệu tổng hợp. Nhóm tạo TC cho chức năng nhập số lượng dòng đơn bán hàng. TC duy nhất dùng số lượng 10 và kết luận Pass khi hệ thống lưu được đơn.

Current Behavior: Hệ thống mô phỏng lưu đơn với 10. Không có TC cho 0, số âm, số thập phân, trường trống hoặc giá trị vượt ngưỡng nếu ngưỡng được đặc tả.

Underlying Need: Cần chứng minh hệ thống xử lý từng nhóm input theo test basis, không chỉ chứng minh một input hợp lệ được lưu.

Options:
1. Giữ TC 10 và kết luận chức năng đạt.
2. Bổ sung các nhóm dữ liệu nhưng tự đặt giới hạn tối đa.
3. Giữ TC 10, tìm REQ hoặc AC quy định miền giá trị; chỉ thiết kế test biên khi nguồn nêu giới hạn.

Decision Criteria: Expected result phải truy được nguồn; dữ liệu phải tái lập; mỗi TC phải cô lập điều kiện chính; không tự tạo business rule.

Decision: Chọn phương án 3. TC 10 chỉ xác minh một lớp hợp lệ. Nếu test basis chưa nêu giá trị nhỏ nhất, lớn nhất hoặc có cho phép số thập phân hay không, ghi gap thay vì tự tạo TC pass/fail cho các ngưỡng đó.

Authority: Business Owner xác nhận ý nghĩa nghiệp vụ của số lượng; QA xác nhận kỹ thuật test và bằng chứng; Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì traceability học liệu. Không có approval được ghi nhận tại IN_REVIEW, v0.9.0, ngày 2026-08-07.

Artifact: Ghi gap và liên kết nguồn trong /01-curriculum/CANONICAL_BUSINESS_RULES.md hoặc requirement canonical liên quan; TC chỉ tham chiếu ID đã tồn tại trong TRACEABILITY_ID_REGISTRY.

Consequence if Wrong: Nếu tự đặt “số lượng tối đa 999”, nhóm có thể báo Fail cho hành vi chưa từng được yêu cầu hoặc bỏ sót lỗi thật tại ngưỡng do Business Owner quy định.

Warning: Không chạy test destructive trên dữ liệu thật để bù cho test basis thiếu. Với Nova Foods mô phỏng, chỉ dùng dữ liệu tổng hợp. Khi nguồn chưa đủ, ranh giới khôi phục an toàn là dừng kết luận Pass/Fail cho điều kiện thiếu nguồn, giữ bằng chứng đã chạy, rồi mở gap để làm rõ.

Senior Lens

Senior BA nhận diện lỗi qua bằng chứng, không qua cảm giác. TC có 20 bước vẫn yếu nếu expected result không truy về requirement hoặc rule. Ngược lại, TC ngắn nhưng có input, precondition, nguồn kỳ vọng và kết quả quan sát được thì có thể review, chạy lại và audit.

Delivery team hay nhầm số lượng TC với độ phủ. Bằng chứng là 30 TC có thể cùng kiểm tra một luồng hợp lệ, trong khi không TC nào kiểm tra dữ liệu rỗng hoặc chuyển trạng thái bị cấm. Sửa bằng coverage map theo điều kiện và lớp dữ liệu, không bằng tăng số TC vô hướng.

Quick Reference

Kiểm tra trước khi viết TC	Đạt khi
Hành vi cần test có nguồn	Có ID requirement, AC, rule hoặc đặc tả được kiểm soát
Input có ý nghĩa	Giá trị đại diện lớp dữ liệu hoặc biên đã được nguồn xác định
Expected result đo được	Có trạng thái, giá trị, thông báo, bản ghi hoặc HTTP response cụ thể
Điều kiện được cô lập	Một TC xác minh một quyết định chính
Dữ liệu tái lập	Có precondition và dữ liệu tổng hợp xác định
Nguồn còn thiếu	Ghi gap; không suy diễn rule hoặc kết luận chất lượng

Core

Cảnh báo — rủi ro thật: Test case sai có thể cho kết quả “Pass” nhưng che mất lỗi chặn xuất kho, lập hóa đơn hoặc truy vết lô. Với Nova Foods là case mô phỏng, dữ liệu tổng hợp, không dùng kết quả này cho vận hành hoặc tuân thủ thực tế.

Black-box testing kiểm tra hành vi nhìn thấy từ đầu vào và đầu ra, không suy đoán mã nguồn. Cảnh báo chỉ dùng khi lỗi có thể gây quyết định sai, mất dữ liệu, sai tiền, lộ dữ liệu hoặc mất khả năng truy vết. Lỗi câu chữ, căn lề, tên cột không nhất thiết cần cảnh báo nếu không ảnh hưởng quyết định hay dữ liệu.

Tình huống rủi ro	Ví dụ lỗi Nova Foods mô phỏng	Ranh giới phục hồi an toàn
Test nhầm môi trường	Tester tạo phiếu xuất OUT-SIM-260807-01 trên môi trường có dữ liệu dùng chung rồi xóa tay	Dừng tạo giao dịch mới; khoanh vùng ID, người thao tác, thời gian; dùng quy trình hoàn tác được hệ thống hỗ trợ; không sửa trực tiếp DB
Dùng dữ liệu thật	Đưa số điện thoại khách hàng thật vào test API tạo đơn hàng	Dừng sử dụng dữ liệu; xóa theo quy trình được thẩm quyền phê duyệt; thay bằng dữ liệu tổng hợp; báo Security/Privacy Owner để đánh giá sự cố
“Pass” sai do test data	Test tồn kho 0 nhưng dữ liệu setup còn 15 thùng lô LOT-SIM-APPLE-01	Không kết luận Pass; ghi nhận trạng thái BLOCKED; làm sạch hoặc tạo bộ dữ liệu tách biệt; chạy lại cùng test case
Hoàn tác sai nghiệp vụ	Xóa chứng từ mô phỏng để sửa kết quả thay vì dùng giao dịch đảo	Không tự suy diễn cách đảo chứng từ; giữ bằng chứng; chuyển Accounting Owner hoặc Business Owner xác định cách phục hồi mô phỏng

Applied

Facts: Nova Foods mô phỏng có test case TC-OUT-014: khi số lượng xuất lớn hơn tồn khả dụng của lô, ERP phải từ chối xác nhận xuất kho. Tester nhập lô LOT-SIM-MANGO-260801, tồn hiển thị 20, số lượng xuất 25, đơn vị thùng.

Current Behavior: Màn hình trả thông báo thành công và tạo phiếu OUT-SIM-260807-01. Báo cáo tồn sau đó hiển thị -5 thùng.

Underlying Need: Ngăn xuất vượt tồn khả dụng và giữ số lượng lô nhất quán giữa màn hình xuất kho, sổ tồn và báo cáo truy vết.

Options:

Phương án	Lợi ích	Rủi ro
Gắn cảnh báo, báo Fail, giữ giao dịch lỗi làm bằng chứng	Bảo toàn dấu vết lỗi	Dữ liệu test bị nhiễm nếu không cô lập
Sửa trực tiếp số tồn trong DB	Nhanh bề ngoài	Phá bằng chứng, che lỗi, vượt thẩm quyền
Xóa phiếu xuất rồi chạy lại ngay	Làm sạch nhanh	Có thể mất bằng chứng và không biết hệ thống đã đồng bộ đâu
Dừng test, ghi nhận lỗi, dùng hoàn tác được hỗ trợ	Bảo toàn bằng chứng và dữ liệu	Cần phối hợp owner

Decision Criteria: Có nguy cơ số tồn âm; lỗi ảnh hưởng giao dịch kho; chưa có bằng chứng phiếu đã hay chưa đồng bộ sang thành phần khác; không có thẩm quyền tự sửa dữ liệu.

Decision: Gắn cảnh báo; ghi TC-OUT-014 = Fail; lưu request, response, ảnh màn hình, thời điểm 2026-08-07 theo Asia/Ho_Chi_Minh; dừng test phụ thuộc lô này. Chỉ hoàn tác bằng chức năng hệ thống được xác định cho môi trường test, sau khi xác định phạm vi đồng bộ.

Authority: QA Lead xác nhận kết quả test; Business Owner xác nhận hành vi nghiệp vụ mong muốn; Architect xác định phạm vi tích hợp; không vai trò nào được suy diễn thành phê duyệt production. Nếu có tác động kế toán, Accounting Owner xác định cách phục hồi. Đây là dữ liệu tổng hợp của Nova Foods mô phỏng.

Artifact: Ghi liên kết từ TC-OUT-014 tới test basis và defect record trong artifact kiểm soát; giữ nguyên Artifact ID, filename và trạng thái IN_REVIEW, version v0.9.0. Không gọi kết quả là baseline hoặc approval.

Consequence if Wrong: Nếu coi lỗi là cảnh báo thấp và tiếp tục test, các test sau có thể dùng tồn -5, tạo chuỗi Pass/Fail không còn đáng tin. Nếu sửa DB, đội giao không thể phân biệt lỗi sản phẩm với lỗi dữ liệu test.

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

flowchart TB
    A["TC-OUT-014 tạo tồn âm<br/>Tồn 20, xuất 25, báo cáo -5 thùng"] --> B{"Có tồn âm, ảnh hưởng giao dịch kho,<br/>sai truy vết hoặc chưa rõ phạm vi đồng bộ?"}

    B -->|"Có: tình huống này"| C["QA Lead xác nhận TC-OUT-014 = Fail<br/>Gắn cảnh báo, dừng test phụ thuộc lô"]
    B -->|"Không"| X["Ghi defect hoặc quan sát<br/>theo mức ảnh hưởng"]

    C --> D["Lưu request, response, ảnh màn hình<br/>Thời điểm 2026-08-07, Asia/Ho_Chi_Minh"]
    D --> E["Liên kết TC-OUT-014 với test basis<br/>và defect record trong artifact kiểm soát"]
    E --> P["Giữ nguyên Artifact ID, filename<br/>Trạng thái IN_REVIEW, version v0.9.0<br/>Không gọi baseline hoặc approval"]
    P --> F["Business Owner xác nhận<br/>hành vi nghiệp vụ mong muốn"]
    F --> G["Architect xác định phạm vi tích hợp<br/>và trạng thái đồng bộ"]
    G --> H{"Có tác động kế toán?"}

    H -->|"Có"| I["Accounting Owner xác định<br/>cách phục hồi"]
    H -->|"Không"| J{"Có chức năng hoàn tác được hỗ trợ<br/>trong môi trường test?"}
    I --> J

    J -->|"Có"| K["Hoàn tác trong môi trường test<br/>bằng chức năng hệ thống đã xác định"]
    K --> L["Tạo dữ liệu tổng hợp sạch<br/>và chạy lại test"]
    J -->|"Không"| M["Giữ cảnh báo, tiếp tục dừng test phụ thuộc<br/>Không tự sửa hoặc xóa dữ liệu"]

    C -.-> N["Nếu tiếp tục test với tồn -5<br/>chuỗi Pass/Fail sau không còn đáng tin"]
    C -.-> O["Không sửa trực tiếp DB<br/>Phá bằng chứng, che lỗi, vượt thẩm quyền"]
    C -.-> Q["Không xóa phiếu rồi chạy lại ngay<br/>Có thể mất bằng chứng, chưa rõ đồng bộ"]

    F -.-> R["Ranh giới quyền hạn<br/>Không xác nhận nào là phê duyệt production"]
    G -.-> R
    I -.-> R

Senior Lens

Ranh giới phục hồi là điểm dừng trước khi hành động sửa chữa làm mất bằng chứng hoặc tạo dữ liệu mới không kiểm soát. Suy luận: phiếu OUT-SIM-260807-01 đã được tạo, nên hệ thống đã đổi trạng thái ít nhất tại màn hình hoặc dịch vụ xử lý; chưa có bằng chứng toàn bộ tác động chỉ nằm một nơi. Vì vậy, “xóa cho sạch” không an toàn hơn hoàn tác có truy vết.

Không dùng cảnh báo để tăng trọng lượng cho ý kiến chưa kiểm chứng. Ví dụ, câu “ERP phải khóa xuất kho theo luật” là khẳng định thẩm quyền không có bằng chứng trong test case. Cách ghi đúng: “Hành vi khóa xuất vượt tồn là nhu cầu mô phỏng đang được kiểm tra; nguồn pháp lý hoặc quy tắc nghiệp vụ áp dụng cần Verification required bởi owner có thẩm quyền.”

Quick Reference

Dùng cảnh báo khi	Không dùng cảnh báo khi	Hành động tối thiểu
Có thể mất, sai hoặc lộ dữ liệu	Lỗi trình bày không đổi dữ liệu hay quyết định	Ghi quan sát hoặc defect theo mức ảnh hưởng
Có thể tạo số tiền, tồn kho hoặc trạng thái sai	Tester chưa thích màu nút hoặc thứ tự cột	Nêu tiêu chí kiểm tra cụ thể
Có thể phá truy vết lô, chứng từ hoặc bằng chứng test	Chưa có đủ dữ liệu để kết luận rủi ro	Đặt BLOCKED, bổ sung dữ liệu test
Phục hồi cần sửa DB, xóa giao dịch, hoặc vượt quyền	Có chức năng hoàn tác có kiểm soát trong môi trường test	Giữ bằng chứng, xác định owner, hoàn tác có truy vết

Core

Sai sót phải tách theo loại vì cách sửa khác nhau. Mơ hồ là câu có nhiều cách hiểu hợp lệ; không đầy đủ là thiếu điều kiện hoặc dữ liệu cần để kiểm thử; khẳng định thẩm quyền không có bằng chứng là gán trạng thái quyết định, phê duyệt, pháp lý hoặc baseline khi artifact không ghi nhận; dùng sai ký pháp là gọi sơ đồ hay ký hiệu bằng tên chuẩn không đúng; đứt truy vết là không nối được test với nguồn requirement, rule hoặc quyết định.

Loại lỗi	Red flag quan sát được	Nguyên nhân gốc	Sửa an toàn
Mơ hồ	“Hệ thống xử lý đơn lớn nhanh”	Không định nghĩa “lớn”, “nhanh”, kết quả	Ghi ngưỡng, thời điểm đo, kết quả mong đợi, ngoại lệ
Không đầy đủ	Test chỉ có dữ liệu hợp lệ	BA quên biên, dữ liệu rỗng, quyền, trạng thái trước	Bổ sung phân vùng tương đương, giá trị biên, tiền điều kiện
Thẩm quyền không có bằng chứng	Ghi “đã được Finance phê duyệt” nhưng không có approval reference	Nhầm trao đổi miệng, review, IN_REVIEW với phê duyệt	Đổi thành “Verification required”; nêu owner cần xác nhận
Dùng sai ký pháp	Gọi Mermaid flowchart là BPMN	Nhầm công cụ vẽ với chuẩn notation	Gắn đúng nhãn “Mermaid flowchart”; chỉ gọi BPMN khi dùng BPMN 2.0.2
Đứt truy vết	Test ID không có Requirement ID, Rule ID hoặc nguồn quyết định	Test viết độc lập, không dùng traceability matrix	Liên kết lại nguồn canonical; dừng claim coverage nếu nguồn chưa rõ

[!WARNING] Rủi ro thật: ghi APPROVED, BASELINED, hoặc “tuân thủ pháp luật” cho artifact IN_REVIEW có thể làm team triển khai theo giả định sai. v0.9.0 ngày 2026-08-07 chưa có baseline hay approval reference. Chỉ sửa nhãn và traceability trong phạm vi học liệu; không tự tạo quyết định nghiệp vụ, pháp lý, kế toán hay production.

Applied

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

Mục	Nội dung
Facts	Test case TC-ORD-017 ghi: “Đơn bán giá trị cao phải được duyệt.” Không có mức VND, vai trò duyệt, trạng thái đơn, nguồn rule, hay quyết định được ghi nhận.
Current Behavior	Tester tạo một test với đơn 50.000.000 VND, kỳ vọng “hiện màn hình duyệt”. Test không xác định giá trị biên, ai duyệt, hoặc hành vi khi không đủ quyền.
Underlying Need	Cần test basis đủ xác định để kiểm tra quyết định duyệt đơn, không biến giả định của tester thành business rule.
Options	A: tự chọn ngưỡng 50.000.000 VND; B: đánh dấu thiếu nguồn và chỉ kiểm thử luồng hiện có; C: truy về CANONICAL_BUSINESS_RULES và TRACEABILITY_ID_REGISTRY, yêu cầu Business Owner xác nhận rule.
Decision Criteria	Có Rule ID canonical; có ngưỡng và toán tử so sánh; có role; có trạng thái trước/sau; có authority ghi nhận; không mâu thuẫn IN_REVIEW.
Decision	Chọn C. Đặt TC-ORD-017 trạng thái không đủ test basis. Không kết luận pass hoặc fail cho rule duyệt.
Authority	Business Owner xác nhận rule nghiệp vụ. Principal IT Business Analyst / Technical Curriculum Author chỉ duy trì liên kết và nhãn xác minh.
Artifact	/01-curriculum/CANONICAL_BUSINESS_RULES.md; /01-curriculum/TRACEABILITY_ID_REGISTRY.md; test artifact chứa liên kết nguồn, không sao chép rule chưa xác minh.
Consequence if Wrong	Ngưỡng tự đặt có thể chặn đơn hợp lệ hoặc bỏ lọt đơn cần duyệt; báo cáo test tạo cảm giác coverage giả.

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

flowchart TB
    A["TC-ORD-017"] --> B{"Có Rule ID trong<br/>CANONICAL_BUSINESS_RULES<br/>và TRACEABILITY_ID_REGISTRY?"}

    B -- Không --> M["Không đủ test basis<br/>Không kết luận pass hoặc fail<br/>Không sao chép rule chưa xác minh"]
    B -- Có --> C{"Có ngưỡng VND và<br/>toán tử so sánh?"}

    C -- Không --> M
    C -- Có --> D{"Có vai trò duyệt?"}

    D -- Không --> M
    D -- Có --> E{"Có authority ghi nhận<br/>quyết định duyệt đơn?"}

    E -- Không --> M
    E -- Có --> F{"Có trạng thái đơn<br/>trước và sau quyết định?"}

    F -- Không --> M
    F -- Có --> G{"Trạng thái trước/sau hoặc rule<br/>có mâu thuẫn IN_REVIEW?"}

    G -- Có --> M
    G -- Không --> H{"Có hành vi xác định khi<br/>người dùng không đủ quyền duyệt?"}

    H -- Không --> M
    H -- Có --> I{"Business Owner đã xác nhận<br/>rule nghiệp vụ?"}

    I -- Không --> M
    I -- Có --> J["Thiết kế test biên, phân vùng<br/>và ngoại lệ không đủ quyền"]

    J --> K["Principal IT Business Analyst /<br/>Technical Curriculum Author<br/>duy trì liên kết và nhãn xác minh"]
    K --> L["Test artifact liên kết<br/>CANONICAL_BUSINESS_RULES và<br/>TRACEABILITY_ID_REGISTRY"]

    M --> N["Yêu cầu Business Owner<br/>bổ sung hoặc xác nhận rule"]
    N --> O{"Rule đã đủ basis<br/>và được xác nhận?"}
    O -- Có --> B
    O -- Chưa --> P["Giữ TC-ORD-017 ở trạng thái<br/>không đủ test basis"]

    M -. "Nếu vẫn tự đặt ngưỡng<br/>hoặc kết luận coverage" .-> R["Rủi ro:<br/>coverage giả<br/>chặn đơn hợp lệ<br/>bỏ lọt đơn cần duyệt"]

Senior Lens

Không sửa mơ hồ bằng cách đoán ý. Ví dụ, “đơn giá trị cao” chỉ thành điều kiện kiểm thử khi nguồn nêu rõ công thức giá trị đơn, tiền tệ VND, ngưỡng, toán tử > hoặc >=, và thời điểm đánh giá. Không sửa thiếu đầy đủ bằng cách thêm câu chữ đẹp; phải bổ sung đúng biến làm thay đổi kết quả test.

Không dùng tên người họp, email không kiểm soát, hay ghi chú không có reference làm bằng chứng authority. “Finance đã nói” là nguồn tham khảo, không phải approval. Nếu nội dung liên quan thuế, 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, giữ nhãn Verification required cho đến khi owner có thẩm quyền xác nhận theo nguồn chính thức.

Notation cũng là traceability. Mermaid diagram có thể giải thích luồng kiểm tra, nhưng không chứng minh tuân thủ BPMN. Test case có link đến sơ đồ nhưng thiếu Requirement ID hoặc Rule ID vẫn là đứt truy vết: sơ đồ mô tả cách hiểu, không thay nguồn quyết định.

Quick Reference

Kiểm tra trước khi chốt test	Đạt khi
Một câu, một nghĩa	Thuật ngữ, ngưỡng, thời điểm, actor, kết quả rõ
Đủ điều kiện	Có tiền điều kiện, input, expected result, ngoại lệ cần thiết
Thẩm quyền đúng	Không ghi approval, baseline, legal compliance khi không có reference
Ký pháp đúng	Tên sơ đồ khớp chuẩn hoặc công cụ đã dùng
Truy vết kín	Test liên kết được nguồn canonical và quyết định liên quan
Phạm vi phục hồi	Chỉ sửa nhãn, link, test basis; escalation khi cần quyết định nghiệp vụ hoặc chuyên môn

11. Senior BA Notes & Rules of Thumb

Senior Lens

Kỹ thuật kiểm thử hộp đen giúp tìm hành vi sai từ góc nhìn input và output; nó không tự chứng minh yêu cầu đúng, đầy đủ, hợp pháp hay đã được phê duyệt. Senior BA tách hai quyết định: chọn test nào dựa trên rủi ro và test basis, với quy tắc nào đúng dựa trên nguồn canonical và owner có thẩm quyền. Bằng chứng “đã chạy test pass” chỉ hỗ trợ kết luận rằng hệ thống khớp expected result đã ghi; không biến expected result thành quy tắc nghiệp vụ hợp lệ.

Tình huống Nova Foods mô phỏng	Trade-off	Cách đánh giá bằng chứng	Thẩm quyền quyết định
QA muốn test toàn bộ tổ hợp chiết khấu, kho và kênh bán	Bao phủ cao tốn thời gian; test chọn lọc có thể bỏ sót tương tác	So sánh số tổ hợp với phân vùng tương đương, giá trị biên, mức rủi ro và dữ liệu lỗi cũ nếu có	QA Lead quyết định chiến lược test; Business Owner xác nhận ưu tiên rủi ro nghiệp vụ
Sales muốn chấp nhận đơn vượt hạn mức “để không mất khách”	Doanh thu ngắn hạn đối nghịch kiểm soát tín dụng	Cần Rule ID canonical nêu hạn mức, actor có quyền override, thời điểm kiểm tra và audit trail	Business Owner quyết định chính sách; Accounting Owner xác nhận tác động kế toán; BA không tự chọn
Finance nói số tiền phải làm tròn khác expected result	Test pass theo công thức cũ có thể sai về nghiệp vụ	Ghi công thức, số chữ số thập phân, điểm làm tròn, dữ liệu VND, nguồn và trạng thái xác minh	Accounting Owner quyết định diễn giải; BA giữ nhãn Verification required nếu chưa có xác nhận
Nhóm kỹ thuật đề xuất bỏ kiểm tra input để tăng tốc API	Hiệu năng đối nghịch an toàn và toàn vẹn dữ liệu	Cần đặc tả API, loại dữ liệu, lỗi dự kiến, quyền truy cập và đánh giá Security/Architect	Architect và Security quyết định thiết kế; BA không đổi expected result để hợp mã hiện có

Heuristic review: test case đáng tin khi mỗi expected result truy được về requirement, business rule, quyết định được ghi nhận, hoặc assumption được gắn nhãn. Nếu test chỉ dùng câu “người dùng thấy hợp lý”, bằng chứng là ý kiến; không đủ để khóa expected result. Nếu test dùng ảnh chụp màn hình không có input, thời điểm, môi trường và nguồn rule, bằng chứng chỉ hỗ trợ tái hiện giao diện; không đủ để kết luận logic đúng.

Red flag xuất hiện khi một stakeholder yêu cầu đổi expected result nhưng không chỉ được nguồn canonical; cùng một input có hai expected result; rule dùng từ mơ hồ như “lớn”, “nhanh”, “khẩn”; hoặc test data chứa dữ liệu cá nhân, tài khoản thật, hóa đơn thật. Nova Foods là case mô phỏng giáo dục, chỉ dùng dữ liệu tổng hợp. Senior BA dừng việc chuẩn hóa test khi thay đổi có thể thành quyết định thuế, kế toán, dữ liệu cá nhân, an toàn thực phẩm, truy xuất nguồn gốc, bảo mật hoặc kiến trúc.

Ngưỡng escalation	Lý do	Gói BA cần ghi
Hai owner có thẩm quyền đưa kết luận khác nhau	Đây là xung đột quyết định, không phải lỗi viết test	Input, expected result đang tranh chấp, nguồn từng bên, tác động, câu hỏi quyết định
Thiếu ngưỡng, toán tử, thời điểm hoặc actor override	Không thể tạo test biên có kết quả xác định	Khoảng trống rule, test bị chặn, ví dụ dữ liệu tổng hợp, owner cần trả lời
Điều chỉnh làm thay đổi tiền, nghĩa vụ pháp lý, quyền truy cập hoặc khả năng truy xuất	Rủi ro vượt thẩm quyền BA và QA	Requirement/rule liên quan, phạm vi ảnh hưởng, nhãn Verification required, owner chuyên môn
Lỗi production-like được báo nhưng không tái hiện được từ test basis	Không đủ bằng chứng để sửa rule hay đóng lỗi	Dấu vết hiện có, điều kiện còn thiếu, dữ liệu cần thu thập, giới hạn kết luận

Quy tắc thông thường “ưu tiên boundary value analysis” không áp dụng riêng lẻ khi đầu ra phụ thuộc nhiều điều kiện liên kết, như quyền người dùng, trạng thái đơn và thời điểm chốt sổ. Khi đó, chỉ test biên từng trường có thể bỏ sót lỗi tương tác; kết hợp với decision table hoặc state transition testing nếu test basis nêu rõ điều kiện. Ngược lại, không tăng số test vì “cẩn thận” khi rule chỉ có một điều kiện độc lập và rủi ro thấp; thêm tổ hợp không có reasoning bridge làm giảm khả năng review.

Senior BA ghi khuyến nghị theo dạng: “Dựa trên CANONICAL_BUSINESS_RULES đang IN_REVIEW, expected result hiện chưa đủ để xác định hành vi tại ngưỡng. Khuyến nghị giữ test ở trạng thái blocked và yêu cầu Business Owner xác nhận toán tử cùng thời điểm đánh giá. Đây không phải xác nhận quy tắc Nova Foods.” Cách ghi này nêu rõ bằng chứng, giới hạn và hành động tiếp theo; không biến suy đoán thành chắc chắn, baseline hay approval.

Senior Lens

Senior BA review test đen hộp dựa trên bằng chứng, không dựa trên số lượng test case. Quy tắc thường dùng: mỗi điều kiện nghiệp vụ quan trọng phải liên kết được với test basis, dữ liệu test và kết quả mong đợi; nếu không liên kết được thì coverage chỉ là tuyên bố. Test basis là nguồn dùng để suy ra kiểm thử, như business rule, acceptance criteria, mockup hoặc API contract. Với Nova Foods Trading & Manufacturing mô phỏng, mọi số liệu VND, mã đơn hàng và vai trò dưới đây là dữ liệu tổng hợp.

Heuristic review	Bằng chứng tối thiểu cần thấy	Red flag	Ngưỡng escalation	Ngoại lệ không áp dụng quy tắc thường
Ưu tiên theo rủi ro	Ma trận nêu ảnh hưởng tiền, an toàn thực phẩm, dữ liệu cá nhân, vận hành và xác suất lỗi	Nhóm test chọn theo màn hình dễ test thay vì rủi ro	Escalate khi luồng có thể ghi nhận sai VND, lộ dữ liệu cá nhân hoặc mất truy vết lô hàng	Proof of concept nội bộ không ghi dữ liệu thật có thể dùng coverage hẹp, nhưng phải ghi rõ giới hạn
Kiểm tra biên trước giá trị giữa miền	Rule, miền dữ liệu, giá trị nhỏ nhất, lớn nhất và sát biên	Chỉ có test “hợp lệ” như số lượng 10, thiếu 0, -1, giới hạn tối đa	Escalate khi không xác định được biên từ nguồn canonical hoặc các bên cho biên khác nhau	Không suy đoán biên kỹ thuật nếu API contract hoặc data dictionary chưa xác định; ghi Verification required
Tách lỗi yêu cầu khỏi lỗi phần mềm	Test case chỉ ra requirement ID hoặc nguồn test basis	Tester báo “hệ thống sai” nhưng expected result không có nguồn	Escalate khi expected result mâu thuẫn giữa /01-curriculum/CANONICAL_BUSINESS_RULES.md và tài liệu khác	Không ép QA chọn một cách hiểu để kịp chạy test; giữ defect hoặc question ở trạng thái cần quyết định
Kiểm tra phân vùng tương đương	Lý do các giá trị trong cùng nhóm được xem là xử lý giống nhau	Một giá trị đại diện cho nhóm nhưng không nêu điều kiện nhóm	Escalate khi phân vùng thay đổi quyền, giá, thuế, kho hoặc trạng thái đơn	Không gộp nhóm chỉ vì cùng kiểu dữ liệu; cùng là số nguyên không có nghĩa cùng business behavior
Đối chiếu quyền và trạng thái	Vai trò, trạng thái trước/sau, thao tác được phép và bị chặn	Case chỉ test happy path của người có quyền cao	Escalate khi thao tác vượt quyền có thể sửa chứng từ, xem dữ liệu cá nhân hoặc bỏ qua kiểm soát	Không kết luận compliance từ một test pass; cần Security, Legal hoặc Compliance xác minh theo thẩm quyền
Giữ kết quả tái lập được	Test data, thời điểm Asia/Ho_Chi_Minh, môi trường và expected result đủ để chạy lại	“Pass” không có dữ liệu đầu vào hoặc ảnh chụp không truy được nguồn	Escalate khi kết quả phụ thuộc cấu hình không được ghi nhận hoặc dữ liệu test bị thay đổi	Không dùng dữ liệu production để tái lập trong corpus; dùng dữ liệu tổng hợp và ghi giới hạn

Ví dụ review: test case ghi “đơn bán SO-SYN-001 có tổng tiền âm phải bị từ chối”. Senior BA không kết luận rule này đúng chỉ vì trực giác. Cầu nối suy luận là: tổng tiền âm có ảnh hưởng ghi nhận doanh thu mô phỏng; do đó đây là rủi ro cao. Nhưng nếu /01-curriculum/CANONICAL_BUSINESS_RULES.md chưa có rule về credit note hoặc điều chỉnh âm, expected result “bị từ chối” chưa có nguồn. Hành động đúng là ghi Verification required, liên kết case với khoảng trống rule, rồi escalation đến Business Owner và Accounting Owner mô phỏng. BA không tự biến giả định thành rule.

Escalate ngay, không chờ hết vòng test, khi có một trong các điều kiện: hai nguồn canonical mâu thuẫn; một test yêu cầu diễn giải pháp lý, kế toán, thuế, bảo mật hoặc an toàn thực phẩm; lỗi có thể làm mất dấu vết lô hàng; expected result phụ thuộc quyền truy cập chưa được xác định; hoặc thay đổi test data làm thay đổi kết quả tài chính mô phỏng. Senior BA chuẩn bị gói escalation gồm ID test, nguồn đang mâu thuẫn, dữ liệu tổng hợp, kết quả quan sát, tác động, câu hỏi cần quyết định và vai trò có thẩm quyền. IN_REVIEW tại v0.9.0 ngày 2026-08-07 không phải approval, baseline hay quyền tự quyết.

Senior Lens

Senior BA không biến thiếu bằng chứng thành khẳng định. Khuyến nghị có thể được đưa ra khi chưa đủ chắc chắn, nhưng phải tách rõ: fact (sự kiện có bằng chứng), assumption (giả định dự án), unknown (điều chưa biết), và decision (quyết định thuộc thẩm quyền). Cầu nối suy luận phải nhìn thấy được: bằng chứng nào dẫn tới rủi ro nào, rủi ro nào khiến khuyến nghị phù hợp.

Ví dụ Nova Foods Trading & Manufacturing là case mô phỏng, dữ liệu tổng hợp. Test case kiểm tra ERP chặn tạo phiếu xuất kho khi số lượng yêu cầu lớn hơn tồn khả dụng. Kết quả thử cho thấy API trả HTTP 400, nhưng không có requirement canonical hay acceptance criteria xác nhận mã lỗi, thông báo người dùng, hoặc cách xử lý đơn hàng giao một phần. Senior BA không ghi “hệ thống đã đúng nghiệp vụ”. Ghi nhận: hành vi hiện tại chỉ chứng minh phản hồi tại dữ liệu thử; chưa chứng minh phù hợp quy tắc nghiệp vụ.

Trường ghi nhận	Nội dung defensible
Phạm vi kiểm tra	Chức năng tạo phiếu xuất kho, dữ liệu tổng hợp Nova Foods, trạng thái corpus IN_REVIEW, phiên bản v0.9.0, ngày 2026-08-07
Fact	Với tồn khả dụng 100 đơn vị và yêu cầu xuất 120 đơn vị, API trả HTTP 400; bằng chứng là request, response, thời điểm chạy test theo Asia/Ho_Chi_Minh
Unknown	Chưa có nguồn canonical xác nhận có cho phép giao một phần, backorder, hay bắt buộc chặn toàn bộ
Assumption	Nhóm test tạm giả định chặn vượt tồn là hành vi an toàn hơn việc âm tồn; đây không phải quy tắc Nova Foods đã được xác nhận
Rủi ro	Nếu nghiệp vụ cho phép giao một phần, test đang gắn nhãn lỗi sai; nếu nghiệp vụ cấm âm tồn, response hiện tại vẫn chưa đủ chứng minh thông báo và audit trail đạt yêu cầu
Khuyến nghị	Giữ kết quả là INCONCLUSIVE; tạo điểm làm rõ cho Business Owner xác định chính sách xuất thiếu hàng; sau đó cập nhật test basis và chạy lại
Thẩm quyền cần quyết định	Business Owner quyết định chính sách phục vụ đơn hàng; Architect xác nhận hợp đồng API; QA quyết định trạng thái test sau khi test basis đủ
Giới hạn tuyên bố	Không suy diễn yêu cầu pháp lý, kế toán, thuế, an toàn thực phẩm hay compliance từ một response API

Câu chữ nên nêu mức tin cậy và điều kiện đảo chiều. Mẫu ghi: “Dựa trên response HTTP quan sát được và chưa có quy tắc canonical trong CANONICAL_BUSINESS_RULES, khuyến nghị không đóng lỗi là Passed hoặc Failed. Khuyến nghị Business Owner xác nhận chính sách giao thiếu hàng. Nếu chính sách cho phép giao một phần, cần thay đổi expected result; nếu chính sách cấm xuất vượt tồn, cần bổ sung tiêu chí kiểm tra thông báo, mã lỗi và truy vết.”

Khuyến nghị defensible không cần giả vờ chắc chắn. Nó cần đủ dấu vết để người có thẩm quyền kiểm tra lại: nguồn bằng chứng, dữ liệu thử, giới hạn, người quyết định cần thiết, và hậu quả nếu giả định sai. Không ghi approval, baseline, compliance, hay production-ready khi các trạng thái đó chưa có tham chiếu được ghi nhận.

12. Associated Template Reference & Completed Artifact

Core

Template là biểu mẫu chuẩn để ghi dữ liệu test nhất quán. Với kỹ thuật kiểm thử hộp đen, template phải giữ được liên kết từ test condition, test data, expected result đến evidence. Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp, không đại diện ERP thật.

Không tự tạo ID template hoặc tên tệp mới. Bằng chứng: TEMPLATE_MANIFEST là nguồn kiểm soát danh mục template dự kiến; nguồn được cung cấp chưa nêu template test cụ thể cho chapter này. Vì vậy BA chỉ được tham chiếu artifact canonical đã có, rồi yêu cầu đăng ký template trước khi dùng biểu mẫu mới.

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

flowchart TB
    A[Test basis] --> B{Template canonical đã có?}
    F[TEMPLATE_MANIFEST] --> B

    B -->|Có| C[Template canonical được phép dùng]
    B -->|Chưa có| D[BA yêu cầu đăng ký template]
    D --> E[Chưa được dùng template]
    E --> J[Template được đăng ký]
    J --> C

    C --> G[Test case hộp đen]
    G --> H[Evidence thực thi]
    H --> I[Kết quả và traceability]
    K[TRACEABILITY_ID_REGISTRY] --> I

Applied

Thành phần	Nội dung
Facts	Chapter dạy equivalence partitioning, boundary value analysis, decision table, state transition và use case testing. Nguồn đầu vào xác nhận có TEMPLATE_MANIFEST, TRACEABILITY_ID_REGISTRY, CANONICAL_BUSINESS_RULES, CANONICAL_DATA_DICTIONARY.
Current Behavior	Corpus đang IN_REVIEW, version v0.9.0, ngày 2026-08-07. Chưa có baseline, approval, hoặc template test ID/file cụ thể trong nguồn được cấp.
Underlying Need	Learner cần biết dùng artifact nào để ghi test case mà không biến ví dụ học liệu thành yêu cầu ERP hay quyết định production.
Options	Dùng template test chưa đăng ký; tự tạo file local; dùng artifact canonical như nguồn tham chiếu và chờ template được đăng ký.
Decision Criteria	Giữ đúng ID, filename, source boundary; truy vết được; không tạo approval ngầm định; không bịa template canonical.
Decision	Chỉ map artifact canonical có bằng chứng. Không xác nhận template test cụ thể khi TEMPLATE_MANIFEST chưa cung cấp ID và đường dẫn template đó.
Authority	Principal IT Business Analyst / Technical Curriculum Author quản trị manifest. QA Reviewer xác nhận tính đủ của test artifact. Business Owner xác nhận quy tắc nghiệp vụ. Architect xác nhận API hoặc integration behavior.
Artifact	/01-curriculum/TEMPLATE_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	Dùng ID tự đặt làm đứt traceability; gọi assumption là rule làm sai expected result; gọi IN_REVIEW là approved làm sai trạng thái quản trị.

Senior Lens

Quality gate là điểm kiểm soát trước khi artifact được dùng làm test basis. Gate không xác nhận nghiệp vụ đúng; gate chỉ xác nhận evidence, ID, nguồn và thẩm quyền đủ để review. Ví dụ, expected result “chặn xuất vượt tồn” chỉ hợp lệ khi liên kết tới rule canonical đã có hoặc được gắn Verification required; HTTP response quan sát được không tự biến thành business rule.

Không dùng CANONICAL_BUSINESS_RULES để tự diễn giải kế toán, thuế, pháp lý, an toàn thực phẩm hoặc quyền riêng tư. Nếu test chạm các miền này, giữ nhãn Verification required và chuyển người có thẩm quyền phù hợp. IN_REVIEW nghĩa là đang xem xét có kiểm soát, không phải BASELINED, APPROVED, compliant, hay production-ready.

Quick Reference

Associated ID	File canonical	Phân loại nguồn	Dùng khi	Không dùng khi	Owner	Consumer	Quality gate
TEMPLATE_MANIFEST	/01-curriculum/TEMPLATE_MANIFEST.md	Controlled planning artifact; manifest template dự kiến	Cần kiểm tra template ID, filename, phạm vi và trạng thái đăng ký	Cần lấy business rule, expected result, hoặc kết luận test	Principal IT Business Analyst / Technical Curriculum Author	BA Author, QA Reviewer, Curriculum Reviewer	ID và filename phải tồn tại trong manifest; không tự đặt biến thể
TRACEABILITY_ID_REGISTRY	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical identifier registry plan	Cần kiểm tra format và quan hệ ID giữa requirement, rule, data, test	Cần tạo ID ngoài registry hoặc thay thẩm quyền quyết định	Principal IT Business Analyst / Technical Curriculum Author	BA, QA Reviewer, Architect	Không trùng ID; liên kết nguồn-trường đích truy được
CANONICAL_BUSINESS_RULES	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Canonical rule catalog plan	Cần xác định rule làm test basis và expected result	Rule chưa được xác nhận hoặc thuộc legal, accounting, tax	Principal IT Business Analyst / Technical Curriculum Author; nội dung cần Business Owner hoặc owner chuyên môn xác nhận	BA, QA Reviewer, Business Owner	Rule ID còn nguyên; assumption và Verification required không bị đổi thành rule
CANONICAL_DATA_DICTIONARY	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Canonical logical data dictionary plan	Cần xác định field, domain, datatype, boundary test data	Cần suy ra schema triển khai, API contract, hoặc dữ liệu production	Principal IT Business Analyst / Technical Curriculum Author; Architect xác nhận chi tiết kỹ thuật	BA, QA Reviewer, Architect	Field reference đúng ID; test data tổng hợp; boundary có bằng chứng
CHAPTER_MANIFEST	/01-curriculum/CHAPTER_MANIFEST.md	Authoritative chapter manifest	Cần kiểm tra title, filename, dependency và phạm vi chapter	Cần thay đổi cấu trúc chapter không qua governance	Principal IT Business Analyst / Technical Curriculum Author	Handbook Author, Curriculum Reviewer	Chapter giữ đúng 12 H2 blueprint; không đổi slug hoặc filename
00_SOURCE_MAP	/00-research/00_SOURCE_MAP.md	Controlled research and source mapping artifact	Cần kiểm tra nguồn chuẩn cho thuật ngữ black-box testing, như ISTQB CTFL	Cần bịa page, clause, hoặc tuyên bố tuân thủ	Principal IT Business Analyst / Technical Curriculum Author	BA Author, QA Reviewer	Nêu đúng source boundary; không diễn giải vượt phạm vi nguồn

Template test case cụ thể: chưa có ID và filename canonical trong nguồn đầu vào. Không dùng file tự tạo như template chính thức. Chỉ dùng sau khi được đăng ký trong TEMPLATE_MANIFEST và liên kết được với TRACEABILITY_ID_REGISTRY.

Quick Reference

Nova Foods Trading & Manufacturing là case mô phỏng giáo dục; mọi dữ liệu là tổng hợp. Tra cứu trước khi dùng test case nhằm giữ test basis, quy tắc, dữ liệu và ID cùng một nguồn. IN_REVIEW, v0.9.0, ngày 2026-08-07 không phải baseline hay phê duyệt.

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

flowchart TB
    A[Đọc test case] --> B{Đủ input, precondition,<br/>expected result quan sát được,<br/>nguồn rule hoặc requirement,<br/>dữ liệu tổng hợp, canonical ID?}

    B -- Không --> V[Verification required<br/>Không bù bằng giả định]
    B -- Có --> C[Tra requirement hoặc rule<br/>theo canonical ID]

    C --> D[Đối chiếu nguồn canonical nội bộ:<br/>manifest, ID registry, business rules,<br/>data dictionary]
    D --> T[Tra nguồn thuật ngữ khi cần:<br/>source map hoặc ISTQB]
    T --> E{Canonical ID giữ nguyên?}

    E -- Không --> V
    E -- Có --> F[Đối chiếu định nghĩa dữ liệu:<br/>tên trường, kiểu, trạng thái, giá trị biên]

    F --> G{Nguồn rule có nhãn<br/>IN_REVIEW?}
    G -- Có --> H[Dùng làm test basis, ghi trạng thái nguồn<br/>Không coi là nghĩa vụ vận hành]
    G -- Không --> I[Kiểm tra bằng chứng baseline hoặc phê duyệt riêng]

    H --> J[Kiểm tra expected result<br/>khớp rule hoặc requirement]
    I --> K{Có bằng chứng baseline<br/>hoặc phê duyệt riêng?}

    K -- Không --> L[Không coi là nghĩa vụ vận hành<br/>hoặc bằng chứng phê duyệt]
    K -- Có --> J

    L --> J
    J --> M[Trace link ghi canonical ID không biến thể<br/>và trạng thái nguồn]
    M --> N[Test case có nguồn, dữ liệu,<br/>expected result và trace link kiểm tra được]

    O[IN_REVIEW, v0.9.0, 2026-08-07<br/>không đủ chứng minh baseline hoặc phê duyệt] -.-> I

Mục cần tra trong chapter	Vị trí tra cứu	Điều phải khớp	Lý do
Khái niệm black-box testing	Mục 1	Thuật ngữ kiểm thử hộp đen: kiểm tra hành vi từ input và expected result, không dựa code	Tránh viết test case theo cấu trúc nội bộ chưa được cung cấp
Lý do dùng kỹ thuật	Mục 2	Rủi ro nghiệp vụ và loại lỗi mục tiêu	Kỹ thuật phải phục vụ rủi ro, không chọn theo thói quen
Lifecycle	Mục 3	Test basis đến test case, thực thi, ghi nhận kết quả	Xác định test case chưa phải bằng chứng pass
Input	Mục 4	Requirement, acceptance criteria, business rule, data, interface contract	Thiếu đầu vào thì expected result là suy đoán
BA activities	Mục 5	Bước phân vùng, biên, bảng quyết định, trạng thái, cặp đôi	Kiểm tra kỹ thuật đã áp dụng đúng loại rule
Output	Mục 6	Test condition, test case, test data, trace link, defect evidence	Phân biệt điều kiện test với test case hoàn chỉnh
Người dùng output	Mục 7	BA, QA, Developer, Business Owner theo vai trò được mô tả	Không gán quyền xác nhận nghiệp vụ cho người chỉ thực thi test
Artifact đã điền	/02-handbook/19-black-box-testing-techniques-for-ba.md, mục 8 Detailed Worked Example	Facts, Current Behavior, Underlying Need, Options, Decision Criteria, Decision, Authority, Artifact, Consequence if Wrong	Đây là vị trí artifact Nova Foods đã điền trong chapter; không có tệp template riêng được xác nhận trong micro-batch này
Dependency	/01-curriculum/CHAPTER_MANIFEST.md	Đường dẫn chapter, trạng thái, version, case-study boundary	Manifest là nguồn kiểm soát cấu trúc chapter
ID và traceability	/01-curriculum/TRACEABILITY_ID_REGISTRY.md	Canonical ID phải giữ nguyên, không tự tạo biến thể	ID sai làm đứt liên kết requirement–test
Business rule	/01-curriculum/CANONICAL_BUSINESS_RULES.md	Rule được viện dẫn phải giữ nhãn IN_REVIEW và nguồn	Rule chưa baseline không thành nghĩa vụ vận hành
Dữ liệu logic	/01-curriculum/CANONICAL_DATA_DICTIONARY.md	Tên trường, kiểu dữ liệu, trạng thái, giá trị biên	Giá trị test chỉ hợp lệ khi khớp định nghĩa dữ liệu
Nguồn thuật ngữ kiểm thử	/00-research/00_SOURCE_MAP.md; ISTQB CTFL Syllabus v4.0.1	Thuật ngữ kỹ thuật kiểm thử hộp đen	Không suy diễn định nghĩa chuẩn ngoài source boundary

Checklist hoàn tất khi từng test case trong mục 8 có: input cụ thể, precondition, expected result quan sát được, nguồn rule hoặc requirement, dữ liệu tổng hợp, và canonical ID không biến thể. Nếu thiếu một mục, đánh dấu Verification required; không bù bằng giả định hoặc gọi artifact là đã phê duyệt.

Core

Tự rà soát liên tệp là đối chiếu nội dung chapter với artifact canonical trước handoff. Mục tiêu: phát hiện sai ID, sai đường dẫn, suy diễn rule, hoặc gọi IN_REVIEW là đã phê duyệt. Nova Foods Trading & Manufacturing là case mô phỏng; mọi dữ liệu là tổng hợp; v0.9.0 ngày 2026-08-07, vi-VN, Asia/Ho_Chi_Minh, VND.

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

flowchart TB
    A["/02-handbook/19-black-box-testing-techniques-for-ba.md"] --> B["Đối chiếu ID, path, status, version"]
    C["CHAPTER_MANIFEST"] --> B
    D["TRACEABILITY_ID_REGISTRY"] --> B
    E["CANONICAL_BUSINESS_RULES"] --> B
    F["CANONICAL_DATA_DICTIONARY"] --> B
    B --> G{"Có mâu thuẫn hoặc suy diễn?"}
    G -->|Không| H["Ghi kết quả review; handoff IN_REVIEW chưa phải phê duyệt"]
    G -->|Có| I["Ghi issue, giữ nhãn Verification required"]
    I --> J["Escalation đúng owner"]

Applied

Trường	Nội dung
Facts	Chapter dùng kỹ thuật black-box testing, gồm Equivalence Partitioning và Boundary Value Analysis. Upstream xác nhận mọi artifact đang IN_REVIEW, v0.9.0, chưa baseline, chưa approval.
Current Behavior	Bản chapter có thể tham chiếu rule, data field, hoặc test case Nova Foods mà không kiểm tra artifact canonical.
Underlying Need	Test condition phải truy ngược được về requirement, rule hoặc data definition. Nếu không có nguồn canonical, test chỉ là giả định học liệu.
Options	1. Giữ test như fact Nova Foods. 2. Xóa test. 3. Giữ test, gắn project assumption hoặc Verification required, mở issue.
Decision Criteria	Không đổi canonical ID; không biến giả định thành rule; không tạo approval ngầm định; owner chuyên môn nhận đúng loại quyết định.
Decision	Chọn 3. Giữ ví dụ để dạy kỹ thuật, nhưng ghi rõ mô phỏng và trạng thái cần xác minh.
Authority	Principal IT Business Analyst / Technical Curriculum Author điều phối traceability. Business Owner xác nhận ý nghĩa nghiệp vụ. QA Owner xác nhận test coverage. Legal Owner, Accounting Owner, Security Owner, Architect xác nhận phần thuộc thẩm quyền riêng.
Artifact	/02-handbook/19-black-box-testing-techniques-for-ba.md, liên kết /01-curriculum/CHAPTER_MANIFEST.md, /01-curriculum/TRACEABILITY_ID_REGISTRY.md, /01-curriculum/CANONICAL_BUSINESS_RULES.md, /01-curriculum/CANONICAL_DATA_DICTIONARY.md.
Consequence if Wrong	Test case có thể kiểm tra rule không tồn tại, bỏ sót boundary thật, hoặc bị hiểu nhầm là hướng dẫn ERP production hay nghĩa vụ pháp lý.

Senior Lens

Kiểm tra liên tệp	Bằng chứng cần thấy	Kết quả hiện tại	Owner escalation
Status và version	Mọi tham chiếu giữ IN_REVIEW, v0.9.0, ngày 2026-08-07	Pass nếu không có APPROVED, BASELINED, production-ready	Principal IT Business Analyst / Technical Curriculum Author
ID và filename	ID, path khớp artifact canonical	Verification required vì batch không chứa registry đầy đủ	Principal IT Business Analyst / Technical Curriculum Author
Business rule test basis	Mỗi expected result có rule canonical hoặc nhãn giả định	Open issue: chưa có rule ID cụ thể trong batch	Business Owner; Principal IT Business Analyst / Technical Curriculum Author
Data boundary	Giá trị biên có field, datatype, domain rõ	Open issue: chưa xác định field canonical cho ví dụ	Data Owner; Principal IT Business Analyst / Technical Curriculum Author
Legal, accounting, food safety	Không diễn đạt giả định thành nghĩa vụ	Verification required nếu ví dụ chạm dữ liệu cá nhân, hóa đơn, truy xuất thực phẩm	Legal Owner; Accounting Owner; Compliance Owner
API, security, architecture	Không suy diễn HTTP contract, quyền truy cập, integration behavior	Verification required nếu test API hoặc phân quyền	Security Owner; Architect
Test adequacy	Partition, boundary, expected result, negative case truy vết được	Verification required trước dùng làm test basis	QA Owner

Không handoff như nội dung hoàn tất khi còn issue có thể đổi rule, data boundary, expected result, hoặc authority. Handoff chỉ chuyển gói review IN_REVIEW; không xác nhận baseline, approval, compliance, hay quyền dùng production.

Quick Reference

Open issues trước handoff

Issue ID	Vấn đề	Tác động	Escalation owner	Điều kiện đóng
ISS-19-BBT-001	Chưa có canonical business-rule ID cho expected result ví dụ	Không chứng minh được oracle test	Business Owner	Rule được xác nhận hoặc ví dụ gắn project assumption
ISS-19-BBT-002	Chưa có field/domain canonical cho boundary values	Boundary test có thể sai miền dữ liệu	Data Owner	CANONICAL_DATA_DICTIONARY có field, datatype, allowed range
ISS-19-BBT-003	Chưa có QA review về coverage partition âm và dương	Thiếu test condition	QA Owner	QA Owner ghi nhận kết quả review trong artifact kiểm soát
ISS-19-BBT-004	Bất kỳ ví dụ liên quan hóa đơn, dữ liệu cá nhân, truy xuất thực phẩm chưa được xác minh nguồn hiện hành	Rủi ro diễn giải pháp lý sai	Legal Owner; Accounting Owner; Compliance Owner	Kết luận chuyên môn được ghi nhận; hoặc ví dụ bị giới hạn là giả định

Verification-required items: đối chiếu exact ID với /01-curriculum/TRACEABILITY_ID_REGISTRY.md; đối chiếu rule với /01-curriculum/CANONICAL_BUSINESS_RULES.md; đối chiếu field và boundary với /01-curriculum/CANONICAL_DATA_DICTIONARY.md; đối chiếu chapter scope với /01-curriculum/CHAPTER_MANIFEST.md. Principal IT Business Analyst / Technical Curriculum Author lập gói handoff, giữ traceability và không thay thế quyết định của owner chuyên môn.