Tên công ty bị sai chính tả trên trang chủ và tính năng xuất hiếm khi được sử dụng bị lỗi: bạn sửa cái nào trước? Những lập luận như thế này là lý do khiến các nhóm thử nghiệm tách biệt mức độ nghiêm trọng và mức độ ưu tiên. Một phần mô tả thiệt hại kỹ thuật, phần còn lại mô tả tính cấp bách của hoạt động kinh doanh.

Nếu không có sự phân biệt đó, mọi lỗi sẽ được gắn nhãn “nghiêm trọng”, các nhãn sẽ mất đi ý nghĩa và các nhà phát triển không còn tin tưởng chúng nữa. Hướng dẫn này cung cấp cho bạn các định nghĩa và ví dụ rõ ràng, cùng với quy trình đơn giản để đưa ra các quyết định này. Các ví dụ mang tính minh họa và tỷ lệ chính xác khác nhau giữa các nhóm và công cụ.

Câu trả lời ngắn gọn

Mức độ nghiêm trọng câu trả lời: lỗi này ảnh hưởng đến sản phẩm nặng đến mức nào? Sự cố hoặc mất dữ liệu là nghiêm trọng, trong khi trục trặc về mặt thẩm mỹ thì không.

Ưu tiên câu trả lời: chúng tôi nên khắc phục trong bao lâu? Điều đó phụ thuộc vào khách hàng bị ảnh hưởng, thời hạn, doanh thu, rủi ro pháp lý và uy tín thương hiệu.

Hãy nghĩ về một bệnh viện. Mức độ nghiêm trọng là tình trạng của bệnh nhân nghiêm trọng đến mức nào. Ưu tiên là thứ tự điều trị cho bệnh nhân, điều này cũng phụ thuộc vào các yếu tố khác, chẳng hạn như ai có thể chờ đợi an toàn và nguồn lực nào miễn phí.

Mức độ nghiêm trọng và mức độ ưu tiên cạnh nhau

Mức độ nghiêm trọng

Hầu hết các đội sử dụng khoảng bốn hoặc năm cấp độ. Đây là thang đo chung:

Mức độ ưu tiên

Viết ra ý nghĩa của từng cấp độ đối với nhóm của bạn, lý tưởng nhất là kèm theo thời gian phản hồi mục tiêu cho từng cấp độ. “P1 có nghĩa là ai đó sẽ bắt đầu trong vòng một giờ” hữu ích hơn nhiều so với “P1 có nghĩa là rất quan trọng”.

Bốn sự kết hợp, với các ví dụ

Cách rõ ràng nhất để hiểu điều này là xem xét từng sự kết hợp:

Mức độ nghiêm trọng cao, mức độ ưu tiên cao

Mọi người đều không thể thanh toán, doanh nghiệp mất tiền từng phút và không có cách giải quyết nào. Đây là trường hợp hiển nhiên: bỏ mọi thứ và sửa nó.

Mức độ nghiêm trọng cao, mức độ ưu tiên thấp

Ứng dụng gặp sự cố khi xuất sang định dạng cũ. Về mặt kỹ thuật, đó là một thất bại nghiêm trọng. Nhưng nếu chỉ một phần nhỏ người dùng chạm tới tính năng này và định dạng hiện đại hoạt động tốt thì nó có thể chờ bản phát hành theo lịch trình.

Mức độ nghiêm trọng thấp, mức độ ưu tiên cao

Tên công ty bị sai chính tả trên trang chủ. Không có gì bị hỏng và không có dữ liệu nào gặp rủi ro. Tuy nhiên, mọi khách truy cập đều nhìn thấy nó, điều đó làm tổn hại đến lòng tin và nếu một buổi ra mắt lớn diễn ra vào ngày mai thì nó cần được sửa chữa ngay hôm nay.

Mức độ nghiêm trọng thấp, mức độ ưu tiên thấp

Một lỗi đánh máy nhỏ trong bài viết trợ giúp hiếm khi được truy cập. Hãy sửa nó khi thuận tiện. Nếu tồn đọng của bạn chứa đầy những thứ này, hãy cân nhắc việc gộp chúng thành một nhiệm vụ dọn dẹp.

Một lỗi, hai ưu tiên khác nhau

Cùng một khiếm khuyết có thể có mức độ ưu tiên khác nhau tùy thuộc vào ngữ cảnh. Giả sử email xác nhận đơn hàng gửi đi có logo sai.

Mức độ nghiêm trọng không thay đổi vì tác động lên hệ thống là như nhau. Nhưng tình hình kinh doanh đã làm được. Thời gian cũng có thể thay đổi mọi thứ. Lỗi P3 hôm nay có thể trở thành P1 một tuần trước khi khách hàng lớn đi vào hoạt động.

Ai quyết định mức độ nghiêm trọng và ưu tiên?

• Người thử nghiệm thường đề xuất mức độ nghiêm trọng vì họ đã nhìn thấy hành vi và hiểu tác động lên hệ thống.
• Chủ sở hữu hoặc người quản lý sản phẩm thường quyết định mức độ ưu tiên vì họ cân nhắc khách hàng, doanh thu và lộ trình.
• Nhà phát triển thêm thông tin về nguyên nhân, rủi ro của việc khắc phục và thời gian thực hiện.
• Các nhóm hỗ trợ đưa ra bằng chứng về số lượng khách hàng bị ảnh hưởng và mức độ ảnh hưởng nặng nề như thế nào.

