Test-Passing Illusion

Derived Failure Pattern của Proxy Validation và False Confidence

Summary

Test-Passing Illusion là Failure Pattern trong đó
test success hoặc operational confirmation trong verification environments
được coi như nó đảm bảo system correctness hoặc safety.

Điều mà Pattern này đề cập không phải là hiệu quả của tests hoặc staging environments bản thân.
Nó mô tả một cấu trúc trong đó success dưới các điều kiện hạn chế
che khuất assumptions và expectations mà ban đầu nên được xác minh,
tạo ra false confidence.

Context

Automated tests và verification environments
là các yếu tố thiết yếu trong phát triển hiện đại.

Unit tests, integration tests, CI,
và hơn nữa operational confirmation trong staging environments
đảm bảo sự an toàn của các thay đổi đến một mức độ nhất định.

Tuy nhiên, khi những confirmations này
chỉ được đánh giá bởi "liệu chúng có pass hay không,"
phạm vi của verification và assumptions trở nên khó làm rõ ràng.

Forces

Các động lực chính tạo ra Pattern này như sau:

Simplification of verification results
Bởi vì test results được hiển thị như nhị phân (success/failure),
các assumptions của chúng dễ dàng bị bỏ qua.
Trust in confirmation work
Càng nhiều tests và staging environments được phát triển,
càng nhiều lòng tin quá mức được đặt vào kết quả của chúng.
Time constraints
Trong thời gian hạn chế,
không có lựa chọn nào khác ngoài sử dụng "sự thật nó đã pass" như vật liệu decision.
Absence or ambiguity of specifications
Khi điều nên được thỏa mãn để đúng không được làm rõ ràng,
test success trở thành de facto specifications.

Failure Mode

Bằng cách coi verification results như proxy indicators,
judgment của correctness phụ thuộc vào các điều kiện hạn chế.

Kết quả là, các dạng hỏng sau đây tiến hành đồng thời:

Assumptions không được chia sẻ
Các điều kiện được giả định bởi tests và staging không được làm rõ ràng,
và sự khác biệt từ production trở nên khó nhận ra.
Expectations nổi lên sau thực tế
Chỉ sau release,
expectations của "nó nên hoạt động như thế này ban đầu" xuất hiện.
Success và safety được đánh đồng
Sự thật rằng errors không xảy ra
được coi như cơ sở cho system correctness và safety.

Consequences

Thất bại có xu hướng xảy ra dưới các điều kiện production-specific
(Part I: What Breaks — Boundary / Operation)
Verification conditions không thể giải thích khi các vấn đề xảy ra, và các quyết định dừng lại
(Part I: What Breaks — Responsibility / Boundary)
Lòng tin vào verification environments trở nên quá mức, và learning không tiến bộ
(Part II: Why It Breaks — Broken Learning Loop)
AI và auto-generated code có xu hướng bị nhận nhầm là an toàn
Bởi vì chỉ verification results được sử dụng như decision material,
assumptions và constraints trở nên khó xem xét.
(Part II: Why It Breaks — Context Erosion)

Countermeasures

Sau đây không phải là danh sách các giải pháp,
mà là các counter-patterns để chuyển trục của judgment chống lại Failure Mode.

Làm rõ ràng điều nằm ngoài phạm vi của verification
Làm hiển thị điều mà tests và staging không đảm bảo,
và trả lại ý nghĩa của success về các điều kiện hạn chế.
Xử lý assumptions và success riêng biệt
Phân tách satisfied conditions và assumptions được đặt một cách ngầm định,
và ngăn các quyết định được nhị phân hóa.
Định vị verification results như một phần của observation
Coi success/failure như input thay vì conclusion,
và kết nối với các quyết định bổ sung và learning.

Resulting Context

Tests và verification environments tiếp tục đóng các vai trò quan trọng,
nhưng chúng được coi như các confirmation means dưới các điều kiện hạn chế.

Correctness được đánh giá không phải bởi một verification result duy nhất,
mà bao gồm assumptions, expectations, và operational conditions.

Kết quả là, tests được định vị
không phải như vật liệu an tâm,
mà là observation means hỗ trợ learning.

Appendix: Conceptual References

Feedback, Measurement & Learning
Background của các cấu trúc trong đó verification results không dẫn đến learning hoặc decision updating.
Requirements & Knowledge
Background của các cấu trúc trong đó test results được coi như proxy specifications trong khi điều nên được thỏa mãn để đúng không được cố định như specifications.
Information Hiding & Boundaries
Background của các cấu trúc trong đó test conditions và assumptions không được làm rõ ràng như boundaries,
và sự khác biệt từ production conditions được làm vô hình.

Appendix: References

W. Edwards Deming, Out of the Crisis, 1982.
Pamela Zave, Michael Jackson, Four Dark Corners of Requirements Engineering, 1997.
Gojko Adzic, Specification by Example: How Successful Teams Deliver the Right Software, 2011.

Summary​

Context​

Forces​

Failure Mode​

Consequences​

Countermeasures​

Resulting Context​

See also​

Appendix: Conceptual References​

Appendix: References​