Khi cần xem lại verification

“Quý trước đã thử” có thể đúng nhưng chưa đủ. Verification ghi hành vi trong điều kiện cụ thể; điều kiện đổi có thể khiến tính áp dụng hiện tại chưa rõ.

Giữ kết quả ban đầu

Giữ claim, scenario, environment, dependency, evidence và kết quả. Thời gian trôi qua không biến bài thử thành công thành failure.

Verified · Stale nghĩa là scenario đã được verify lúc đó và evidence cần review hôm nay. Điều này chưa chứng minh hệ thống hiện tại lỗi.

Xem giả định đã thay đổi

Xem topology, version, capacity, traffic shape, access, data volume và external service. Retry policy có thể đổi load propagation; queue có thể đổi recovery order; payment integration có thể đổi reconciliation.

Nối thay đổi với flow và claim bị ảnh hưởng. Không vô hiệu mọi record hoặc xem code diff nhỏ là bằng chứng hành vi nghiệp vụ không đổi.

Chọn verification tiếp theo

Với payment-path change minh họa, hãy hỏi:

1. Scenario nào phụ thuộc vào payment behavior cũ?
2. Giả định timeout, retry và idempotency còn được giữ không?
3. Failure có thể lan đến order creation hoặc fulfilment không?
4. Bài thử nào phân biệt thay đổi an toàn với rủi ro chưa rõ?

Chọn thử nghiệm tập trung, review evidence mới hoặc thử flow rộng hơn. Ghi lý do và giới hạn còn lại.

Giao review owner

Ghi thay đổi kích hoạt review, claim bị ảnh hưởng, decision owner và điều kiện review tiếp theo. Một lịch định kỳ chưa bao phủ mọi thay đổi quan trọng.

Công việc định kỳ vẫn theo phạm vi: khách hàng giữ quyền quyết định production và rủi ro; thống nhất ai review, thực hiện thay đổi và hoàn tất hành động.

Freshness cần engineering judgment, không phải điểm theo lịch hay khả năng platform tự phát hiện thay đổi. Dependency chưa được nhận diện vẫn có thể tạo gap. Xem phương pháp hoặc high-risk architecture change.