Đây không phải là lỗi!
Bạn có thể đã gặp câu hỏi: “Bạn sẽ làm gì khi nhà phát triển từ chối một lỗi bạn vừa tìm thấy vì tài liệu không mô tả lỗi đó?” Hoặc bạn có thể đã nghe câu:
Bài viết này mô tả một số ví dụ thực tế. Với điều này, hãy cùng tìm hiểu nguyên nhân và cách khắc phục. Bạn đang xem: Bạn sẽ làm gì khi nhà phát triển nói rằng lỗi của bạn không thể được sao chép?
Tài liệu không mô tả tình huống này
Lý do có thể nhất mà bạn nghe thấy khi tham gia nhóm thuê ngoài 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ề lỗi hoặc cái gọi là “lỗi không hợp lệ” đã được người kiểm tra tìm thấy (báo cáo lỗi = báo cáo lỗi) nhưng lập trình viên (nhà phát triển = nhà phát triển) không đồng ý. Những ví dụ này được tôi sưu tầm qua một bài viết trên facebook group Issf.vn vn (https://www.facebook.com/groups/issf.vnvietnam/)
Đối với một số ví dụ ngắn, tôi sẽ giải thích lại chúng để giúp những người thử nghiệm mới hình dung dễ dàng hơn
Không thể xem chi tiết thông báo
Đây là một ví dụ dành cho bạn – https://www.facebook.com/mine.nil.minion
Nhấp để đọc thông báo, nhưng không thể xem chi tiết của thông báo. dev nói rằng tài liệu không mô tả phần đó.
Chức năng hiển thị thông báo
Video không tự động phát khi báo thức kêu
Ví dụ về phí thu thập của bạn – https://www.facebook.com/hapithu
Lỗi này được mô tả ở định dạng báo cáo lỗi phổ biến:
Các bước để tái tạo lỗi:
Nhà phát triển đã từ chối lỗi này (loại từ chối – là lỗi không hợp lệ) bởi vì: video dừng không nhất thiết là lỗi. Ở đây, khách hàng không mô tả bất cứ điều gì buộc tôi phải sửa chữa (fix)
Kiểm tra tính hợp lệ của giá trị được nhập vào hộp văn bản
Một ví dụ khác về bạn yang yang – https://www.facebook.com/rose.thorn.11111
Một trường hợp kiểm tra (xác thực) cho tính hợp lệ của giá trị đầu vào (đầu vào) là một ô trên màn hình (trường văn bản, hộp văn bản) nhưng tài liệu (srs – Đặc điểm kỹ thuật yêu cầu phần mềm) không mô tả thời điểm nó được kiểm tra (kích hoạt) .
Thời gian để kiểm tra và báo cáo lỗi
Vì kỳ vọng khác biệt này, lỗi do người kiểm tra báo cáo đã bị từ chối với lý do “tài liệu không mang tính mô tả, vì vậy nó không phải là lỗi!”
Ngoài ra, sau khi xác nhận với ba (nhà phân tích kinh doanh), sự hiểu biết của người kiểm tra là đúng. Ba srs cập nhật và các nhà phát triển đã sửa mã.
Xoay điện thoại khi tải hình ảnh lên máy chủ
Một ví dụ khác về bạn hung ridoji – https://www.facebook.com/hung.ridoji
Chức năng chụp ảnh và tải lên đám mây. Các bước dẫn đến lỗi như sau:
Nhà phát triển phủ nhận đây là một sự nhầm lẫn vì một lý do đơn giản: không có người dùng (người dùng) nào lật úp điện thoại khi hình ảnh được tải lên. Người dùng phải đợi cho đến khi tải lên thành công trước khi quay điện thoại.
Mật khẩu mới chưa xác định phải khác với mật khẩu cũ
Đây là một ví dụ mà nhiều người thử nghiệm đã gặp phải
Người kiểm tra nên làm gì?
Người kiểm tra nên làm gì nếu nhà phát triển không đồng ý rằng đây là lỗi và từ chối nó hoàn toàn (cập nhật lỗi không hợp lệ)? Những người kiểm tra luôn đúng?
Bạn có thể xem chi tiết về lỗi này tại đây https://jira.atlassian.com/browse/jswcloud-21697
Trước tiên, bạn và một thành viên của nhóm phát triển phần mềm cần làm rõ lỗi bị cáo buộc. Trường hợp nào không phải là lỗi (nab – không phải lỗi hoặc lỗi không hợp lệ)
Lỗi là gì?
Được dịch sơ bộ từ định nghĩa trên wiki. Lỗi phần mềm là một lỗi, khiếm khuyết hoặc lỗi trong chương trình hoặc hệ thống máy tính khiến nó tạo ra kết quả không chính xác hoặc không mong muốn hoặc hoạt động theo cách không mong muốn. Xem thêm: chu khi buon 40 – game chú khỉ buồn 9
Lỗi phần mềm là các lỗi, khiếm khuyết hoặc trục trặc trong một chương trình hoặc hệ thống máy tính khiến nó tạo ra kết quả không chính xác hoặc không mong muốn hoặc hoạt động theo những cách không mong muốn.
Do đó, có thể nói rằng tài liệu mô tả yêu cầu không phải lúc nào cũng mô tả tất cả các trường hợp có thể xảy ra. Thông thường tài liệu chỉ mô tả những gì khách hàng (hoặc pm, ba) cho rằng cần được mô tả.
Một số điều quá phổ biến mà khách hàng coi là không đáng nói, ví dụ: màn hình đăng nhập, ngay cả khi khách hàng không mô tả chi tiết, chúng tôi hiểu nó phải có hộp kiểm ‘nhớ tôi’ (nhớ ghi lại trong lần sau) và liên kết “Quên mật khẩu” (đổi mật khẩu).
Ngoài ra, nhiều khách hàng do không quen hoặc không được đề cập chi tiết nên không mô tả chi tiết số lượng hoặc loại ký tự được phép có trong ô khi đăng ký tạo tài khoản. ‘Tên khách hàng’
Do đó, để tránh những bất đồng, tình huống châm biếm hoặc tranh chấp không cần thiết trong nhóm của bạn hoặc với khách hàng của bạn, nhóm của bạn và khách hàng nên thỏa thuận trước về phạm vi được mô tả trong tài liệu. cho dù. Những yêu cầu này là cơ bản hay chi tiết? Phần nào phải đúng như mô tả trong yêu cầu, và trong trường hợp nào thì nhóm đó quyết định? Ngoài ra, bạn cũng cần có các quy tắc ngầm trong nhóm, trường hợp nào thì đăng lỗi, trường hợp này là q & amp; a hoặc các hình thức khác như cải thiện, nâng cao.
Ngoài ra, đối với nhóm outsourcing, bug là gì, yêu cầu thay đổi là gì, yêu cầu mới là gì, hoặc làm gì bây giờ, làm gì trong tương lai, v.v … pm sẽ thảo luận với khách hàng. Cả hai bên phải đồng ý. Vì nó ảnh hưởng đến tiền bạc và thời gian hoàn thành sản phẩm. Đây cũng là lý do tại sao các nhà phát triển và quản lý dự án thường từ chối những sai lầm của người kiểm thử vì những tình huống này nằm ngoài phạm vi của mô tả yêu cầu, ngay cả khi nó hợp lý.
Điều gì sẽ xảy ra nếu thử nghiệm nằm ngoài phạm vi?
Ví dụ: khi khách hàng không yêu cầu kiểm tra trên ie11, nhưng bạn kiểm tra trên ie11 và tìm thấy hàng tá lỗi không xảy ra trên chrome.
Nếu bạn đang cố gắng thuyết phục nhà phát triển sửa lỗi hoặc người kiểm tra rất “quyền lực” trong một số nhóm nhất định, thì nhà phát triển phải tuân theo? 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 hài lòng khách hàng và bạn thỏa mãn cái tôi của mình bởi vì các nhà phát triển “lắng nghe bạn”. Nhưng nhóm của bạn nhận được gì từ nó? Phải chăng, các lập trình viên phải làm việc thêm giờ để đối phó với những “lỗi” này? (Tôi gọi đó là một lỗi nhỏ vì nó không được mô tả trong tài liệu, nhưng tôi nghĩ người dùng cuối sẽ không hài lòng, hoặc nó sẽ làm cho hệ thống không chuyên nghiệp.) Nhiều lỗi liên quan đến kết xuất trong trình duyệt. Các thiết bị di động khác nhau cần thời gian để điều chỉnh. Đôi khi nó đẹp trong một trình duyệt nhưng không đẹp trong một trình duyệt khác.
Nếu nhóm của bạn có nhiều thời gian hơn để làm những việc này thì nên làm để chúng tôi có phần mềm hoàn thiện hơn, chuyên nghiệp hơn và tốt hơn, thậm chí trong một số trường hợp bạn sẽ thấy nó trong mắt người dùng hơn “xử lý thông minh “. Thường là các nhóm sản xuất sản phẩm của chính họ. Hầu hết các đội gia công phần mềm không làm điều này. Họ sẽ tiết kiệm thời gian và tập trung làm những gì khách hàng yêu cầu. Đối với họ, thời gian đối phó với những tên “mày râu” đó là một điều xa xỉ.
Chúc một ngày tốt lành!