Onboarding Test- Hướng dẫn cách viết bug report chuẩn theo Test IO

submit bug report

Viết một bug report chuẩn theo yêu cầu của Test IO luôn là một vấn đề khó khăn nhất của newbie khi mới tham gia nền tảng Test IO, do vậy bài viết này sẽ giúp các bạn hiểu hơn các mục trong bug report mà Test IO yêu cầu để giúp các bạn submit một bug report đạt tiêu chuẩn để Test IO chấp nhận.

 1. Form bug report của Test IO

Bug_form

Gồm các mục như sau:

  • Feature: Tính năng của sản phẩm mà lỗi xảy ra ( lựa chọn có sẵn và đọc trong mục overview)
  • Bug Type: Loại lỗi ( các bạn có thể xem bài viết chi tiết về loại lỗi tại đây )
  • Severity: Mức độ nghiêm trọng của lỗi
  • Title: Tiêu đề lỗi, mô tả ngắn gọn về lỗi đó xảy ra như thế nào và khi nào xảy ra.
  • Url: Đường dẫn xẩy ra lỗi ( Đối với  test app thì có thể để trống phần này )
  • Steps: các bước tái hiện lại lỗi
  • Result description/Expected result: Kết quả thực tế và mong muốn với tính năng mà lỗi đang gây ra
  • Attachment: File đính kèm ( các bạn có thể xem bài viết chi tiết về attachment  tại đây )
  • Devices used: Thiết bị mà bạn đã sử dụng để tìm ra bug.

 2. Severity- Mức độ nghiêm trọng

Low bug: Là lỗi từ mấy function hiển thị và có phản hồi khi người dùng tương tác nhưng không quan trọng mà thích gây chú ý bằng việc nó có bug nhưng không ảnh hưởng đến mục đích chính của Web/App
Ví dụ: Review trong PDP không sort khi chọn condition, không filter theo Rating Ballon của
tooltip không hiện khi click vào.

High bug: Là bug có ảnh hưởng đến mục đích chính của trang web, nhưng có thể thay thể bằng một cách khác để không bị bug, hoặc function có hiển thị trên web nhưng khi tương tác thì không có phản hồi.
Ví dụ: Bạn không xóa ở Cart được, nhưng vào Checkout bạn có thể xóa được. Không add ở PLP được nhưng vào PDP bạn có thể add được.

Critical Bug: Là cái bug mà là chết Web/App, ảnh hưởng trực tiếp đến chức năng chính của Web/App nhưng không thể thay thể bằng con đường nào khác.

 3. Tiêu đề lỗi- Title

bug report

– Tiêu đề cần phải có 2 thành phần tối thiểu đó là WHATHOW riêng đối với thành phần WHERE là không bắt buộc

 WHAT: Lỗi là gì, bạn cần mô tả được hiện tượng lỗi một cách chính xác cụ thể có một số yêu cầu sau:

  • Cần mô tả được hiện tượng lỗi ở mức độ tổng quan chứ không phải là hiện tượng lỗi cụ thể. Ví dụ: sau khi chọn sắp xếp từ giá thấp tới cao, sản phẩm có giá 20 usd đứng sau sản phẩm có giá 30 usd – After select sorting by price from low to high, the product has price 20$ is displayed after the one is 30$. Đây chỉ là một trường hợp lỗi gặp phải mà thôi. không phải là hiện tượng lỗi tổng quan. Tốt nhất nên viết lại là “Sau khi chọn sắp xếp từ giá thấp tới cao, sản phẩm có giá thấp hơn lại được hiển thị sau sản phẩm có giá cao hơn – After select sorting by price from low to high, the product with lower price is displayed after the higher one.
  •  Cần mô tả theo cách là hiện tượng thực tế tính năng đang thực hiện chứ không viết theo cái tính năng không làm được. Ví dụ: Khi thực hiện tính năng search, danh sách kết quả hiển thị các sản phẩm không mong muốn. Kết quả không mong muốn là một mô tả mơ hồ và sẽ không được chấp nhận. Tốt nhất nên viết lại là “Khi thực hiện tính năng search, danh sách kết quả hiển thị các sản phẩm không liên quan tới điều kiện search.
  • “Do not work” “Do not work properly” không bao giờ được chấp nhận. Ví dụ: “Tính năng search không hoạt động”, title thế này là rất dở vì nó chẳng mang lại thông tin gì cho người đọc cả, bạn cần mô tả kỹ hơn. Ví dụ: Khi nhập thông tin và thực hiện tìm kiếm thì website không có phản hồi gì.

 HOW: Mô tả được thao tác, điều kiện gây ra lỗi.

  • Bạn chỉ cần mô tả thao tác gần nhất gây ra lỗi chứ không phải là toàn bộ các thao tác.
  • Cần chỉ rõ các điều kiện gây ra lỗi để giúp người đọc dễ mường tượng được lỗi hơn. Ví dụ lỗi là ” khi đăng nhập bằng Google account thì người dùng lại bị chuyển về màn hình đăng nhập ”
    – Log sai: When login user is taken to the login form again => Không nếu được điểm mấu chốt là phải đăng nhập bằng Google account
    – Log đúng: When login via Google account, user is taken to the account login form again

  WHERE: Vị trí gây lỗi, đây là thông tin không bắt buộc có thì title sẽ đầy đủ hơn nhưng không có thì cũng không sao.

