Tóm Tắt
Đó 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 khước từ con bug mà bạn vừa bắt với nguyên do tài liệu không miêu tả ? ” Hoặc chắc rằng 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ả!Đó không phải là bug ! Trên máy tôi vẫn chạy được thông thường ! Tài liệu không miêu 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.
Bạn đang xem: Bạn sẽ làm gì khi developer nói là không thể tái tạo được lỗi của bạn?
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à 1 số ít ví dụ thực tiễn 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 chấp thuận đồng ý đó là bug, hay gọi là “ invalid bug. ” Những ví dụ này mình tích lũy được trải qua một bài viết trên nhóm Facebook issf.vn việt nam ( https://www.facebook.com/groups/issf.vnvietnam/ )Đối với một số ít ví dụ ngắn gọn thì mình sẽ diễn giải lại để dễ tưởng tượng hơn so 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.MinionsClick để đọc thông tin mà không xem chi tiết cụ thể thông tin được. Dev bảo do tài liệu không miêu 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áoDeveloper: lập trình hiển thị danh sách thông báo đến người dùngTester: 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
Hiển thị list thông báolập trình hiển thị list thông tin đến người dùngkhi kiểm thử, thấy được list thông tin, click vào 1 thông tin để xem chi tiết cụ thể thông tin. Kết quả trong thực tiễn : ứng dụng không hiển thị chi tiết cụ thể thông tin. Trong khi tester mong đợi nó phải mở màn hình hiển thị chi tiết cụ thể thông tin đó .
Một ví dụ đến từ bạn Phí Thu Hà – https://www.facebook.com/haphithu
Lỗi này được diễn đạ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 raTắt chuông báo thứcKế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ứcKế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ứcMở ứng dụng, xem một video trên đóĐang xem thì có chuông báo thức hiện raTắt chuông báo thứcVideo vẫn đang tạm dừng ( paused ) sau người dùng khi tắt chuông báo thứcVideo nên liên tục chạy, ngay sau người dùng khi tắt chuông báo thứcDeveloper phủ nhận bug này ( reject – đánh là invalid bug ) với nguyên do : video dừng lại cũng không hẳn là lỗi. Chỗ này người mua có miêu 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 hiển thị ( text field, textbox ) nhưng tài liệu ( SRS – software requirement specification ) không miêu tả là sẽ kiểm tra vào thời gian 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ỗiTester mong đợi: ngay sau khi di chuyển ra khỏi textbox đó (lost focus) thì báo lỗisau khi click vào nút Đăng nhập ( Sign in button ) thì mới báo lỗingay sau khi vận động và di chuyển ra khỏi textbox đó ( lost focus ) thì báo lỗiVì mong đợi khác nhau này, nên bug do tester report đã bị phủ nhận với nguyên do “ tài liệu không miêu 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 – nghiên cứu và phân tích nhiệm vụ ) thì cách hiểu của tester là đúng. BA update 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ìnhTrong 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ị crashKế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Để điện thoại cảm ứng đứng ( portrait ), thực thi chụp hìnhTrong lúc hình đang được tự động hóa upload, thì xoay ngang điện thoại cảm ứng ( landscape ) Ứng dụng bị crashHình vẫn được upload thành công xuất sắc và ứng dụng thì chuyển sang hiển thị dạng ngangDeveloper phủ nhận đó là bug với nguyên do rất đơn thuầ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 cảm ứng hết áh. User phải đợi đến khi nó upload thành công xuất sắc thì mới xoay điện thoại cảm ứng .
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ặpTester: 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?
bắt bug trong màn hình hiển thị đổi password vì nó được cho phép password mớipassword cũ. Spec ( specification ) không bảo password phảipassword cũ, nên tớ không phải kiểm tra .Trong trường hợp dev không chấp thuận đồng ý đó là bug, và khước từ ( reject ) thẳng tay ( update con bug đó là invalid ) thì tester nên làm gì ? Và có phải tester luôn đúng không ?
Invalid BugMột ví dụBạn hoàn toàn có thể xem cụ thể về lỗi này ở đây https://jira.atlassian.com/browse/JSWCLOUD-21697Trước tiên bạn và những thành viên trong nhóm tăng trưởng ứng dụng 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.
Xem thêm: Chu Khi Buon 40 – Trò Chơi Chú Khỉ Buồn 9
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.
Như vậy, hoàn toàn có thể nói không phải khi nào trong tài liệu miêu tả nhu yếu cũng đều miêu tả hết thảy mọi trường hợp hoàn toàn có thể xảy ra. Thường tài liệu chỉ miêu tả những điều người mua ( hoặc PM, BA ) nghĩ rằng cần phải miêu tả .Có những điều quá đỗi thông thường, nên người mua nghĩ rằng không đáng để đề cập, ví dụ như : Màn hình đăng nhập, thì dù người mua không miêu tả cụ thể, tất cả 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 người mua, vì không rành hoặc không đề cập cụ thể, nên khi ghi nhu yếu cho màn hình hiển thị Tạo thông tin tài khoản, thì không miêu tả cụ thể số lượng hoặc loại ký tự được phép nhập vào ô ‘ Tên người mua ’
Vậy, để tránh những sự không tương đồng, những trường hợp trớ trêu, hay những tranh cãi không đáng có trong nội bộ nhóm, hoặc với người mua thì nhóm của bạn và người mua nên thỏa thuận hợp tác trước khoanh vùng phạm vi diễn đạt trong tài liệu. Những nhu yếu đó là cơ bản hay cụ thể ? Phần nào thì phải tuân thủ khắt khe theo diễn đạt trong nhu yếu, trường hợp nào thì team tự quyết định hành động ? Tương tự như vậy, thì bạn cũng cần có pháp luật 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 kiến nghị nâng cấp cải tiến ) . Ngoài ra, so với những nhóm gia công ứng dụng ( outsourcing ), chuyện cái nào là bug, cái nào là đổi khác nhu yếu, nhu yếu mới, hay cái nào làm ngay, sẽ làm sau, v.v … thì PM sẽ bàn với người mua. Hai bên sẽ phải thống nhất với nhau. Vì nó ảnh hưởng tác động đến tiền tài và thời hạn triển khai xong mẫu sản phẩm. Đó cũng là nguyên do Dev và PM hay khước từ bug của tester vì những trường hợp đó không nằm trong khoanh vùng phạm vi diễn đạt của nhu yếu dù nó hài hòa và 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.
Xem thêm: 20 Điều Bạn Cần Thảo Luận Với Chàng Trước Khi Lấy Chồng Cần Chuẩn Bị Những Gì ?
Nếu nhóm bạn có dư thời hạn để giải quyết và xử lý những việc đó thì nên làm để tất cả chúng ta có ứng dụng hoàn thành xong hơn, chuyên nghiệp và tốt hơn, thậm chí còn một số ít trường hợp bạn thấy nó “ giải quyết và xử lý mưu trí ” hơn trong mắt người dùng. Thường đó là những nhóm làm loại sản phẩm cho chính họ. Còn đa số những nhóm outsource sẽ không làm như vậy. Họ sẽ tiết kiệm chi phí thời hạn, để tập trung chuyên sâu làm những thứ người mua nhu yếu. Đối với họ, thời hạn dành để giải quyết và 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 !
Source: https://final-blade.com
Category : Kiến thức Internet
