Khi nào một bug không phải là bug?

Để đảm bảo chất lượng phần mềm thì việc phát hiện và log bug là công việc hàng ngày của một QA/ Tester. Tuy nhiên không hẳn tất cả những bug chúng ta tìm được đều là bug. Vậy khi nào một bug không phải là bug? Và đâu là ranh giới để xác định một bug có phải là bug hay không?

Bug là gì

Đầu tiên ta cần hiểu Bug là gì? Theo wikipedia định nghĩa: "Bug là những error, flaw, failure, hay fault tạo ra một kết quả sai, hoặc không lường đến được."

Đơn giản có thể coi nó như một thứ gì đó không hoạt động đúng theo thiết kế. Tuy nhiên còn nhiều thứ phát sinh không được mô tả trong thiết kế và requiment của khách hàng, vậy nó có phải là Bug?

Một số quy tắc xác định bug

Một lỗi phần mềm xuất hiện khi 1 hoặc nhiều hơn trong 4 quy tắc dưới đây là đúng:

1. Nó không được thực hiện giống như mô tả trong bản đặc tả phần mềm

Áp dụng quy tắc này, tester chỉ cần luôn nắm được yêu cầu phần mềm thì việc xác định bug cũng sẽ đơn giản hơn.

• VD 1: Thử áp dụng quy tắc trên để phân tích lỗi trong phần mềm Calculator, với yêu cầu nói rõ rằng: 'nó phải thực thi phép cộng, phép trừ, phép nhân, phép chia đúng'.

Nếu bạn nhấn phím “+” và không có chuyện gì xảy ra, đó là một bug theo đúng quy tắc này do nó không thực hiện giống như mô tả. Tương tự, nếu bạn nhận được câu trả lời sai, cũng có nghĩa rằng đó là một bug.

• VD2: Kiểm tra chức năng của nút Back ở trang kết quả tìm kiếm của một website:

Ở VD này nút 'Back' không được làm việc theo thiết kế (Not Working as Designed). Vì nó không làm đúng chức năng yêu cầu nên nó rõ ràng là một bug.

2. Bản đặc tả yêu cầu nó không được thực hiện nhưng nó vẫn xảy ra

Spec yêu cầu: 'Calculator sẽ không bao giờ bị đột ngột ngưng hoạt động, bị khóa lại hoặc bị đóng băng'. Nếu bạn nhấn liên tiếp lên các phím và nhận được thông báo từ calculator “not responding”, đây là một lỗi theo theo quy tắc 2.

3. Nó là chức năng mà bản đặc tả không đề cập tới

Khi bạn phát hiện ra Calculator không chỉ thực hiện các phép tính công, trừ, nhân, chia mà còn thực hiện các phép căn bậc 2. Điều này không được nêu trong spec, một lập trình viên có nhiều tham vọng vừa thêm nó vào bởi vì anh ta cảm thấy nó sẽ là một tính năng hữu ích. Đây không phải là một một feature, nó thật sự là một bug theo quy tắc 3. Phần mềm đang thực hiện một số công việc không được yêu cầu.

Mặc dù feature này có thể là tốt, nhưng nó sẽ yêu cầu thêm những nỗ lực lập trình và kiểm thử (vì có thể sẽ xuất hiện thêm nhiều lỗi). Có thể làm cho chi phí sản xuất phần mềm lớn hơn, làm giảm hiệu quả kinh tế của quá trình sản xuất phần mềm.

4. Nó là chức năng không được thực hiện mà bản đặc tả cũng không đề cập tới nhưng là những việc nên làm

Đọc quy tắc 4 có thể thấy hơi lạ với sự phủ định kép, nhưng mục đích của nó là tìm thấy những đặc điểm bị lãng quên, không được nhắc tới trong requirement. VD ở phần mềm Calculator khi Pin yếu, bạn không nhận được những câu trả lời đúng cho quá trình tính toán của bạn nữa. Chưa ai từng xem xét xem calculator phản ứng lại như thế nào trong chế độ này. Giả dụ pin luôn được nạp đầy thì những phép tính đúng đã không xảy ra. Tuy nhiên spec lại không nêu rõ khi pin yếu thì cần làm những gì, do đó việc thông báo pin yếu và không trả về kết quả tính toán sai là một việc cần thiết nên làm.

