Phát hiện lỗi đã quan trọng nhưng log một lỗi để không ăn reject lại càng là mục tiêu quan trọng không kém. Bắt Bug Dạo cũng đang từng chịu cảnh log bug xong thì lại ngồi ăn Reject. Thấu hiểu nỗi đau, chúng tôi mang tới bài viết dưới đây để phân loại các loại reject cùng cách phòng chống.
- 1. Ăn reject do log bug vào phần OOS
- 2. Ăn reject do cách log lỗi không đạt yêu cầu
- 3. Reject do log trùng các bug đã được log trực tiếp
1. Ăn reject do log bug vào phần OOS
Một trong những nguyên nhân phổ biến nhất khi bạn bị ăn reject đó là việc log bug vào phần không được phép kiểm thử hay còn gọi là OOS (Out of scope). Lý do chủ yếu khiến các bạn ăn reject do log vào phần OOS là không chịu đọc các phần mô tả trong tab “Overview”, đặc biệt là phần Out of scope. Đây là phần chứa thông tin chủ yếu về các vùng bạn không cần test cũng như không được phép log bug.
Các phòng chống: Đơn giản là đọc toàn bộ trông tin trong tab Overview, do TestIO không có quy định nào cho khách hàng về việc mô tả thế nào sao cho chuẩn xác cũng như đúng các vùng cần được mô tả, nên các mô tả OOS sẽ nằm rải rác ở khắp mọi nơi.
- Out of scope: Phần mô tả trực tiếp đến các vùng không thực hiện
- Additional requirements: Mô tả bổ xung cũng có thể chứa các phần liên quan tới phần không thực hiện test
- Test these features: Trong từng tính năng khách hàng cũng có thể mô tả các phần nhỏ mà tester không được test.
Đọc kỹ các phần trên sẽ giúp bạn chống được các trường hợp bị reject do out of scope
2. Ăn reject do cách log lỗi không đạt yêu cầu
Giờ bạn là greenhorn, hãy tập dần để mô tả lỗi theo đúng tiêu chuẩn, các bạn có thể tham khảo link hướng dẫn của Bắt Bug Dạo tại đây. Ngoài các yêu cầu cơ bản của TestIO, tuỳ từng cycle mà khách hàng có yêu cầu cho việc log lỗi, các bạn cần chú ý kỹ phần yêu cầu này. Các yêu cầu này thường được mô tả trong tab “Ovewview” phần “Additional information”

Hãy tuân thủ các thông tin yêu cầu này nếu không bạn có thể bị reject nếu gặp ông team lead khó tính.
3. Reject do log trùng các bug đã được log trực tiếp
Ở đây mình chia làm 2 phần đó là Trùng trực tiếp và trùng gián tiếp
3.1 Trùng trực tiếp
Đây là lỗi mà bạn log giống y xì các lỗi mà tester khác đã log trong phần Know bug hoặc trong cycle hiện tại. Để tránh được các lỗi này thì bạn có thể tham khảo bài viết này.
3.2 Trùng gián tiếp
Lỗi bạn log trông sơ qua có vẻ là khác với lỗi của tester khác đã log nhưng với việc phân tích của TL thì lỗi đó được coi là cùng nguyên nhân với lỗi đã log trước đó. Dưới đây là một số ví dụ tiêu biêu
- Lỗi GUI: cùng một style control nhưng ở 2 màn hình khác nhau thì chỉ được log 1 lỗi

- Lỗi content: cùng một tool tip bị thiếu nội dung ở nhiều màn hình khác nhau thì chỉ log một 1 lỗi. (Cái này thì tuỳ vào TL nhé Andre vẫn chấp nhận lỗi content tương tự như vậy)
- Lỗi functional: có 2 kiểu
- Lỗi gặp ở control A tại màn hình 1 thì cũng control đó tại màn hình 2 cũng không được phép log bug mới.
- Lỗi xẩy ra ở control A đã được log nhưng bạn lại thấy một lỗi khác có hiện tượng khác với lỗi đã log. Tuy nhiên, với TL thì control đã có lỗi thì không thể log thê lỗi mới. Đây là trường hợp phổ biến nhất mà anh chị em nhà mình hay mắc phải. Đến với một số ví dụ nhé
- Lỗi 1: Price slider không thể kéo đến giá trí tối đa, lỗi 2: Price slider có thể kéo giá trị max nhỏ hơn giá trị min.
- Lỗi 1: Paste text vào search box không hiển thị suggestion list, lỗi 2: Dùng voice text nói vào search box thì không hiển thị suggestion list.
- Lỗi 1: Sắp xếp theo giá từ cao tới thấp thì sản phẩm hiển thị lung tung. Lỗi 2: Sắp xếp theo thứ tự từ thấp tới cao thì sản phẩm hiển thị lung tung
Để phòng chống các lỗi log gián tiếp này thì các bạn nên
- Hãy tìm hiểu các lỗi có cùng control với lỗi mình phát hiện.
- Nếu thấy control đó cũng xuất hiện lỗi tương tự rồi thì hãy đánh giá theo các tiêu chí sau
- Nguyên nhân gốc rễ của hiện tượng lỗi có giống nhau không (ví dụ như cùng do so sánh về giá, cùng do kéo price slider)
- Hiện tượng lỗi có giống nhau không (Sắp xếp hỗn loạn, tính năng không thực hiện được, cùng một loại control được sử dụng ở nhiều nơi)
Việc quyết định từ bỏ lỗi mình vừa phát hiện chưa bao giờ là dễ dàng nhưng nếu nếu bạn đặt mục tiêu chất lượng cao hơn thì hãy bỏ thời gian tư duy về nguyên nhân của lỗi. Sau đó sẽ quyết định về việc giữ lại lõi hay xoá bỏ nó. Đối với mình, nếu lỗi từ 6 euro trở lên thì mình có thể chấp nhận rủi ro bị reject, thâp hơn thì sẽ sẵn sàng xoá.
Hi vọng sẽ giúp đỡ được các bạn giảm thiểu việc ăn reject không đáng có từ đó nâng cao được điểm quality của bản thân.