Kiến thức nền: đọc hiểu hồ sơ kiểm chứng của một bản dựng

Ba tuần trước tôi đã xây dựng một widget đặt lịch cho một người bạn điều hành phòng tập yoga — một cuộc trò chuyện, một kế hoạch tôi duyệt nhanh vì lúc đó đang bận việc khác, một lần chạy, và sau đó là một thẻ phiên bản với dấu tích màu xanh mà tôi liếc qua rồi bỏ đi. Thứ Ba cô ấy nhắn tin hỏi liệu có thể trỏ trang web của studio thứ hai vào cùng bản build này không. Trước khi tôi đồng ý, tôi đã quay lại xem "đã xác minh" thực sự có nghĩa là gì ba tuần trước đó, và đó là lúc tôi thực sự đọc một trong những bản ghi này lần đầu tiên thay vì chỉ tin vào dấu tích.

Nó nằm ngay trên thẻ phiên bản, cạnh bản xem trước và các thao tác mã — cùng chỗ bạn sẽ vào để triển khai lại hoặc quay lại phiên bản cũ. Điều đầu tiên tôi nhận ra: nó chỉ giới hạn trong một phiên bản đó, không phải toàn bộ cuộc trò chuyện. Tôi đã lặp lại bản build này năm lần để đuổi theo một bộ chọn ngày bị lỗi, và tôi gần như mong đợi bản ghi sẽ kể cho tôi câu chuyện của toàn bộ quá trình qua lại. Nhưng không. Bản ghi của phiên bản 4 chỉ mô tả phiên bản 4. Nó không nhớ rằng phiên bản 2 đã phát hành với một form đăng nhập âm thầm bị lỗi, và nó sẽ không cho tôi biết phiên bản 5 đã âm thầm sửa điều gì đó mà phiên bản 3 làm hỏng. Mỗi bản ghi là một ảnh chụp nhanh, không phải bản so sánh khác biệt và cũng không phải nhật ký thay đổi — nếu tôi muốn xem lịch sử những gì đã thay đổi qua từng lần phát hành, đó là một view hoàn toàn khác. Cái này chỉ trả lời câu hỏi "phiên bản này có ổn không".

Cuộn xuống, bản ghi chia thành sáu hàng:

Cả sáu mục đều xanh, và phản xạ đầu tiên của tôi cũng là phản xạ sai lầm mà tôi đoán hầu hết mọi người đều có: bảo mật đạt, nghĩa là nó an toàn; khả năng tiếp cận đạt, nghĩa là nó dễ tiếp cận. Không cách hiểu nào trong hai cách đó đúng với những gì các lượt kiểm tra thực sự làm. Lượt kiểm tra bảo mật nghĩa là những thứ ở bề mặt — nối chuỗi trực tiếp vào một truy vấn, một API key nằm lộ ra trong bundle phía client, một eval trên thứ gì đó người dùng nhập vào — không xuất hiện. Đó không phải một ngày với một chuyên gia kiểm thử xâm nhập. Studio yoga của bạn tôi không nhận thanh toán qua widget này, chỉ nhận tên và khung giờ, nên mức tối thiểu đó là ổn cho cô ấy. Nếu đó là luồng thanh toán, tôi đã muốn nhiều hơn mức tối thiểu.

Khả năng tiếp cận là mục thực sự khiến tôi dừng lại và tra cứu, vì "đạt lượt quét axe" nghe có vẻ toàn diện nhưng thực ra không phải. Axe — bộ máy tự động chạy bên dưới — chỉ phát hiện chắc chắn khoảng một phần ba đến một nửa tiêu chí thành công WCAG: thiếu alt text, tỷ lệ tương phản kém, trường form không có nhãn, lỗi ARIA rõ ràng. Nó không thể cho bạn biết liệu bộ chọn ngày tùy chỉnh mà tôi yêu cầu có dùng được với trình đọc màn hình hay không, liệu việc dùng Tab để di chuyển qua luồng đặt lịch nhiều bước có đưa focus đến một chỗ hợp lý hay không, hay liệu trạng thái "đã xác nhận" so với "đang chờ" mà tôi tô màu xanh và vàng có gây khó khăn cho người mù màu đỏ-xanh hay không. Những điều đó cần một con người thực sự đi qua bản build với các công cụ mà người dùng khuyết tật thực sự dựa vào. Axe là tín hiệu thật, không phải là vô nghĩa — nó là lớp kiểm tra chính tả của khả năng tiếp cận, không phải là biên tập viên.

Tuân thủ là hàng tôi suýt lướt qua, vì nó nghe có vẻ hành chính — "chứa đúng những gì kế hoạch đã hứa" — cho đến khi tôi nhớ ra kế hoạch mà tôi đã duyệt được viết trong lúc tôi đang mất tập trung, và tôi thực sự không nhớ mình đã yêu cầu xác nhận qua email hay chỉ SMS. Đây là lớp kiểm tra bản build so với kế hoạch, không phải so với ý định thực sự của tôi, và nó đạt, điều đó cho tôi biết bản build khớp với những gì tôi đã đồng ý, chưa chắc là những gì tôi thực sự muốn. Tôi từng nghe về những bản build hoạt động tốt và an toàn nhưng vẫn không đạt lớp này vì một tính năng đã bị âm thầm bỏ qua do áp lực thời gian. Đây là lớp giữ cho bản build trung thực với cuộc trò chuyện đã tạo ra nó, ngay cả khi bản thân cuộc trò chuyện có phần sơ sài.

