Những lý do bug bị từ chối và cách khắc phục

Bị từ chối bug - Đây là vấn đề phổ biến nhất mà bất cứ Tester nào cũng phải đối đầu ít nhất 1 lần trong nghề. Nó có thể xảy ra ở bất cứ đâu và bất cứ dự án nào. Phần lớn, tester và developer đều muốn chứng tỏ bug đó là nằm ở phía bên kia.Vậy nên trong bài viết này tôi muốn chia sẻ những điểm mấu chốt , những lý do vì sao Bug bị từ chối.

1.1 Ước lượng thấp mức độ nghiêm trọng của việc báo cáo lỗi Theo wiki: "Kiểm thử phần mềm là quá trình test được tiến hành để cung cấp cho các bên liên quan thông tin về chất lượng của sản phẩm hoặc dịch vụ đang được test" -> Công việc của tester là cung cấp càng nhiều thông tin hiện tại về hệ thông cho khách hàng càng tốt. Do đó tester không chỉ tìm kiếm bug mà còn phải chú tâm đến việc báo cáo bug

• Managers: Cần báo cáo bug để Manager hiểu tổng quan về tình trạng của hệ thống giúp họ có thể lên kế hoạch cho công việc hoặc thực hiện một quyết định nào đó.
• Developers: Cần báo cáo bug để Developers có thể khắc phục sự cố tương ứng.
• Team: Cần báo cáo bug để các tester khác tham khảo, tìm kiếm để biết thêm về hệ thống và tránh trùng lặp trước khi gửi bug. --> Việc báo cáo bug là vô cùng quan trọng để các thành viên khác có thể hoàn thành công việc đúng cách

1.2 Báo cáo bug không hợp lệ

• Nguyên nhân: + Bạn cho rằng đó là bug nhưng đó lại là cách hệ thống được thiết kế + Bug đã được báo cáo trước đó -> đây là công việc hoàn toàn lãng phí

1.3 Không thể tái hiện bug Trong khi log bug, tester đã không chú ý đến tần suất của bug để đảm bảo xem bug đó là lặp đi lặp lại hay chỉ xuất hiện một cách ngẫu nhiên. Với những bug xảy ra ngẫu nhiên thì tần suất tái hiện rất thấp và những bug như vậy, khi không thể tái hiện lại thì sẽ bị từ chối.

1.4 Tester hiểu sai yêu cầu Nếu tester không nắm rõ được yêu cầu và chứng minh bug đó nằm trong yêu cầu thì bug sẽ bị từ chối

1.5 Phần mềm không có yêu cầu rõ ràng Đối với những chức năng, ứng dụng, sản phẩm mà yêu cầu không được làm rõ, mọi người đều tự do chấp nhận yêu cầu theo cách riêng của mỗi người và điều này dẫn đến những giả định cá nhân khác biệt. Khi tester thấy không hài lòng với kết quả nhận được và thực hiện log bug đó thì kết quả là bug đó cũng sẽ bị từ chối.

1.6 Mô tả không chính xác về bug Khi dev không thể hiểu, không thể tái hiện được bug vì nội dung bug đã không được mô tả chính xác và yêu cầu chi tiết không được làm rõ. Những bug như vậy cũng sẽ bị từ chối.

2.1 Mô tả bug Làm chi tiết và cẩn thận các bước sau: a, Tóm tắt bug Có rất nhiều bug cần xem xét nên hầu hết các Dev sẽ đọc tóm tắt điều đầu tiên khi họ xem lại bug. Vì vậy, cần tập trung vào các tóm tắt để làm cho nó ngắn gọn và súc tích. Tóm tắt sẽ cho biết chính xác vấn đề và điều kiện như thế nào. Điều này rất quan trọng. VD: Bug: - "Sự cố hệ thống" -> "Hệ thống gặp sự cố khi người dùng đăng nhập và đăng xuất". Bug: - "Camera không hoạt động đúng cách" -> "Việc máy ảnh bị mờ khi chụp ảnh trong phòng tối"

Tất nhiên, bạn không có cách nào để nói tất cả mọi thứ trong bản tóm tắt bug và đó là lý do tại sao bạn cần những điều sau. . .

b,Mô tả bug Mô tả bug rất quan trọng vì đó là nơi Dev sẽ đi vào xem xét các chi tiết và khắc phục sự cố. Bạn phải mô tả vấn đề chính xác và rõ ràng. Đọc lại và làm theo các bước của bạn một lần nữa trước khi gửi đi

