Tác giả
Câu này hay được hỏi lúc phỏng vấn, và hay bị dùng sai lúc đi làm.
Đặt mức cho lỗi là một phần của việc báo cáo — nhóm việc cuối trong bốn nhóm việc của một tester. Ba nhóm trước ở Manual testing là gì.
Hầu hết bài viết về nó cho một bảng bốn ô rồi hết. Bảng đó đúng nhưng không giải quyết được chuyện thật sự xảy ra trong công việc: bạn đặt mức nghiêm trọng cao, lỗi vẫn nằm đó hai tuần, và không ai giải thích vì sao.
Trả lời ngay, một câu mỗi cái
Severity — mức độ nghiêm trọng: lỗi này làm hỏng hệ thống đến đâu?
Priority — mức độ ưu tiên: lỗi này cần được sửa sớm đến đâu?
Chúng độc lập với nhau. Đó là toàn bộ chỗ khó, và cũng là lý do câu này hay được đem ra hỏi.
Cách nhớ gọn: severity nói về hệ thống, priority nói về lịch làm việc.
Bốn tổ hợp
Vì hai thứ độc lập nên có bốn khả năng. Ba cái dễ hình dung. Cái thứ tư mới là chỗ hay bị hiểu sai.
Nghiêm trọng cao, ưu tiên cao: Không thanh toán được. Hệ thống hỏng ở chỗ sinh ra tiền. Không ai tranh luận gì, và đây cũng là loại lỗi ít cần bàn nhất.
Nghiêm trọng thấp, ưu tiên thấp: Một dòng chữ lệch hai pixel trong trang cài đặt mà ít ai vào. Ghi lại, sửa khi rảnh. Cũng không ai tranh luận.
Nghiêm trọng thấp, ưu tiên cao: Tên công ty bị viết sai chính tả trên trang chủ.
Hệ thống chạy hoàn hảo. Không chức năng nào hỏng, không dữ liệu nào sai — nên severity thấp, đúng theo định nghĩa. Nhưng nó nằm ngay trang đầu và làm mất mặt thương hiệu, nên phải sửa trong hôm nay.
Đây là tổ hợp làm người mới bối rối nhất, và cũng là tổ hợp chứng minh rõ nhất rằng hai thứ này không phải một thứ đổi tên.
Nghiêm trọng cao, ưu tiên thấp: Chức năng xuất báo cáo sập hoàn toàn — nhưng chỉ sập khi chọn một định dạng chưa khách hàng nào dùng.
Hỏng nặng: sập là sập, không có đường tránh. Nhưng chưa ảnh hưởng ai, nên chưa cần chen vào lịch tuần này.
Ai quyết cái nào
Đây là phần các bài khác bỏ qua, và là phần gây tranh cãi trong công việc thật.
Cách phân chia phổ biến:
- Severity là của tester. Bạn là người thấy lỗi, bạn biết nó làm hỏng đến đâu. Đây là đánh giá kỹ thuật về hệ thống.
- Priority là của người quản lý sản phẩm hoặc quản lý dự án. Nó phụ thuộc vào những thứ tester không thấy hết: cam kết với khách hàng, ngày ra bản, việc gì đang làm dở, ai đang rảnh.
⚠️ Cách phân chia này không phải chuẩn quốc tế. Nó là cách làm phổ biến, và mỗi công ty một khác. Có nơi tester đề xuất cả hai rồi họp chốt lại. Có nơi lập trình viên tự đặt severity khi nhận lỗi. Đừng đi tranh luận rằng chỗ mình đang làm sai chuẩn — không có chuẩn để sai.
Điều dùng được: biết ranh giới đó ở chỗ bạn đang làm, và biết mình có quyền ở phần nào. Đặt severity là quyền của bạn thì đừng tự hạ nó xuống vì bị hối.
Khi bạn và Dev không đồng ý
Chuyện này xảy ra thường xuyên. Tranh luận kiểu "tôi thấy nó nghiêm trọng" không dẫn tới đâu, vì đối phương cũng có một cái thấy khác và không ai chứng minh được cái thấy của mình.
Ba cách chuyển tranh luận từ cảm tính sang dữ kiện.
Nói bằng hậu quả, không bằng tính từ:
Thay "lỗi này nghiêm trọng" bằng "lỗi này khiến người dùng không hoàn tất được đơn hàng". Câu sau khó phản đối hơn nhiều, vì nó là một phát biểu kiểm chứng được, không phải một đánh giá.
Nói bằng phạm vi:
Lỗi này ảnh hưởng mọi người dùng, hay chỉ người dùng chọn một tuỳ chọn ít ai chọn? Chỉ xảy ra trên một trình duyệt, hay tất cả?
Phạm vi là dữ kiện. Nó cũng là thứ thường quyết định priority trong thực tế, nên nói ra phạm vi là nói đúng ngôn ngữ của người quyết.
Nói bằng đường tránh:
Có cách nào người dùng tự làm được việc đó bằng đường khác không? Có đường tránh dễ thì priority hạ xuống một cách hợp lý.
Chủ động nói ra điều này — kể cả khi nó làm yếu lập luận của mình — có một tác dụng dài hạn: lần sau bạn nói một lỗi là nghiêm trọng, người ta tin. Người luôn nói mọi lỗi đều nghiêm trọng thì cuối cùng không ai nghe nữa.
Ba nhầm lẫn hay gặp
Đặt mọi lỗi ở mức cao nhất: Nếu mọi lỗi đều nghiêm trọng nhất thì không lỗi nào nghiêm trọng, và cả bảng phân loại mất nghĩa. Đây là cách nhanh nhất để ý kiến của bạn bị coi nhẹ.
Lẫn priority với thời điểm phát hiện: Lỗi tìm ra sát ngày ra bản không tự động thành ưu tiên cao. Nó chỉ khẩn cấp nếu hậu quả khẩn cấp. Ngược lại, một lỗi tìm ra từ tháng trước không tự động thành ưu tiên thấp chỉ vì nó đã nằm đó lâu.
Đổi severity vì bị hối: Severity là đánh giá kỹ thuật về mức hỏng của hệ thống. Nó không đổi vì lịch dự án đổi. Cái đổi theo lịch là priority — và đó là quyền của người khác, không phải chỗ bạn phải nhượng bộ.
Nói lại một câu
Severity trả lời "hỏng đến đâu". Priority trả lời "sửa lúc nào". Hai câu hỏi khác nhau, hai người trả lời khác nhau, và lẫn chúng vào nhau là nguồn của phần lớn tranh cãi quanh bảng lỗi.
Nếu chỉ mang đi được một điều: khi cần bảo vệ một lỗi, hãy nói bằng hậu quả và phạm vi, đừng nói bằng tính từ.