Bên dưới sáu hàng là một danh sách dài hơn, chia thành hai nhóm, và đây là chỗ tôi dành nhiều thời gian nhất. Các mục bắt buộc-sửa không phải là những thứ hiện đang sai trong bản build — chúng là biên lai. Một dòng ghi rằng lớp review đã gắn cờ một trường hợp chuỗi ngày được nối trực tiếp vào một truy vấn, và nó đã được vá trước khi phiên bản này được đánh dấu hoàn thành. Tôi không nhìn vào một vết thương đang hở; tôi đang nhìn vào một vết sẹo. Sự khác biệt đó quan trọng, vì nếu bạn đọc một mục bắt buộc-sửa như một cảnh báo còn sống, bạn sẽ tốn thời gian lo lắng về điều gì đó đã được giải quyết rồi.

Danh sách khuyến nghị dài hơn, và phần lớn là những điều tôi cũng sẽ tự nói nếu đang review code của một đồng nghiệp mà không muốn chặn việc merge: "cân nhắc tách khối render slot lặp lại thành một component dùng chung", "endpoint này không có giới hạn tốc độ, điều này ổn cho một công cụ đặt lịch nội bộ nhưng đáng cân nhắc lại nếu nó công khai". Không có gì trong danh sách đó là lỗi. Đó là những phán đoán mà một bộ xác minh đưa ra chỉ dựa trên kế hoạch và mã nguồn, và đối với bộ lập lịch nội bộ của một studio yoga, mỗi phán đoán đó đều hợp lý. Nếu studio của bạn tôi là một chuỗi nhượng quyền với widget nhúng trên năm mươi trang địa điểm, tôi sẽ muốn phản đối mục giới hạn tốc độ — việc phân loại đó phụ thuộc vào ngữ cảnh mà bộ xác minh chỉ có thể đoán, và khi một dự đoán có vẻ sai với bạn, cách đúng là nói ra trong chat, chứ không phải giả định rằng nhãn đó là cuối cùng.

Điều khiến tôi ấn tượng, khi nhìn vào một danh sách khuyến nghị khá dài bên cạnh một cột bắt buộc-sửa sạch sẽ, là tôi gần như đã đọc độ dài của nó như một tin xấu. Nhưng không phải vậy. Một bản build không có ghi chú khuyến nghị nào hoặc đã trải qua một lượt kiểm tra hẹp, hoặc chỉ là may mắn; một bản build với một loạt các mục "cân nhắc" và không có gì tồn đọng trong mục bắt buộc-sửa là bản build thực sự đã được xem xét kỹ lưỡng. Cột khuyến nghị là những gì còn lại sau khi các vấn đề thực sự đã được loại bỏ.

Điều khác tôi tự bắt mình làm, vì bản ghi này đã cũ ba tuần, là kiểm tra xem lớp nào thực sự đã chạy trước khi tin vào kết quả. Cả sáu lớp đều có mặt ở đây, nhưng tôi đã từng thấy một bản build mà khả năng tiếp cận đơn giản là vắng mặt khỏi danh sách thay vì được đánh dấu đạt hoặc không đạt — điều đó không giống với việc bị bỏ qua vì không quan trọng, đó là dấu hiệu cho thấy lượt kiểm tra đó không chạy cho loại trang web hoặc cấu hình cờ cụ thể đó, và việc đọc sự vắng mặt như một lượt đạt thầm lặng chính xác là sai lầm mà định dạng này dễ mắc phải nếu bạn chỉ đọc lướt.

Không có gì trong đó cho tôi biết liệu luồng đặt lịch của studio yoga có thực sự chuyển đổi hay không, liệu người ta có bỏ dở ở bước chọn khung giờ hay không, hay liệu ý tưởng dùng một widget tùy chỉnh thay vì chỉ liên kết ra Calendly có phải là lựa chọn đúng ngay từ đầu hay không. Việc xác minh chứng minh rằng một bản build hoạt động đúng như đã hứa, không phải rằng lời hứa đó là điều đúng đắn để đưa ra — đó là những câu hỏi tách biệt, và tôi đã chứng kiến những bản build vượt qua mọi lớp một cách sạch sẽ mà vẫn thất bại với người dùng thực vì "hoạt động đúng" và "giải quyết đúng vấn đề" không trùng nhau nhiều như bạn mong đợi. Nửa còn lại thực sự trả lời câu hỏi thứ hai là vòng lặp đo lường, và hai thứ này nên được đọc cùng nhau. Một bản ghi xác minh sạch sẽ trên một tính năng không ai đặt lịch qua vẫn là một tính năng không ai đặt lịch qua.