• Nội dung trong 1 bản mô tả bug: + Điều kiện tiên quyết: Mô tả những điều kiện cần để tái hiện bug (hệ điều hành cụ thể, phiên bản trình duyệt, thiết bị hỗ trợ, mạng, vv) Điều này sẽ đảm bảo rằng mọi người có môi trường và điều kiện cần thiết để tái hiện bug + Các bước để tái hiện: Mô tả từng bước để tái hiện vấn đề. Không cần phải viết dài mà nên viết một hướng dẫn rõ ràng, từng bước để đưa mọi người đến đúng vấn đề. Tuy nhiên: Cũng không cần phải viết quá chi tiết
  VD: 1. Nhấp nút Start 2. Vào All Program 3. Nhấp chuột vào [Program Name] -->Thay vào đó: Khởi chạy [Tên Chương trình] Ngoài ra, ghi cụ thể những nơi thực hiện. Không để người đọc phải đoán + Kết quả mong đợi: ghi cụ thể, chính xác những gì thấy được và giải thích lý do bạn cho đó là bug.

c,Số lần suất hiện bug/ Total số lần thực hiện d,Ver soft dùng để test (nếu trong trường hợp test mobile, app..) e, Check ở Các môi trường khác có xuất hiện bug không? Số lần xuất hiện/ tổng số lần thực hiện. f,Data dùng để test g,Chụp hình ảnh , quay video lại làm bằng chứng

2.3 Ngôn ngữ viết report bug Một trong những lý do bug bị từ chối là do không giỏi ngôn ngữ viết report bug. Đây là một lý do hợp lý, nhưng không thuyết phục hoàn toàn ->Nên sử dụng các từ tiếng Anh đơn giản (càng đơn giản càng tốt) để mô tả vấn đề.

• Nếu có thể tìm thấy một từ đơn giản, nhưng có cùng ý nghĩa, hãy sử dụng nó. Bạn cũng có thể tạo ra một Hướng dẫn chung, đơn giản những gì bạn muốn gọi. Trong đó mô tả thuật ngữ và định nghĩa chung được sử dụng trong các dự án của bạn. Bằng cách này, tất cả các thành viên trong nhóm sẽ đều hiểu một cách chính xác.

2.4 Cung cấp thêm thông tin về bug Cung cấp thêm thông tin về bug để giúp Dev hiểu rõ hơn về bug đó

• Có thể gửi một email riêng cho các nhà quản lý để thông báo về lỗi nếu lỗi là rất quan trọng và cần phải được giải quyết ngay lập tức
• Gắn các tập tin, hình ảnh chụp màn hình hoặc video của bug.
• Nếu bug là về sự sụp đổ của hệ thống, thì có thể cung cấp thông tin workaround để giúp người sử dụng khắc phục vấn đề và tiếp tục công việc.
• Nếu biết nguyên nhân gốc rễ của sự cố, có thể đề xuất các giải pháp kỹ thuật cho các nhà phát triển.

2.5 Phải có chứng cứ rõ ràng Tester muốn chỉ ra lỗi của Dev trong quá trình xây dựng phần mềm thì phải có chứng cứ rõ ràng. Bug là lỗi mà phần mềm hoạt động không như mong đợi của khách hàng. Thế nên nếu Dev không công nhận bug thì cần phải đưa ra các tài liệu liên quan để chứng thực được cái mình nói có cơ sở. Cụ thể là Requirement document, Detail Design, Test spect, Test case,…

2.6 Ngoài ra

• Đặt câu hỏi với Dev để hiểu rõ nguyên nhân, không nên tuyên bố hay khẳng định đây là bug không cần bàn cãi
• Cố gắng nghiên cứu tìm hiểu trước khi hỏi Dev
• Nhờ những Dev khác có kinh nghiệm xem qua bug đã bị từ chối
• Đôi khi Bug bị dev reject vì lý do requirement không mô tả. Đây chính là trường hợp requirement bị thiếu. Nếu bug của bạn có liên quan tới chức năng business nó có thể được chấp nhận hoặc reject bởi 1 BA. Thì bạn nên đồng tình với nó.

Để tránh tình trạng bug bị reject thì Tester cần phải hoàn thiện rất nhiều kỹ năng

• Hiểu biết các kỹ thuật test, kỹ thuật tạo test design : có thế test không áp dụng kỹ thuật, nhưng nếu biết về các kỹ thuật test thì sẽ là chìa khóa để bạn làm tốt nhất và tự tin với công việc của mình
• Có khả năng research & development cho công nghệ mới : công nghệ thì luôn thay đổi, ko chỉ Developer mà bạn làm Tester cũng phải biết về nó
• Kỹ năng giao tiếp :phải luôn giao tiếp với Dev, với PM, thậm chí cả với khách hàng , vậy cần làm thế nào để làm hài hòa mọi thứ nhưng vẫn không quên nhiệm vụ tìm bug của mình
• Khả năng chịu áp lực
• Tính kiên nhẫn : điều này là cực kỳ cần thiết

***Nguồn tham khảo : http://www.asktester.com/bug-report/ https://vntesters.com/ban-se-lam-gi-khi-bug-ban-bao-cao-bi-tu-choi/