Các nguồn và nhóm khác nhau sẽ thực hiện những trách nhiệm này và trong một công ty khởi nghiệp nhỏ, một người có thể đảm nhận tất cả những việc đó. Điều quan trọng là mọi người đều biết ai là người đưa ra quyết định cuối cùng, vì vậy những bất đồng sẽ kết thúc bằng một quyết định.

Cách đánh giá một lỗi

Khi bạn không chắc chắn, hãy giải quyết những câu hỏi này.

Đối với mức độ nghiêm trọng:

1. Nó có làm mất hoặc làm hỏng dữ liệu hoặc tiết lộ thông tin cá nhân không?
2. Nó có ngăn chức năng chính hoạt động không?
3. Có cách giải quyết nào không và người dùng bình thường có thể tìm thấy nó không?
4. Bao nhiêu tính năng bị ảnh hưởng?

Về ưu tiên:

1. Có bao nhiêu người dùng bị ảnh hưởng và những người dùng nào?
2. Nó có tốn tiền hay tạo ra rủi ro pháp lý hoặc tuân thủ không?
3. Sắp có đợt phát hành, demo hoặc giảm giá?
4. Mức độ hiển thị của nó như thế nào và nó có thể gây tổn hại đến danh tiếng của bạn không?
5. Nó có cản trở công việc khác, chẳng hạn như kiểm tra không?

Chạy phân loại lỗi

Phân loại là cuộc họp thường kỳ nơi một nhóm xem xét các lỗi mới và quyết định điều gì sẽ xảy ra tiếp theo. Một định dạng đơn giản hoạt động tốt:

1. Chuẩn bị. Người kiểm tra đảm bảo rằng mỗi lỗi mới đều có các bước, bằng chứng rõ ràng và mức độ nghiêm trọng được đề xuất.
2. Xác nhận. Kiểm tra xem nó có thể được sao chép và không phải là bản sao.
3. Quyết định. Đồng ý về mức độ nghiêm trọng, đặt mức độ ưu tiên và chỉ định chủ sở hữu.
4. Đóng vòng lặp. Từ chối, trì hoãn hoặc lên lịch cho từng lỗi và ghi lại lý do.

Giữ nó ngắn gọn và thường xuyên. Trong những ngày cuối cùng trước khi phát hành, việc phân loại 15 phút hàng ngày là điều phổ biến. Mức độ nghiêm trọng và mức độ ưu tiên cũng ảnh hưởng đến quyết định phát hành của bạn, vì vậy hãy đồng ý trước với các quy tắc, chẳng hạn như “không có lỗi S1 hoặc S2 nào khi phát hành”, như một phần trong tiêu chí thoát của bạn.

Mức độ nghiêm trọng và mức độ ưu tiên trong báo cáo lỗi

Mục ngắn gọn, rõ ràng giúp mọi người đưa ra quyết định đúng đắn:

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

Những con số đó là ví dụ. Trong một báo cáo thực tế, hãy sử dụng các số đo được từ nhật ký của bạn và giải thích lý do của bạn. Tìm hiểu thêm trong hướng dẫn của chúng tôi về cách viết báo cáo lỗi. Việc này cũng giúp bạn biết ý nghĩa của các mã lỗi, vì vậy, hãy chuẩn bị sẵn bảng ghi chú về mã trạng thái HTTP của chúng tôi.

Những lỗi thường gặp

• Xử lý chúng như cùng một trường. Nếu cả hai luôn khớp nhau, bạn đang mất đi thông tin hữu ích.
• Thổi phồng mức độ nghiêm trọng để thu hút sự chú ý. Một khi mọi thứ đều quan trọng thì chẳng có gì quan trọng cả.
• Để người thử nghiệm tự mình đặt mức độ ưu tiên. Họ hiếm khi có được bức tranh toàn cảnh về doanh nghiệp.
• Không bao giờ xem xét các hồ sơ tồn đọng. Các ưu tiên đã cũ, vì vậy hãy thường xuyên kiểm tra lại các lỗi cũ.
• Không có định nghĩa bằng văn bản. Không có chúng, mọi người áp dụng các nhãn khác nhau và cuối cùng bạn phải tranh luận về các từ.
• Bỏ qua các vấn đề chồng chất ở mức độ nghiêm trọng thấp. Năm mươi vấn đề nhỏ có thể khiến sản phẩm có cảm giác bị hỏng, ngay cả khi chỉ riêng vấn đề đó không nghiêm trọng.

Lời kết

Hãy tách biệt hai câu hỏi: nó tệ đến mức nào và phải sửa chữa trong bao lâu? Thống nhất về các định nghĩa bằng văn bản cho từng cấp độ và nêu rõ ai là người quyết định. Bước tiếp theo, hãy lấy mười lỗi lâu đời nhất trong trình theo dõi của bạn và đánh giá lại chúng bằng cách sử dụng các câu hỏi ở trên. Bạn có thể sẽ tìm thấy một số thứ nên di chuyển và một số thứ nên đóng lại.

Câu hỏi thường gặp

Tiếp tục học hỏi