Notice: Undefined index: blockId in /home/hocteste/domains/testing.vn/public_html/wp-content/plugins/table-of-contents-block/table-of-contents-block.php on line 159
Đó 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 con bug mà bạn vừa bắt với lý do tài liệu không mô tả?” Hoặc chắc hẳn 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 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 mình thu thập được thông qua một bài viết trên nhóm Facebook TESTING VN (https://www.facebook.com/groups/testingvietnam/)
Đố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ề (Fresher Tester)
Không xem được chi tiết thông báo
Đây là một ví dụ của bạn Nhung – https://www.facebook.com/Mine.Nil.Minions
Click để đọc thông báo mà không xem chi tiết thông báo được. Dev bảo do tài liệu không mô tả phần đó.
Chức năng hiển thị thông báo
- 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ả thực tế: ứ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 chuông báo thức
Một ví dụ đến từ bạn Phí Thu Hà – https://www.facebook.com/haphithu
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:
- Mở ứng dụng, xem một video trên đó
- Đang xem thì có chuông báo thức hiện ra
- Tắt chuông báo thức
- Kết quả thực tế: Video vẫn đang tạm dừng (paused) sau người dùng khi tắt chuông báo thức
- Kết quả mong đợi: Video nên tiếp tục chạy, ngay sau người dùng khi tắt chuông báo thức
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ả gì đâu mà bắt tôi phải sửa (fix)
Kiểm tra tính hợp lệ của các giá trị nhập vào textbox
Một ví dụ khác đến từ bạn Dương Dương – https://www.facebook.com/rose.thorn.11111
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ày, 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 thì, 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.
Xoay điện thoại khi đang upload hình lên server
Một ví dụ khác đến từ bạn Hưng Ridoji – https://www.facebook.com/hung.ridoji
Chức năng chụp hình sau đó upload lên cloud. Các bước thao tác dẫn đến lỗi như sau:
- Để điện thoại đứng (portrait), thực hiện chụp hình
- Trong lúc hình đang được tự động upload, thì xoay ngang điện thoại (landscape)
- Kết quả thực tế: Ứng dụng bị crash
- Kết quả mong đợi: Hình vẫn được upload thành công và ứng dụng thì chuyển sang hiển thị dạng ngang
Developer từ chối đó là bug với lý do rất đơn giản: không người dùng (user) nào mà trong khi đang upload hình lại đi xoay ngang điện thoại hết áh. User phải đợi đến khi nó upload thành công thì mới xoay điện thoại.
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.
Tester nên xử lý thế nào?
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?
Bạn có thể xem chi tiết về lỗi này ở đây https://jira.atlassian.com/browse/JSWCLOUD-21697
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?
Tạm dịch theo một định nghĩa trên wiki. 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.
A software bug is an error, flaw or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
Nguồn: https://en.wikipedia.org/wiki/Software_bug
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, hoặc với khách hàng thì nhóm của bạn 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, v.v… 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ý.
Nếu bạn kiểm thử vượt quá phạm vi của yêu cầu thì sao?
Ví dụ như, khi khách hàng không yêu cầu phải test trên IE11, nhưng bạn lại test và phát hiện chục lỗi trên đó, trong khi đó những lỗi này không xảy ra trên Chrome.
Nếu bạn cố gắng thuyết phục Dev phải fix, hoặc trong một số nhóm thì tester rất “quyền lực” nên Dev phải làm theo thì sao? Nếu điều này xảy ra, thì khách hàng sẽ rất hài lòng. Bạn đã làm khách hàng hài lòng, và bạn cũng thoả mãn cái tôi của bản thân vì Dev đã “nghe theo lời bạn.” Nhưng nhóm của bạn được được gì từ chuyện này? Có thể, Dev phải làm thêm giờ để xử lý những “lỗi vặt” này? (Mình gọi là lỗi vặt vì nó không được mô tả trong tài liệu nhưng mình nghĩ người dùng cuối sẽ không hài lòng, hoặc nó làm cho hệ thống trở nên không chuyên nghiệp.) Nhiều lỗi liên quan đến hiển thị trên các trình duyệt, thiết bị di động khác nhau sẽ rất mất thời gian để tinh chỉnh. Đôi khi đẹp trên trình duyệt này nhưng lại không được ở trình duyệt khác.
Nếu nhóm bạn có dư thời gian để xử lý những việc đó thì nên làm để chúng ta có phần mềm hoàn thiện hơn, chuyên nghiệp và tốt hơn, thậm chí một số trường hợp bạn thấy nó “xử lý thông minh” hơn trong mắt người dùng. Thường đó là những nhóm làm sản phẩm cho chính họ. 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. Đối với họ, thời gian dành để xử lý những thứ “râu ria” đó là thuộc hàng xa xỉ.
Chúc bạn một ngày tốt đẹp!
P/S: Nếu bạn muốn chia sẻ câu chuyện của mình, mời bạn liên lạc với mình qua Zalo 0909426181. Cám ơn
