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?

Video ko auto chạy sau thời điểm tắt chuông báo thức

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

Lỗi này được biểu lộ theo hiệ tượng (format) nhỏng một bug report hay gặp:

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

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

Kiểm tra tính đúng theo lệ của những quý hiếm nhập lệ textbox

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

Trường phù hợp bình chọn (validate) tính vừa lòng lệ của quý hiếm được nhtràn lên (input) một ô trên màn hình hiển thị (text field, textbox) nhưng mà tư liệu (SRS – software requirement specification) không trình bày là đã đánh giá vào thời điểm nào (trigger).

Thời điểm khám nghiệm với báo lỗi

Vì mong muốn đợi không giống nhau này, yêu cầu bug vì chưng tester report đã bị lắc đầu với lý do “tài liệu không biểu đạt buộc phải đó không hẳn là bug!”

Thêm nữa thì, sau thời điểm xác thực với BA (Business Analyst – phân tích nghiệp vụ) thì biện pháp phát âm của tester là đúng. BA cập nhật SRS với Developer đang sửa lại code.

Xoay điện thoại cảm ứng thông minh lúc sẽ upload hình lên server

Một ví dụ khác đế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ối upload lên cloud. Các bước thao tác làm việc dẫn đến lỗi nhỏng sau:

Developer lắc đầu đó là bug cùng với nguyên nhân siêu đối kháng giản: không người dùng (user) nào mà trong những lúc sẽ upload hình lại đi xoay ngang điện thoại thông minh hết áh. User đề xuất đợi đến khi nó upload thành công thì mới luân phiên điện thoại cảm ứng.

Không lao lý mật khẩu đăng nhập new yêu cầu không giống mật khẩu cũ

Và trên đây một ví dụ có rất nhiều tester đã từng có lần gặp

Tester buộc phải cách xử lý ráng nào?

Trong trường phù hợp dev ko gật đầu đồng ý chính là bug, cùng khước từ (reject) mạnh tay (cập nhật nhỏ bug sẽ là invalid) thì tester yêu cầu có tác dụng gì? Và tất cả đề nghị tester luôn đúng không?

Quý khách hàng hoàn toàn có thể xem cụ thể về lỗi này tại chỗ này https://jira.atlassian.com/browse/JSWCLOUD-21697

Trước hết chúng ta cùng những thành viên vào team trở nên tân tiến ứng dụng cần được làm rõ khái niệm thế nào thì được Gọi là BUG. Và trường hòa hợp như thế nào thì chưa phải là bug (NAB – Not a Bug, hoặc invalid bug)

⁠

Như vậy nào thì được điện thoại tư vấn là bug?

A software bug is an error, flaw or fault in a computer program or system that causes it khổng lồ produce an incorrect or unexpected result, or khổng lồ behave sầu in unintended ways.

Như vậy, nói theo cách khác chưa hẳn lúc như thế nào trong tư liệu biểu thị từng trải cũng đều biểu lộ hết thảy đều ngôi trường hợp hoàn toàn có thể xẩy ra. Thường tài liệu chỉ trình bày mọi điều quý khách (hoặc PM, BA) cho là cần phải trình bày.

Có mọi điều thừa đỗi thông thường, yêu cầu quý khách nghĩ rằng không đáng để đề cập, ví dụ như: Màn hình singin, thì dù quý khách hàng không bộc lộ cụ thể, họ cũng hiểu rằng, nó đề nghị có checkbox ‘Remember me’ (ghi ghi nhớ singin đến lần sau) và liên kết ‘Forgot Password’ (đổi mật khẩu).

Hình như, các quý khách hàng, vì ko rành hoặc không nói cụ thể, nên những lúc ghi thử khám phá mang đến screen Tạo tài khoản, thì ko biểu hiện cụ thể số lượng hoặc các loại ký từ bỏ được phnghiền nhập lệ ô ‘Tên khách hàng’

Vậy, để tránh phần đông sự không tương đồng, các trường hợp trớ trêu, tuyệt các bất đồng quan điểm không đáng có trong nội cỗ nhóm, hoặc với quý khách thì nhóm của chúng ta và khách hàng yêu cầu thỏa thuận hợp tác trước phạm vi trình bày vào tư liệu. Những đề nghị đó là cơ bản tốt đưa ra tiết? Phần làm sao thì đề nghị tuân thủ nghiêm khắc theo biểu lộ trong tận hưởng, ngôi trường đúng theo làm sao thì team tự quyết định? Tương từ bỏ như vậy, thì các bạn cũng cần phải có nguyên lý ngầm vào đội, ngôi trường phù hợp nào thì post bug, ngôi trường vừa lòng như thế nào thì Q&A hoặc dạng khác ví như Improvement, Enhancement (khuyến cáo cải tiến).

⁠Hình như, đối với hầu hết nhóm gia công phần mềm (outsourcing), cthị trấn loại như thế nào là bug, dòng làm sao là biến hóa từng trải, trải đời mới, tuyệt chiếc như thế nào có tác dụng tức thì, vẫn làm sau, v.v… thì PM sẽ bàn với quý khách. Hai mặt vẫn phải thống nhất cùng nhau. Vì nó ảnh hưởng đến tiền tài cùng thời gian xong sản phẩm. Đó cũng là lý do Dev với PM giỏi lắc đầu bug của tester vì phần đa trường vừa lòng đó ko bên trong phạm vi biểu hiện của thưởng thức dù nó phù hợp.

Nếu bạn kiểm thử vượt vượt phạm vi của hưởng thụ thì sao?

lấy ví dụ như, Khi khách hàng không đề xuất đề nghị chạy thử trên IE11, tuy vậy bạn lại thử nghiệm cùng phân phát hiện tại chục lỗi trên đó, trong lúc đó những lỗi này sẽ không xảy ra trên Chrome.

Xem thêm: Gia Tộc Giàu Có Trương Mỹ Lan Là Ai, Trương Mỹ Lan Là Ai

Nếu nhóm bạn bao gồm dư thời hạn nhằm xử trí rất nhiều vấn đề đó thì nên làm nhằm họ tất cả ứng dụng hoàn thiện hơn, chuyên nghiệp hóa cùng tốt hơn, thậm chí là một số trong những trường hòa hợp chúng ta thấy nó “cách xử trí thông minh” hơn vào đôi mắt người dùng. Thường sẽ là số đông đội làm cho thành phầm cho chủ yếu chúng ta. Còn phần nhiều những đội outsource sẽ không còn có tác dụng như vậy. Họ vẫn tiết kiệm thời gian, để triệu tập làm cho mọi đồ vật người sử dụng hưởng thụ. Đối cùng với bọn họ, thời hạn dành riêng nhằm giải pháp xử lý hầu hết sản phẩm công nghệ “râu ria” sẽ là ở trong hàng xa xỉ.