10 lý do tại sao lỗi của bạn bị từ chối . Là một QA/tester bạn sẽ làm gì trong trường hợp đó!

Nếu như một dự án không có sự tranh luận của các developer và các tester chỉ vì những lý do hết sức tầm thường, đơn giản hay chỉ vì cái tôi cá nhân quá lớn của từng người, tôi chắc dự án đó sẽ thành công. Phần lớn, tester và developer tranh luận chỉ vì một lý do đơn giản đó là lỗi (bug) của sản phẩm. Ai cũng muốn chứng tỏ lỗi đó là nằm ở phía bên kia. Thế nhưng nếu chúng ta bình tĩnh thì sẽ thấy rằng bug này thuộc cùng một sản phẩm mà cả hai bên đang cố gắng hoàn thiệ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. Hiểu sai yêu cầu:

Vì lý do nào đó, nếu bạn không hiểu các yêu cầu đúng cách, bạn chắc chắn sẽ tìm ra các yêu cầu sai trong việc thực hiện thực tế mà cuối cùng lỗi đó sẽ bị từ chối.

Ví dụ thực tế : Sau khi thử nghiệm một công thức, bạn thấy rằng nó là vô vị như việc muối không được bổ sung vào món ăn vậy, nhưng bạn không biết muối lẽ ra phải được thêm vào thời gian nào công đoạn nào nếu không nó có thể ảnh hưởng đến công thức tổng thể.

2. Cách thực hiện yêu cầu

Sau cuộc thảo luận trước đó ,bạn đã nhận thức được rằng yêu cầu cụ thể sẽ được thực hiện theo con đường XYZ . Nhưng trong khi coding/implement, Developer tìm thấy nó đã không thể đi theo con đường XYZ và do đó, họ đã đi theo con đường ABC và không thông báo cho bạn. Cuối cùng, bạn sẽ báo lỗi khi bạn tìm thấy những yêu cầu không được thực hiện theo cách nó đã được thảo luận.

Ví dụ thực tế : Khi bạn đi may một chiếc áo sơ mi và bạn được yêu cầu mặc thử, tuy nhiên bạn đã từ chối nó vói lý do rằng bạn không tìm thấy cúc áo trên nó. Khi người thợ may giải thích rằng việc đưa vào các cúc áo trên mặt trước sẽ có tác động tới tổng thể của chiếc áo sơ mi vì lý do đó ông đã đặt nó bên trong phía trước mặt áo, bạn chắc chắn sẽ chết lặng.

3. Yêu cầu không rõ ràng

Khi không có các yêu cầu rõ ràng , tất cả mọi người được tự do giả định các yêu cầu theo cách riêng của mình và điều này dẫn đến giả định ở mức độ cá nhân. Khi bạn thấy rằng giả định cá nhân là không hài lòng, bạn đánh dấu nó như là một lỗi.

Ví dụ thực tế : Bạn cần phải vẽ 1 chiếc xe đạp. Sau khi giáo viên thông báo cô mong đợi học sinh sẽ vẽ xe đạp 2 bánh . Sau nửa giờ, khi cô kiểm tra bản vẽ của tất cả mọi người, cô không tìm được ai phù hợp với kỳ vọng của mình. Mọi người đều mơ hồ trong cách nghĩ riêng của họ và kết quả là họ đã vẽ xe đạp 3 bánh, xe đạp cho e bé, Xe nhiều bánh và có cả xe lăn...

4. Thay đổi yêu cầu

Một ví dụ khác của sự hiểu lầm, hầu hết những lần mà người kiểm thử không được truyền đạt về việc thay đổi yêu cầu(CR) cho nên rất nhiều lỗi sẽ được báo cáo và cuối cùng bị từ chối.

***Ví dụ thực tế : *Bạn có chắc chắn sẽ từ chối bánh sandwich khi bạn thấy nó dùng bánh mì mật ong chứ không phải bánh chuối mà bạn vẫn thường ăn. Bạn nên biết rằng cửa hàng đã thay đổi các loại bánh mì theo ngày và việc này bạn có thể check trên điện thoại và tất nhiên người bán hàng không thấy cần phải chia sẻ nó với bạn.

5. KHông hiểu về phạm vi test

