Hướng dẫn làm bài Onboarding – Bug report

Trong các bài kiểm tra onboarding thì bug report là bài khó nhất. Ở đây bạn sẽ phải viết report cho một lỗi được đưa ra bởi testIO.

Đây là form khi bạn tạo một bug report

Các thành phần của màn hình log lỗi

  • Feature: Tính năng mà lỗi xảy ra
  • Bug type: Loại lỗi, để hiểu về loại lỗi – content, visual hay functional bug
  • Severity: Trọng số lỗi đối với functional but
  • Title: Tiêu đề lỗi, mô tả ngắn gọn về hiện tượng và cách làm lỗi xuất hiện
  • Url: Đường dẫn xẩy ra lỗi, trường hợp là test app thì có thể để trống phần này
  • Steps: các bước tái hiện, chi tiết sẽ có trong phần hướng dẫn ở dưới
  • Result description/Expected result: Kết quả thực tế và mong muốn với tính năng
  • Attachment: File đính kèm, về yêu cầu với file đính kèm thì có thể tham khảo tại đây
  • Devices used: Thiết bị mà bạn sử dụng để phát hiện lỗi.

Dưới đây là các mục đặc biệt cần chú ý

1. Tiêu đề lỗi

WHAT  –  HOW  – WHERE

Tiêu đề cần phải có 2 thành phần tối thiểu đó là WHAT HOW 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í du: sau khi chọn sắp xếp từ giá thấp tới cao, sản phẩm có giá 20usd đứ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ỗ 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í du: 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.

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.

WHERE: Mô tả được Ví trí xẩy ra 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.

2. URL:
  • Đối với website thì chính link URL của trang web bị lỗi.
  • Đối với app thì phần này bạn để trống.
3. Steps :
  • Mở đầu luôn là mở đường link được cung cấp ở “Overview” nếu test web. Và là mở app với trường hợp test Application
  • 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 payment step, Login with a valid account
  • Các step quan trọng, dữ liệu quan trọng phải được mô tả và highlight, 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ế.
4. Result description
  • Không bao giờ copy title và đẩy xuống phần “Result description”, hãy thay đổi văn phong theo hướng mới. Phầ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.
5. Expected result
  • 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ược 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.

Total
0
Shares
Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Chủ đề trước

Hướng dẫn làm bài Onboarding - Phần 2.

Chủ đề tiếp theo

Cách cài đặt proxy trên các thiết bị