4. URL:
– Đối với website thì đây là nơi xuất hiện lỗi, chỉ cần copy URL trên trình duyệt vào. Sai ở đâu copy URL ở đó.
– Còn nếu là APP thì chỉ cần ghi là N/A hoặc để trống.
Ví dụ: https://website.com/login

5. Steps:
– Đây là nơi dùng để mô tả tất các step để có thể dẫn tới việc tạo ra bug.
– Câu đầu tiên luôn là Open https:// website.com nếu là web, còn app thì là Open {name} app
– Bạn không cần phải mô tả chi tiết từng step, có thể rút gọn bằng cách mô tả chung chung.
Ví dụ: Process to the payment step, log in with a valid account
– Các step quan trọng, dữ liệu quan trọng phải được mô tả và highlight ( chữ in đậm), ví dụ lỗi chỉ xảy ra khi người dùng đăng nhập bằng Apple account thì trong step cần mô tả rõ bước này.
– Dữ liệu test cần có tính thực tế. Trường hợp lỗi “input “ưạihnrjawherahw” to search box” chắc chắn sẽ ăn reject bởi Test IO
Ví dụ
Step 1: Open https://website.com
Step 2: Input your account into fields
Step 3: Click the Login button or press Enter key.
6. Actual:
– Đây là một trong những trường quan trọng của bug report.
– Không bao giờ copy Title và đẩy xuống phần “Actual”, hãy thay đổi văn phong theo hướng mới để mô tả “Actual”
– Bạn hãy mô tả cụ thể lỗi, quay lại với ví dụ về lỗi thực hiện sắp xếp bên trên, đến Result description bạn có thể mô tả sản phẩm nào giá bao nhiêu đứng trước sản phẩm nào…
– Bổ xung các thông tin liên quan đến lỗi như hướng thiết bị, độ phân giải màn hình, lỗi bị trên trình duyệt này mà ko bị trên trình duyệt kia. Tức là, hãy tìm hiểu kỹ hơn một chút về lỗi và bổ xung thông tin vào đây.
Ví dụ: The user cannot redirect to other page after the user click Login button.

7. Expected:
• Mô tả cụ thể thao tác mà bạn mong muốn hệ thống xử lý. Đừng mô tả chung chung ví dụ:
Search function work as expected => The products relate with the search condition should be displayed in result list
• Không bao giờ được đổi khẳng định sang phủ định và người lại với 2 trường Result description/Expected description. Hãy viết môi trường với cách thể hiện khác nhau.
Ví dụ: The user should be redirected to the Homepage or receive an error message, for example, your account is locked, or your username or password is wrong after the user clicks the Login button

8. Video hướng dẫn vượt qua bug report trên bài Onboarding của Test IO

 9. Kết Luận: 

Với các gợi ý khi viết bug report trên thì mình tin rằng các bạn sẽ vượt qua bài Onboarding test của Test IO một cách dễ dàng cũng như là áp dụng cho các dự án trả tiền sau này.

Chú ý:

  • Không copy y nguyên bug report từ tester khác để submit trong bài Onboarding test mà chỉ nên học hỏi cách viết để hiểu được và thay đổi nó thì Test IO mới chấp nhận. Còn nếu không thì sẽ bị Test IO ban acc với lý do Coppied bug
  • Khi viết bug report thì nên hạn chế việc viết sai lỗi chính tả và ngữ pháp bằng cách bạn có thể thử đặt tên bằng tiếng Việt rồi dùng Google dịch để chuyển sang Tiếng Anh. Khi viết bug report lên trang Test IO thì nên kết hợp dùng thêm tiện ích Grammarly ( tìm trên tiện tích của trình duyệt) để được hỗ trợ check ngữ pháp và chính tả giúp bug report giảm thiểu tối đa nguy cơ bị rejected.
  • Không sử dụng được copy-paste toàn bộ nội dung vào báo cáo lỗi trên IO thử nghiệm (khuyến khích bạn nhập nội dung vào báo cáo lỗi chứ không sử dụng copy-paste lệnh tổ hợp 100%)

Xem thêm về các mẫu Bug Report từ Test IO cung cấp tại đây: http://Bug Serverity Assessments- Test IO

 

Nếu chưa có tài khoản test Test IO thì có thể tạo tài khoản test tại bài viết này: Các bước tạo tài khoản Test IO-2022

Xem lại quy trình vượt qua bài test Onboarding của Test IO ở đây: Quy trình vượt qua bài Onboarding của Test IO-2022 

 

Nếu mọi người còn phân vân về bug report trước khi submit thì có thể post bài viết lên group Facebook để được các đội ngũ support hoặc các tester có kinh nghiệm đi trước góp ý nhé.

Đừng quên team đang có chương trình tặng Ebook testing online với những kiến thức và kinh nghiệm quan trọng được tổng hợp giúp newbies đi nhanh hơn trong mảng kiếm tiền online trên nền tảng Test IO và uTest. Đăng ký nhận Ebook tại đây

Thank mọi người

Đặng Phương

Testertudo team

 

Trả lời

Email của bạn sẽ không được hiển thị công khai.