Trong khi test, bạn bắt đầu mà không xem xét là có thể test tại thời điểm nào, phạm vi ra sao (tất cả hoặc không phải là ở tất cả theo tiêu chuẩn sản phẩm). Điều sẽ dẫn bạn trở thành một nạn nhân của sự từ chối những lỗi mà bạn phát hiện được.

Ví dụ thực tế: Bạn có nghĩa vụ phải quét một góc phòng . Tuy nhiên bạn lại nhìn thấy một mớ hỗn độn trong các khu vực khác trong phòng, bạn có chắc chắn mình sẽ bỏ qua các khu vực này và chỉ tập trung vào nghĩa vụ thực tế của mình?

7. Sử dụng các dữ liệu kiểm thử

Sử dụng dữ liệu kiểm thử không đúng với yêu cầu.

***Ví dụ thực tế : *Moi người đểu biết máy tính cầm tay rất hữu ích trong việc tính toán các con số. Tuy nhiên điều gì sẽ xảy ra nếu bạn cố gắng thêm các ký tự đặc biệt vào các phép tính. Và thật bất ngờ máy tính có thể tính toán được. Bạn nghĩ rằng đó là không đúng vì nó chỉ có thể xử lý được các con số. Kết luận này có thật đúng không?

8. Trùng lặp lỗi

Bạn đã không tìm hiểu lỗi trước đó và báo cáo lỗi(bug) mà đã có người báo cáo/ghi chép rồi.

Ví dụ thực tế: Nếu bạn là một nhân viên hỗ trợ khách hàng thì chắc chắn bạn sẽ không cảm thấy hạnh phúc khi mà nhận được nhiều khiếu nại gọi cho cùng một sản phẩm từ mỗi thành viên trong gia đình khi sử dụng nó.

9. Mô tả lỗi không chính xác

Developer sẽ không thể tái hiện/điều tra lỗi Khi không thể hiểu được những gì bạn đang cố gắng để truyền đạt thông qua các báo cáo lỗi, họ không tìm thấy mô tả thích hợp và cần thiết chi tiết và độ quan trọng của lỗi . Và chắc chắn họ sẽ trừ chối bug của bạn.

Ví dụ thực tế : Nếu bạn muốn sử dụng một ứng dụng hoặc một sản phẩm nào đó bạn nên chắc chắn đọc kĩ hướng dẫn sử dụng để có thể sử dụng đúng cách. Đừng giả định cách hiểu, cách sử dụng giả định của bản thân.

10. Tái hiện lỗi và tấn suất lỗi

Miêu tả chi tiết lỗi trong khi báo cáo ngoài nội dung chi tiết của lỗi thì 1 phần quan trọng khác là viết rõ tần suất xảy ra lỗi để có thể tiết kiệm thời gian làm việc của cả đội trong việc tái hiện , tìm nguyên nhân và fix lỗi.

Kết luận

**Chúng ta dù biết hay không biết, chúng ta mang cái tôi cá nhân vào công việc. Chúng ta luôn cho rằng chúng ta làm tốt nhất và không nghi ngờ gì về điều đó cả. Nhưng mà điều đó không có nghĩa là mọi thứ tốt đẹp như chúng ta nghĩ.  Nếu một developer cho rằng những bug của các module là vớ vẩn, tầm thường hay chỉ là một ý tưởng không đâu thậm chí chỉ là làm cản trở dự án. Developer cho rằng tester không hiểu chính xác sản phẩm bởi vì họ là người làm ra sản phẩm, họ đã làm rất tốt. Đó chẳng qua là cái tôi cá nhân mà thôi, cái tôi quá lớn làm họ không nhận đó là một bug. Ngược lại, tester khi thấy bug mà họ đã đưa ra bị từ chối, họ cảm thấy bị tổn thương, họ nghĩ rằng developer không muốn giải quyết vấn đề mà họ đã đưa ra. Và như vậy cả những ý tưởng mới, cả những bug của sản phẩm sẽ dần ít đi và tất nhiên chất lượng của dự án bị giảm xuống. Hãy nhìn bao quát, tổng thể và tập trung độ ưu tiên đúng cho những công việc thực sự cần thiết. Dự án mới là cái quan trọng hơn. Hãy cất cái tôi của mình đi, developer va tester cùng nhau chia sẻ, thảo luận và cùng hiểu đúng vấn đề hơn. **