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?

  -  

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

Có thể các bạn đã có lần chạm chán câu hỏi “các bạn sẽ làm cái gi khi developer từ chối con bug nhưng mà các bạn vừa bắt cùng với lý do tư liệu ko mô tả?” Hoặc chắc rằng chúng ta đã từng có lần nghe rất nhiều câu đại nhiều loại như:

Đó không hẳn là bug!Trên máy tôi vẫn chạy được bình thường!Tài liệu không biểu lộ ngôi trường hòa hợp này!Không user có tác dụng làm việc những điều đó cả!

Bài viết này biểu lộ một trong những ví dụ thực tiễn. Qua kia, họ thuộc tò mò nguyên nhân với bí quyết cách xử trí 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 thể hiện trường đúng theo này

Có lẽ nguyên do chúng ta nghe nhiều nhất lúc tmê mệt gia một đội gia công phần mềm (outsource) chính là “tư liệu không thể hiện trường đúng theo này!”

Dưới đấy là một trong những ví dụ thực tế về trường hòa hợp tester bắt bug (report bug = báo lỗi) nhưng thiết kế viên (dev = developer) không đồng ý chính là bug, giỏi call là “invalid bug.” Những ví dụ này mình thu thập được thông sang một nội dung bài viết bên trên nhóm Facebook issf.vn nước ta (https://www.facebook.com/groups/issf.vnvietnam/)

Đối cùng với một số ví dụ ngắn thêm gọn thì bản thân đã diễn giải lại để dễ tưởng tượng hơn so với Tester bắt đầu vào nghề (Fresher Tester)

Không xem được cụ thể thông báo

Đây là một trong những ví dụ của doanh nghiệp Nhung – https://www.facebook.com/Mine.Nil.Minions

Click để phát âm thông báo nhưng ko xem cụ thể thông tin được. Dev bảo bởi tài liệu ko 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ị list thông báoDeveloper: xây dựng hiển thị danh sách thông báo cho người dùngTester: lúc kiểm test, thấy được danh sách thông báo, click vào 1 thông báo để thấy chi tiết thông tin. Kết quả tình tế: áp dụng ko hiển thị chi tiết thông báo. Trong lúc tester hy vọng ngóng nó đề xuất mnghỉ ngơi màn hình hiển thị hiển thị cụ thể thông báo kia.

Video ko auto chạy sau khi tắt chuông báo thức

Một ví dụ tới từ các bạn Phí Thu Hà – https://www.facebook.com/haphithu

Lỗi này được miêu tả theo hiệ tượng (format) nhỏng một bug report thường xuyên gặp:

Các bước tái hiện tại lỗi:

Msống áp dụng, coi một video trên đóĐang coi thì tất cả chuông báo thức hiện nay raTắt chuông báo thứcKết quả thực tế: Video vẫn đã tạm dừng (paused) sau người tiêu dùng Khi tắt chuông báo thứcKết trái mong đợi: Video yêu cầu thường xuyên chạy, ngay lập tức sau người tiêu dùng Lúc tắt chuông báo thức

Developer từ chối bug này (reject – tấn công là invalid bug) cùng với lý do: video tạm dừng cũng không phải là lỗi. Chỗ này quý khách hàng gồm mô tả gì đâu nhưng mà bắt tôi bắt buộc sửa (fix)

Kiểm tra tính vừa lòng lệ của những quý giá nhập lệ textbox

Một ví dụ không giống tới từ bạn Dương Dương – https://www.facebook.com/rose.thorn.11111

Trường thích hợp kiểm soát (validate) tính hợp lệ của quý hiếm được nhập lệ (input) một ô bên trên màn hình (text field, textbox) cơ mà tài liệu (SRS – software requirement specification) ko diễn đạt là đang đánh giá vào thời khắc như thế nào (trigger).

Thời điểm bình chọn và báo lỗi

Developer thì lập trình: sau thời điểm clichồng vào nút Đăng nhập (Sign in button) thì mới báo lỗiTester mong mỏi đợi: ngay lập tức sau thời điểm dịch chuyển ra khỏi textbox kia (lost focus) thì báo lỗi

Vì mong muốn ngóng không giống nhau này, buộc phải bug vì chưng tester report đã bị khước từ với lý do “tư liệu không trình bày đề xuất kia chưa hẳn là bug!”

Thêm nữa thì, sau khoản thời gian chứng thực với BA (Business Analyst – đối chiếu nghiệp vụ) thì biện pháp phát âm của tester là đúng. BA cập nhật SRS cùng Developer sẽ sửa lại code.

Xoay điện thoại cảm ứng Lúc đang upload hình lên server

Một ví dụ không giống đến từ chúng ta Hưng Ridoji – https://www.facebook.com/hung.ridoji

Chức năng chụp hình tiếp đến upload lên cloud. Các bước thao tác dẫn cho lỗi nlỗi sau:

Để điện thoại đứng (portrait), tiến hành chụp hìnhTrong thời gian hình đang được tự động hóa upload, thì luân chuyển 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à vận dụng thì gửi sang hiển thị dạng ngang

Developer phủ nhận đó là bug với nguyên do vô cùng đối chọi giản: ko người dùng (user) như thế nào nhưng trong lúc sẽ upload hình lại đi luân chuyển ngang điện thoại cảm ứng thông minh không còn áh. User cần đợi cho đến lúc nó upload thành công thì mới có thể chuyển phiên điện thoại.

Không luật mật khẩu đăng nhập new buộc phải khác mật khẩu cũ

Và đây một ví dụ có tương đối nhiều tester đã có lần gặp

Tester: bắt bug trong screen thay đổi password vì chưng nó có thể chấp nhận được password mới GIỐNG password cũ.Developer: Spec (specification) ko bảo password bắt buộc KHÁC password cũ, yêu cầu tớ chưa hẳn khám nghiệm.

Tester đề xuất xử trí thay nào?

Trong ngôi trường thích hợp dev không gật đầu đó là bug, cùng không đồng ý (reject) thẳng tay (update con bug chính là invalid) thì tester đề xuất có tác dụng gì? Và bao gồm đề xuất tester luôn đúng không?

*
Một ví dụ Invalid Bug

quý khách rất có thể xem cụ thể về lỗi này ở chỗ này https://jira.atlassian.com/browse/JSWCLOUD-21697

Đầu tiên chúng ta cùng các thành viên trong team cải tiến và phát triển ứng dụng rất cần phải hiểu rõ quan niệm thế nào thì được Call là BUG. Và ngôi trường hợp làm sao thì chưa hẳn là bug (NAB – Not a Bug, hoặc invalid bug)

Nlỗi cầm làm sao thì được call là bug?

Tạm dịch theo một tư tưởng trên wiki. Software Bug (lỗi phần mềm) là một lỗi, khiếm kmáu, hoặc sai vào chương trình máy tính xách tay hoặc khối hệ thống làm cho nó tạo nên công dụng không nên hoặc không như ước ao đợi, hoặc hành xử Theo phong cách không như ý đị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 lớn produce an incorrect or unexpected result, or khổng lồ behave in unintended ways.

vì vậy, có thể nói chưa hẳn dịp làm sao trong tài liệu diễn đạt thử khám phá cũng hồ hết biểu lộ không còn thảy hầu hết trường thích hợp có thể xẩy ra. Thường tư liệu chỉ mô tả các điều người tiêu dùng (hoặc PM, BA) nghĩ rằng cần được diễn đạt.

Có số đông điều quá đỗi bình thường, cần quý khách cho là không xứng đáng để nói, ví dụ như: Màn hình singin, thì cho dù người tiêu dùng ko miêu tả chi tiết, bọn họ cũng hiểu đúng bản chất, nó phải tất cả checkbox ‘Remember me’ (ghi ghi nhớ đăng nhập cho lần sau) với link ‘Forgot Password’ (thay đổi mật khẩu).

Dường như, nhiều khách hàng, bởi vì ko rành hoặc không đề cập cụ thể, nên những lúc ghi thử khám phá mang đến màn hình hiển thị Tạo thông tin tài khoản, thì không biểu hiện chi tiết số lượng hoặc loại cam kết từ bỏ được phnghiền nhtràn vào ô ‘Tên khách hàng hàng’

*

Vậy, nhằm tách hầu như bất đồng, những trường hợp trớ trêu, hay gần như tranh cãi xung đột ko xứng đáng tất cả vào nội cỗ nhóm, hoặc với quý khách hàng thì nhóm của công ty cùng quý khách phải thỏa thuận hợp tác trước phạm vi diễn đạt trong tư liệu. Những thử dùng đó là cơ phiên bản tốt chi tiết? Phần làm sao thì đề nghị tuân thủ nghiêm ngặt theo biểu đạt trong tận hưởng, trường phù hợp nào thì team trường đoản cú quyết định? Tương từ điều này, thì bạn cũng cần có hình thức ngầm vào đội, ngôi trường phù hợp nào thì post bug, trường thích hợp làm sao thì Q&A hoặc dạng khác ví như Improvement, Enhancement (khuyến nghị cải tiến).

⁠Ngoài ra, đối với những team gia công ứng dụng (outsourcing), cthị xã chiếc như thế nào là bug, chiếc nào là thay đổi từng trải, kinh nghiệm new, giỏi chiếc như thế nào làm ngay, đã có tác dụng sau, v.v… thì PM vẫn bàn với khách hàng. Hai bên đang đề xuất thống độc nhất vô nhị cùng nhau. Vì nó tác động mang lại tiền tài cùng thời gian xong xuôi thành phầm. Đó cũng là lý do Dev với PM tuyệt phủ nhận bug của tester do rất nhiều ngôi trường vừa lòng kia ko nằm trong phạm vi biểu lộ của tận hưởng dù nó hợp lý.

Nếu bạn kiểm thử thừa vượt phạm vi của những hiểu biết thì sao?

Ví dụ như, lúc quý khách hàng ko từng trải phải demo bên trên IE11, mà lại bạn lại demo với vạc hiện tại chục lỗi bên trên kia, trong những lúc đó phần đa lỗi này sẽ không xẩy ra trên Chrome.

Nếu bạn cố gắng thuyết phục Dev yêu cầu fix, hoặc trong một vài team thì tester cực kỳ “quyền lực” nên Dev đề nghị tuân theo thì sao? Nếu vấn đề này xẩy ra, thì người sử dụng sẽ rất chuộng. Bạn sẽ làm cho quý khách bằng lòng, với bạn cũng hợp ý cái tôi của bạn dạng thân vày Dev vẫn “nghe theo lời các bạn.” Nhưng team của người sử dụng được được gì từ chuyện này? cũng có thể, Dev yêu cầu làm thêm giờ đồng hồ nhằm giải pháp xử lý phần lớn “lỗi vặt” này? (Mình Gọi là lỗi lặt vặt do nó ko được mô tả trong tư liệu mà lại bản thân suy nghĩ người dùng cuối sẽ không còn ưa thích, hoặc nó làm cho hệ thống trsống bắt buộc không chuyên nghiệp.) Nhiều lỗi tương quan đến hiện trên những trình xem xét, vật dụng cầm tay khác nhau sẽ rất lâu để tinh chỉnh và điều khiển. Đôi khi đẹp mắt trên trình chu đáo này cơ mà lại không được sinh hoạt trình phê duyệt không giống.

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 team bạn gồm dư thời hạn để giải pháp xử lý phần đông vấn đề kia thì nên cần làm để bọn họ gồm phần mềm triển khai xong rộng, chuyên nghiệp hóa cùng giỏi rộng, thậm chí một trong những trường vừa lòng chúng ta thấy nó “cách xử trí thông minh” hơn trong mắt người tiêu dùng. Thường đó là gần như team làm sản phẩm đến bao gồm bọn họ. Còn phần nhiều các nhóm outsource sẽ không có tác dụng như thế. Họ sẽ tiết kiệm ngân sách thời gian, nhằm triệu tập làm cho phần lớn sản phẩm khách hàng kinh nghiệm. Đối cùng với họ, thời hạn dành riêng để giải pháp xử lý đều trang bị “râu ria” đó là ở trong sản phẩm xa xỉ.

Chúc bạn một ngày giỏi đẹp!