Lỗi chức năng (Functional Bugs)
Cách nhận biết một lỗi có phải là functional bug hay không, cách đánh giá mức độ nghiêm trọng, và phân biệt với đề xuất cải thiện trải nghiệm.
Functional bug (lỗi chức năng) là lỗi liên quan tới chức năng của phần mềm. Ví dụ: một nút không submit được form, ô tìm kiếm không phản hồi khi người dùng nhập liệu, hoặc app bị crash (đóng ứng dụng đột ngột). Mỗi lần bạn thực hiện một hành động mà website hoặc app không phản hồi đúng như kỳ vọng, rất có thể đó là một lỗi chức năng.
Vì Tester thường không nắm hết thông tin về sản phẩm và cách khách hàng triển khai nó, việc phân biệt một hành vi là cố ý hay thực sự là bug không phải lúc nào cũng dễ. Cách tốt nhất là đưa ra phán đoán dựa trên kinh nghiệm, kết hợp thử nghiệm nhiều kịch bản khác nhau để tìm câu trả lời.
1. Làm sao biết một hành vi có phải là functional bug?
- Thử xác định xem tính năng được thiết kế như vậy, hay thực sự đang bị hỏng. Hãy test riêng lẻ tính năng đó và test kết hợp với các tính năng khác để phát hiện sự khác biệt.
- Suy nghĩ về ý định của khách hàng khi làm ra sản phẩm. Đôi khi sản phẩm chỉ đang hoạt động đúng như cách nó được lập trình.
- Tìm bằng chứng cụ thể chứng minh điều gì đó không hoạt động đúng. Đừng chỉ dựa vào cảm giác.
- Ví dụ: một chức năng trên webshop hoạt động khác với các webshop khác bạn từng biết. Điều đó không có nghĩa là nó bị hỏng, khách hàng có quyền triển khai sản phẩm theo cách riêng của họ.
- Ví dụ: bạn cho rằng một ô nhập liệu không được validate (kiểm tra tính hợp lệ) và coi đó là bug. Có bằng chứng nào cho thấy ô đó lẽ ra phải được validate không? Hãy chứng minh bằng cách chỉ ra ô đó được validate ở trường hợp này nhưng không được validate ở trường hợp khác. Nếu không có bằng chứng, đó chỉ là một nhận định chưa được kiểm chứng.
- Một lỗi hiển thị (visual bug) hoặc lỗi nội dung (content bug) sẽ trở thành lỗi chức năng nếu nó cản trở người dùng thực hiện một chức năng, và khi đó nên báo cáo là functional bug.
- Nếu một chức năng luôn hoạt động giống nhau ở nhiều kịch bản khác nhau, không có vấn đề gì rõ ràng, thì nhiều khả năng đó là hành vi cố ý (không phải bug). Lúc này bạn chỉ nên đề xuất cải thiện, gọi là usability suggestion (đề xuất về trải nghiệm sử dụng).
2. Đánh giá mức độ nghiêm trọng (Severity Assessment)
Khi đánh giá mức độ nghiêm trọng của một functional bug, cần cân nhắc nhiều yếu tố: mức độ ảnh hưởng tới chức năng, phạm vi ảnh hưởng, có cách né lỗi (workaround) hay không, lỗi có chặn đứng cả luồng sử dụng (showstopper) hay không, khả năng gây thất thoát doanh thu, và so sánh với các bug tương tự đã từng được duyệt.
Mức độ ảnh hưởng tới chức năng (functional impact). Hãy nghĩ xem việc một chức năng không dùng được thì nghiêm trọng tới đâu. Một chức năng phụ bị hỏng thường không cản trở người dùng đạt được mục tiêu chính, khác với khi chức năng chính (main functionality) bị hỏng. Hãy tự hỏi chức năng đó quan trọng tới mức nào trong tổng thể sản phẩm.
Phạm vi ảnh hưởng (extent). Có bao nhiêu người dùng, sản phẩm hoặc mục bị ảnh hưởng bởi lỗi này? Ví dụ: nút “Thêm vào giỏ” không phản hồi trên mọi trang sản phẩm của webshop, hay chỉ trên một trang cụ thể? Chỉ một nhóm nhỏ người dùng gặp lỗi, hay tất cả mọi người?
Cách né lỗi (workaround). Xem thử có cách nào khác để đạt được mục tiêu mà không cần đi qua chức năng bị lỗi hay không. Nếu bạn dễ dàng tìm ra một cách né lỗi, bug đó thường được đánh giá mức độ thấp hơn so với bug tương tự nhưng không có cách né. Khi chức năng chính bị hỏng và hoàn toàn không có cách né, đó gọi là showstopper (lỗi chặn đứng toàn bộ luồng).
Khả năng thất thoát doanh thu (potential loss of sales). Đây là cách đánh giá gián tiếp, vì bạn thường chỉ có thể suy đoán người dùng sẽ phản ứng thế nào trước lỗi. Dù vậy, hãy cân nhắc mức thiệt hại tiềm ẩn: chênh lệch vài xu và chênh lệch hàng trăm đô la là hai chuyện hoàn toàn khác nhau.
So sánh (compare). Cuối cùng, bạn có thể so sánh bug của mình với những bug tương tự đã được Team Leader duyệt trong cùng đợt test, để kiểm tra xem mức độ mình chọn có hợp lý không.
3. Ba mức độ nghiêm trọng của functional bug
Low (Thấp)
- Ảnh hưởng tối thiểu tới việc sử dụng sản phẩm.
- Sản phẩm có hành vi ngoài ý muốn, nhưng không ảnh hưởng tới việc sử dụng chung.
- Chỉ ảnh hưởng tới một số ít người dùng, sản phẩm hoặc mục.
- Một tính năng bị hỏng hoặc không dùng được, nhưng có cách né lỗi dễ dàng.
High (Cao)
- Ảnh hưởng nghiêm trọng tới việc sử dụng sản phẩm, nhưng chức năng chính vẫn hoạt động.
- Ảnh hưởng tới số lượng lớn người dùng, sản phẩm hoặc mục.
- Một chức năng không nhỏ bị hỏng hoặc không dùng được, và không có cách né lỗi.
- Một chức năng quan trọng bị hỏng nhưng vẫn có cách né (nên chưa tới mức showstopper).
Critical (Nghiêm trọng)
- Lỗi chặn đứng chức năng cốt lõi của app hoặc website.
- Một showstopper khiến người dùng không thể tiếp tục một luồng chính, ví dụ luồng thanh toán (checkout).
- Lỗi có khả năng gây thất thoát doanh thu đáng kể cho công ty vận hành app/website đó.
4. Các trường hợp đánh giá cố định
Có một danh sách các trường hợp đã được quy định sẵn mức độ nghiêm trọng cố định, không áp dụng theo cách đánh giá thông thường ở trên. Danh sách này thường xuyên được cập nhật, nên bạn cần kiểm tra định kỳ trước khi báo cáo các trường hợp tương tự.
5. Edge case bugs (lỗi trường hợp biên)
Edge case bug là lỗi chỉ xảy ra khi một chức năng được sử dụng theo cách khác thường. Với dữ liệu và thao tác điển hình, chức năng đó vẫn hoạt động bình thường. Một số ví dụ:
- Thao tác quá nhanh, ví dụ thu nhỏ app ngay sau khi vừa bấm một nút.
- Lặp lại liên tục cùng một hành động, ví dụ mở rồi đóng menu nhiều lần liên tiếp.
- Bất kỳ lỗi nào chỉ xuất hiện sau một chuỗi thao tác bất thường, hiếm gặp.
Mỗi trường hợp cần được đánh giá riêng. Edge case bug nào thực sự có liên quan tới khách hàng sẽ được chuyển thành bug mức Low. Phần lớn edge case bug không liên quan sẽ bị từ chối.
6. Forced bugs (lỗi bị “ép” tạo ra)
Việc cố tình tạo ra lỗi bằng hành vi bất thường hoặc điều kiện đặc biệt thường nằm ngoài phạm vi báo cáo (out of scope), vì những lỗi này không có giá trị với khách hàng. Hành vi bất thường không phản ánh cách người dùng thật sự sử dụng sản phẩm. Một số ví dụ:
- Chạm vào nhiều phần tử cùng lúc.
- Bấm nút một cách ngẫu nhiên.
- Bấm liên tục, dồn dập vào một nút nhiều lần.
- Thu nhỏ cửa sổ trình duyệt xuống kích thước bất thường, hoặc zoom in/out quá mức.
- Bộ nhớ RAM hoặc bộ nhớ trong đầy, dẫn tới hành vi không mong muốn.
- Dùng phiên bản hệ điều hành không chính thức, bản beta hoặc bản đã chỉnh sửa.