Bug được định nghĩa là các lỗi phần mềm trong hệ thống máy tính hay trong các chương trình lập trình khiến cho kết quả chạy code báo lỗi, không chính xác. Tester phát hiện các lỗi, là bug thì lập trình viên cần phải sửa lại, gọi là fix bug. Tuy nhiên sẽ có một vài trường hợp Dev từ chối sửa vì những lý do sau. 

Đó không phải là bug!

Có thể bạn đã từng gặp câu hỏi “bạn sẽ làm gì khi developer từ chối bug mà bạn vừa bắt với lý do tài liệu không mô tả?”. Hoặc bạn đã từng nghe những câu đại loại như:

• Đó không phải là bug!
• Trên máy tôi vẫn chạy được bình thường!
• Tài liệu không mô tả trường hợp này!
• Không user làm thao tác như vậy cả!

Bài viết này đang mô tả một số ví dụ thực tế. Qua đó, chúng ta cùng tìm hiểu nguyên nhân và cách xử lý vấn đề này.

Tài liệu không mô tả trường hợp này

Có lẽ lý do bạn nghe nhiều nhất khi tham gia một nhóm gia công phần mềm (outsource) đó là “tài liệu không mô tả trường hợp này!”. Dưới đây là một số ví dụ thực tế về trường hợp tester bắt bug (report bug = báo lỗi) nhưng lập trình viên (dev = developer) không đồng ý đó là bug, hay gọi là “invalid bug.” Những ví dụ này được thu thập được thông qua một bài viết trên nhóm . 

Đối với một số ví dụ ngắn gọn thì mình sẽ diễn giải lại để dễ hình dung hơn đối với Tester mới vào nghề ()

Có thông báo nhưng không click vào không xem được chi tiết thông báo

Click để đọc thông báo mà không xem chi tiết thông báo được, do tài liệu không mô tả phần đó.

• Tài liệu mô tả: Hiển thị danh sách thông báo
• Developer: lập trình hiển thị danh sách thông báo đến người dùng
• Tester: khi kiểm thử, thấy được danh sách thông báo, click vào 1 thông báo để xem chi tiết thông báo. Kết quả  là ứng dụng không hiển thị chi tiết thông báo. Trong khi tester mong đợi nó phải mở màn hình hiển thị chi tiết thông báo đó.

Video không tự động chạy sau khi tắt cuộc gọi

Lỗi này được mô tả theo hình thức (format) như một bug report thường gặp. Các bước tái hiện lỗi:

Bước 1: Mở ứng dụng, xem một video trên đó

Bước 2: Đang xem thì có cuộc gọi đến hiện ra

Bước 3: Tắt cuộc gọi

• Kết quả thực tế: Video vẫn đang tạm dừng (paused) sau người dùng khi tắt cuộc gọi
• Kết quả mong đợi: Video nên tiếp tục chạy, ngay sau người dùng khi tắt cuộc gọi

Developer từ chối bug này (reject – đánh là invalid bug) với lý do: video dừng lại cũng không hẳn là lỗi. Chỗ này khách hàng có mô tả nên không sửa (fix)

Kiểm tra tính hợp lệ của các giá trị nhập vào textbox

Trường hợp kiểm tra (validate) tính hợp lệ của giá trị được nhập vào (input) một ô trên màn hình (text field, textbox) nhưng tài liệu (SRS – software requirement specification) không mô tả là sẽ kiểm tra vào thời điểm nào (trigger).

Thời điểm kiểm tra và báo lỗi

• Developer thì lập trình: sau khi click vào nút Đăng nhập (Sign in button) thì mới báo lỗi
• Tester mong đợi: ngay sau khi di chuyển ra khỏi textbox đó (lost focus) thì báo lỗi

Vì mong đợi khác nhau nên bug do tester report đã bị từ chối với lý do “tài liệu không mô tả nên đó không phải là bug!”. Thêm nữa, sau khi xác nhận với BA (Business Analyst – phân tích nghiệp vụ) thì cách hiểu của tester là đúng. BA cập nhật SRS và Developer đã sửa lại code.