Khi nào một bug không phải là bug?

Một bug có thể đúng với 1 hoặc nhiều hơn trong 4 quy tắc trên. Vậy ngược lại khi nó không đúng với bất kỳ nguyên tắc nào trên đó nhưng vẫn chưa xác định được chính xác và rõ ràng là bug hay không? Hãy cùng thử trả lời mỗi câu hỏi dưới đây cho mỗi vấn đề đang gặp, có thể bạn sẽ biết được có nên đưa nó vào danh sách bugs không hay là feedback nó:

1. Nó có khó hiểu, khó sử dụng hay cản trở khả năng của người dùng sử dụng ứng dụng không?
2. Bạn có thể làm nó xảy ra từ hai lần trở lên không?
3. Nếu chỉ xảy ra 1 lần, nó có tạo ra kết quả tiêu cực đáng kể không?
4. Nó có làm mất hứng thú của người dùng sử dụng không?
5. Nó có gì trái ngược hay mâu thuẫn không?
6. Nó có phải là cách tối ưu nhất không?
7. Bạn có mong đợi nó xảy ra theo một cách khác?

Hãy thử áp dụng với một số tình huống lỗi sau:

• VD1: Trong ứng dụng Calculator có những nút có kích thước quá nhỏ. Hoặc có thể sự sắp xếp của các nút đã làm cho nó khó sử dụng. Hoặc sự bố trí màu sắc làm cho nó rất khó nhìn... Tất cả những điều này đều có câu trả lời là có cho câu hỏi số 1. Nên nó được xác định là bug.

• VD2: Đối với những lỗi mà nó không thể được tái hiện ở lần thứ hai (và không chỉ ra được kết quả ảnh hưởng) thì nó sẽ bị ưu tiên thấp và có khả năng sẽ bị từ chối. Lỗi này được gọi tên là 'Once Upon a Time Bug'.

Có thể ban đầu chúng ta bắt gặp nó là lỗi nhưng thật ra lại chỉ bị với trình duyệt của bạn, đó có thể là những lỗi như: hình ảnh bị hỏng, các nút không click được, lỗi đồng bộ video, ... Cách thông minh nhất để bug đó không bị từ chối là xóa bộ nhớ cache, khởi động lại trình duyệt và re-test lại để xác nhận lỗi.

• VD3: Không nhập gì vào ô tìm kiếm, khi nhấn Search thì load lại một trang trắng.

Bản đặc tả đã không yêu cầu về tính năng reload lại trang trong trường hợp này, nó có thể không ảnh hưởng đến việc sử dụng phần mềm của người dùng. Tuy nhiên người dùng không mong đợi như thế, nó được coi là một lỗi UX.

Kết luận

Dựa theo các quy tắc, bạn hãy áp dụng linh hoạt với phần mềm mà mình sử dụng hàng ngày. Khi bám chặt theo quy tắc trên, bạn sẽ dễ dàng tìm ra được cho mình câu trả lời cho mỗi vấn đề mình gặp phải. Do đó số bugs được chấp nhận sẽ nhiều hơn, giảm số bugs phải reject.

Và hơn hết, khi một vấn đề không rõ ràng hoặc bạn không chắc về nó, bạn cho là không phải bug và cần feedback, thì tốt nhất nên tạo Q&A cho BA, PM hay khách hàng.

Trong trường hợp bị từ chối, chỉ cần nhớ rằng khách hàng không phải nói bạn sai! Chỉ là phát hiện của bạn không đáp ứng được yêu cầu trong ứng dụng của họ trong giai đoạn này mà thôi.

Bài biết được tổng hợp và dịch từ các nguồn dưới đây

https://www.utest.com/courses/when-is-a-bug-not-a-bug

https://voer.edu.vn/c/loi-bug-la-gi/4c771e16/32455ae1