Đọc báo cáo đánh giá VPN: phạm vi quan trọng hơn huy hiệu
Huy hiệu đánh giá che giấu bốn sự thật đáng đọc: những thành phần nào đã được kiểm tra, bản dựng nào, điều gì bị loại trừ và những bản sửa nào được kiểm tra lại.
Huy hiệu thì rẻ để trưng bày và đắt để diễn giải. Một báo cáo đánh giá đã công bố là một phần công việc kỹ thuật có giới hạn: một chuyên gia đánh giá có tên đã xem xét các thành phần có tên, ở một phiên bản có tên, với phương pháp được nêu và ngân sách thời gian. Bốn sự thật đó quyết định kết luận có thể chống đỡ điều gì, và chúng thường nằm ở những trang đầu chứ không phải trong bản tóm tắt tiếp thị. Đọc chúng mất mười phút và ngăn ngừa lỗi phổ biến là mở rộng một phát hiện về ứng dụng khách ra toàn bộ dịch vụ.
Phần phạm vi thực sự giới hạn điều gì
Một tuyên bố phạm vi là một hàng rào, và mọi thứ bên ngoài nó vẫn chưa được trả lời chứ không phải đã đạt. Báo cáo liệt kê các thành phần được xem xét, phạm vi commit hoặc mã định danh bản dựng, môi trường được sử dụng và mô hình tương tác được phép. Ứng dụng khách máy tính, ứng dụng di động, mã máy chủ, phần phụ trợ tài khoản và hạ tầng sản xuất là năm chủ đề khác nhau, và một nhiệm vụ có thể bao trùm bất kỳ tập con nào của chúng.
Việc loại trừ quan trọng ngang với việc bao gồm, vì chúng được nêu có chủ đích và bị đọc một cách cẩu thả. Một hệ thống tài khoản được mô tả là ngoài phạm vi không được ngầm hiểu là an toàn, và một ứng dụng di động bị bỏ ngoài nhiệm vụ đơn giản là chưa được xem xét. Đánh dấu mọi thành phần chưa được kiểm tra trong ghi chú của bạn là chưa biết, và chống lại sự thôi thúc lấp đầy khoảng trống bằng danh tiếng.
Hai kiểu kiểm tra trả lời những câu hỏi khác nhau
Rà soát mã nguồn và kiểm thử khi chạy tìm những lỗi khác nhau. Một người rà soát đọc mã có thể theo dõi việc dẫn xuất khóa, nhận ra một kiểm tra độ dài bị thiếu và lập luận về toàn bộ bộ phân tích mà không cần chạy nó. Một người kiểm thử đối với dịch vụ đang chạy khám phá điều mà bản dựng đã triển khai thực sự làm: một chứng chỉ mà ứng dụng từ chối, một giao thức dự phòng vẫn được bật, một điểm cuối rò rỉ biểu ngữ phiên bản qua cấu hình mà không ai rà soát.
Không cái nào thay thế cái kia, và báo cáo thường nêu rõ đã thực hiện kiểu nào. Khi một bản tóm tắt nói «đã đánh giá» mà không có sự phân biệt đó, sự mơ hồ nằm ở bản tóm tắt chứ không phải ở báo cáo.
Các giới hạn truy cập làm công việc tương tự. Một nhiệm vụ hộp đen không thể thấy cấu hình máy chủ, và một rà soát kiến trúc không bao giờ chạm vào điểm cuối đã triển khai không thể nhận ra rằng sản xuất khác với sơ đồ. Cả hai đều chính đáng; trộn lẫn kết quả của chúng thì không.
Một phát hiện trở thành phiên bản đã sửa như thế nào
Nửa có giá trị của báo cáo là bảng khắc phục: từng phát hiện, mức độ nghiêm trọng theo phương pháp của chuyên gia đánh giá, phản hồi của nhà vận hành và kết quả kiểm tra lại. Các con số mức độ nghiêm trọng đến từ phương pháp luận được chọn chứ không phải từ tự nhiên, nên hãy so sánh mức độ nghiêm trọng trong một báo cáo chứ không phải giữa hai báo cáo có thang đo khác nhau.
Sau đó nối bản sửa với phần mềm đã phát hành. Một phát hiện đã sửa chỉ quan trọng với người dùng khi phiên bản mang bản sửa chính là phiên bản đã cài, và đó là lý do mã định danh bản dựng của báo cáo và nhật ký thay đổi của một bản phát hành phải được đọc cùng nhau. Một lần kiểm tra lại bao phủ bản sửa sẽ khép vòng; một bản sửa chưa được kiểm tra là một tuyên bố. Một bản sửa chỉ phát hành trong một nhánh mà không bản phát hành ổn định nào từng hợp nhất cũng vậy.
Điều huy hiệu không thể nói với bạn
Không có phát hiện không phải là bằng chứng không có khiếm khuyết. Một nhiệm vụ ngắn với ngân sách cố định sẽ bỏ sót vài thứ, và cách đọc trung thực một báo cáo sạch là chuyên gia đánh giá không tìm thấy những lớp vấn đề mà họ tìm kiếm trong thời gian có được.
Huy hiệu cũng không thể nói thay cho các thuộc tính nằm ngoài phạm vi của nó. Những tuyên bố về thực hành ghi nhật ký, thẩm quyền tài phán hay lưu trữ sống trong một tài liệu chính sách, không phải trong một cuộc đánh giá ứng dụng khách, và không danh tiếng nào của chuyên gia đánh giá vượt qua ranh giới đó.
Ghi lại bằng chứng bạn có thể bảo vệ
Viết trích dẫn thành ba phần: thành phần, phiên bản và bản sửa đã xác minh. Một nhiệm vụ đã công bố như cuộc đánh giá VPN do Mozilla đặt hàng chỉ chống đỡ đúng những tuyên bố mà phạm vi của nó mô tả và không rộng hơn, điều vẫn đáng giá khá nhiều khi trích dẫn chính xác. Cùng báo cáo đó được trích cho một điều nó chưa từng xem xét thì ít giá trị hơn là không trích dẫn, vì nó mời gọi một sự tin cậy mà không ai giành được.
Khi một thuộc tính được tuyên bố nằm ngoài mọi báo cáo có sẵn, hãy để nó chưa được giải quyết trong tài liệu. Một dòng chưa giải quyết mời gọi một câu hỏi tiếp theo; huy hiệu thì không. Ngoại lệ duy nhất là một thuộc tính được một tài liệu khác, cũng cụ thể như vậy, giải quyết, và khi đó trích dẫn thay đổi chứ không phải tuyên bố.
Hai thói quen nữa làm việc đọc trở nên bền vững: ghi ngày báo cáo so với bản phát hành bạn thực sự chạy, và giữ sự khác biệt giữa điều đã kiểm tra và điều bạn đã triển khai. Cả hai biến một quyết định tin cậy thành điều mà đồng nghiệp có thể kiểm chứng.