Không quy định mật khẩu mới phải khác mật khẩu cũ

Và đây một ví dụ có nhiều tester đã từng gặp:

• Tester: bắt bug trong màn hình đổi password vì nó cho phép password mới giống password cũ.
• Developer: Spec (specification) không bảo password phải khác password cũ, nên tớ không phải kiểm tra.

Trong trường hợp dev không đồng ý đó là bug và từ chối (reject) thẳng tay (cập nhật con bug đó là invalid) thì tester nên làm gì? Và có phải tester luôn đúng không?

Trước tiên bạn và các thành viên trong nhóm phát triển phần mềm cần phải làm rõ khái niệm như thế nào thì được gọi là Bug và trường hợp nào thì không phải là bug (NAB – Not a Bug, hoặc invalid bug). 

Như thế nào thì được gọi là bug? Software Bug (lỗi phần mềm) là một lỗi, khiếm khuyết, hoặc sai trong chương trình máy tính hoặc hệ thống làm cho nó tạo ra kết quả sai hoặc không như mong đợi hoặc hành xử theo cách không như dự định. (Nguồn: Wikipedia) 

Như vậy, có thể nói không phải lúc nào trong tài liệu mô tả yêu cầu cũng đều mô tả hết thảy mọi trường hợp có thể xảy ra. Thường tài liệu chỉ mô tả những điều khách hàng (hoặc PM, BA) nghĩ rằng cần phải mô tả.

Có những điều quá đỗi bình thường, nên khách hàng nghĩ rằng không đáng để đề cập, ví dụ như: Màn hình đăng nhập, thì dù khách hàng không mô tả chi tiết chúng ta cũng hiểu rằng, nó phải có checkbox ‘Remember me’ (ghi nhớ đăng nhập cho lần sau) và link ‘Forgot Password’ (đổi mật khẩu).

Bên cạnh đó, nhiều khách hàng vì không rành hoặc không đề cập chi tiết, nên khi ghi yêu cầu cho màn hình Tạo tài khoản, thì không mô tả chi tiết số lượng hoặc loại ký tự được phép nhập vào ô ‘Tên khách hàng’. 

Làm gì để tránh xung đột trong nhóm?

Vậy, để tránh những bất đồng, các tình huống trớ trêu, hay những tranh cãi không đáng có trong nội bộ nhóm, với khách hàng thì nhóm và khách hàng nên thỏa thuận trước phạm vi mô tả trong tài liệu. Những yêu cầu đó là cơ bản hay chi tiết? Phần nào thì phải tuân thủ nghiêm ngặt theo mô tả trong yêu cầu, trường hợp nào thì team tự quyết định?

Tương tự như vậy, thì bạn cũng cần có quy định ngầm trong nhóm, trường hợp nào thì post bug, trường hợp nào thì Q&A hoặc dạng khác như Improvement, Enhancement (đề xuất cải tiến).

Ngoài ra, đối với những nhóm gia công phần mềm (outsourcing), chuyện cái nào là bug, cái nào là thay đổi yêu cầu, yêu cầu mới hay cái nào làm ngay, sẽ làm sau,… thì PM sẽ bàn với khách hàng. Hai bên sẽ phải thống nhất với nhau vì nó ảnh hưởng đến tiền bạc và thời gian hoàn thành sản phẩm. Đó cũng là lý do Dev và PM hay từ chối bug của tester vì những trường hợp đó không nằm trong phạm vi mô tả của yêu cầu dù nó hợp lý.

Đối với những lỗi như vậy, nếu sửa thì sẽ sản phẩm đến tay khách hàng hoàn chỉnh hơn, chuyên nghiệp hơn. Còn đa phần các nhóm outsource sẽ không làm như vậy. Họ sẽ tiết kiệm thời gian, để tập trung làm những thứ khách hàng yêu cầu. Hy vọng bài viết này sẽ hữu ích với bạn! 

Bộ môn Ứng dụng phần mềm
Trường Cao đẳng FPT Mạng cá cược bóng đá cơ sở Hà Nội