Format viết bug report cho dân IT có report chất lượng


Chia sẻ về Format viết bug report cho dân IT có report chất lượng.

1. Bug ID

Bug ID rất quan trọng trong việc có thể đề cập đến lỗi trong các báo cáo. Nếu một công cụ báo cáo lỗi được sử dụng để ghi nhật ký lỗi, ID thường là một số duy nhất được tạo bởi công cụ quản lý lỗi, tăng theo mỗi lần tạo mới bug.

2. Tiêu đề lỗi

Tiêu đề lỗi được đọc thường xuyên hơn bất kỳ phần nào khác của báo cáo lỗi. Nó sẽ nói lên khái quát lỗi gì đã xảy ra trên ứng dụng.

Tiêu đề lỗi nên nêu khái vấn đề gặp phải là gì và ở đâu. Như kinh nghiệm của mình, nên đặt cho tiêu đề lỗi những prefix nhất định ví dụ như tên màn hình, tên chức năng xảy ra lỗi, sau đó mới khái quát lỗi.

Bạn nên nêu ra vấn đề lỗi trước, và nguyên nhân tại sao lỗi nêu sau. Làm như vậy mục đích là để nhấn mạnh vấn đề gặp phải với phía Dev. Nên viết theo kiểu BUG XẢY RA KHI NÀO thay vì KHI NÀO XẢY RA BUG .

Ví dụ với chức năng change password, người dùng vẫn có thể change password mới khi nhập sai password cũ.

Bạn nên viết

Bug title: [Change password] STILL CAN change password successful when input current password incorrectly

Không nên viết:

Bug title: [Change password] When input current password incorrectly, user still can change password successful

Như vậy, bạn đang nhấn mạnh vào việc vẫn có thể change password trước.

Ngoài ra, bạn cũng nên highlight hay viết hoa những keyword cần nhấn mạnh cho người đọc để ý. Như ví dụ trên, tôi đã viết hoa từ "STILL CAN" để nhấn mạnh việc bình thường là không thể làm nhưng hiện tại lại có thể làm.

bug report 1

3. Môi trường kiểm thử

Cấu hình, hệ điều hành và trình duyệt là cần thiết cho một báo cáo lỗi rõ ràng. Đây là cách tốt nhất để liên lạc về cách có thể sao chép lỗi.

Nếu không có nền tảng hoặc môi trường chính xác, ứng dụng có thể hoạt động khác đi và lỗi ở phía tester có thể không thể tái hiện trên phía môi trường của Dev. Vì vậy, tốt nhất là đề cập rõ ràng đến môi trường phát hiện ra lỗi.

  • Lỗi này ảnh hưởng đến hệ điều hành nào? NêN viết hoàn chỉnh phiên bản của hệ điều hành: Windows XP> Windows XP Pro 2002 SP3
  • Lỗi trình duyệt này ảnh hưởng gì? Lỗi chỉ xảy ra trên những trình duyệt nào?
  • Lỗi này ảnh hưởng đến thiết bị nào? Trên các thiết bị di động thì cần nêu rõ loại thiết bị, version là gì. Ví dụ, bạn test 1 ứng dụng trên iPhone, có bug chỉ xảy ra trên version >10. hoặc chỉ xảy ra trên iPhone 5, iPhone 6 còn những thiết bị và version khác thì lại không.
  • Bất kỳ thông tin bổ sung?
    • Cung cấp thông số kỹ thuật của hệ thống , vì điều này có thể giúp gỡ lỗi với các vấn đề như hết thời gian đo hiệu năng: RAM 16GB, 4GB miễn phí, Intel Core i5- 2300 CPU @ 2.80ghZ 64-bit.
    • Thời gian thực hiện kiểm thử có ảnh hướng đến kết quả test hay không?

4. Mô tả/ Cách tái hiện

Mô tả lỗi giúp nhà phát triển tái hiện lại vấn đề gặp phải. Mô tả kém sẽ tạo ra sự nhầm lẫn và lãng phí thời gian của 2 bên phía người phát triển và người kiểm thử.

Trong mô tả cần nêu rõ những vấn đề sau:

  • Tiền điều kiện (nếu có)
  • Các bước tái hiện: Cần cụ thể và chính xác những gì xảy ra sau mỗi bước. Nên đánh số cho từng bước, không nên gạch đầu dòng như kiểu liệt kê.
  • Kết quả thực tế: Nêu rõ lỗi gì, đã xảy ra sau bước thứ mấy
  • Kết quả mong đợi: Tester cần nắm chắc kết quả mong đợi chính xác là gì. Nếu cần có thể dẫn chứng spec, design yêu cầu minh chứng cho kết quả mong đợi sau khi xử lý lỗi này. Trong trường hợp spec và design không khớp nhau, bạn cũng nên confirm lại với khách hàng để chắc chắn nha, tránh trường hợp dev lại hỏi ngược lại là "Tôi làm theo đúng spec rồi, tôi không làm theo design".
  • Tỉ lệ tái hiện bug: Có những lỗi xảy ra với tần suất nhỏ, có lỗi cần số bước tối thiểu để tái hiện, hay thậm chỉ xảy ra theo số lần chẵn lẻ thao tác một chức năng nào đó bạn cũng nên đề cập vào mô tả. Đó chính là lý do bạn nên tái hiện lại bug ít nhất 3 lần trước khi log bug.

5. Mức độ nghiêm trọng

Mức độ nghiêm trọng của lỗi cho thấy ảnh hưởng của lỗi đối với các hệ thống, doanh nghiệp, môi trường và cuộc sống của con người, tùy thuộc vào bản chất của hệ thống ứng dụng. Mức độ nghiêm trọng thường được xếp hạng và phân loại theo 4 hoặc 5 cấp độ, tùy thuộc vào định nghĩa của tổ chức.

  • Critical (Nguy hiểm): Điều này có nghĩa là lỗi là một điểm dừng của việc sử dụng ứng dụng với khả năng thiệt hại cao và không có cách giải quyết để tránh lỗi.
    Ví dụ: Ứng dụng hoàn toàn không khởi chạy và khiến hệ điều hành ngừng hoạt động. Điều này gây gián đoạn trong việc tiếp tục sử dụng ứng dụng của người dùng và yêu cầu ngay lập tức phải sửa lỗi đó.
  • Serious (Nghiêm trọng): Điều này có nghĩa là một số chức năng chính của ứng dụng bị thiếu hoặc không hoạt động và không có cách giải quyết.
    Ví dụ, một ứng dụng xem hình ảnh không thể đọc một số định dạng hình ảnh phổ biến.
  • Normal (Bình thường): Điều này có nghĩa là một số chức năng chính không hoạt động, nhưng một cách giải quyết khác có thể được sử dụng thay thế như một giải pháp tạm thời.
  • Cosmetic / Enhancement (Mỹ quan / Tính năng mở rộng): Điều này có nghĩa là lỗi gây ra sự bất tiện và phiền toái.
    Ví dụ có thể có một thông báo bật lên cứ sau 15 phút hoặc bạn luôn phải nhấp hai lần vào nút GUI để thực hiện hành động.
  • Suggestion (Gợi ý): Đây thường không phải là lỗi mà là gợi ý để cải thiện chức năng. Đây có thể là GUI hoặc tùy theo thói quen sử dụng của người dùng.

6. Mức độ ưu tiên

Khi mức độ nghiêm trọng được xác định, tiếp theo là xem cách ưu tiên giải quyết. Xác định mức độ ưu tiên nhanh chóng để sửa lỗi. Ưu tiên thường liên quan đến tầm quan trọng của doanh nghiệp như tác động đến dự án và khả năng thành công của sản phẩm trên thị trường. Giống như mức độ nghiêm trọng, mức độ ưu tiên cũng được phân loại thành 4 hoặc 5 cấp độ.

  • Urgent (Khẩn cấp): Có nghĩa là rất khẩn cấp và yêu cầu giải quyết ngay lập tức mới có thể tiếp tục sử dụng ứng dụng, hoặc có thể liên quan đến những vấn đề bảo mật gây nguy hại cấp bách đến người dùng, doanh nghiệp.
  • High (Cao): Yêu cầu cần xử lý cho bản phát hành mở rộng tiếp theo hoặc có ảnh hưởng đến chức năng khác cần phải fix lỗi này trước mới sử dụng được các chức năng khác liên quan.
  • Medium (Trung bình): Yêu cầu cần xử lý cho lần triển khai đầu tiên (thay vì tất cả các lần triển khai) hiểu đơn giản là lỗi này xảy ra độc lập, không ảnh hưởng đến các chức năng khác.
  • Low (Thấp): Mong muốn cho lần triển khai đầu tiên hoặc các bản phát hành tiếp theo trong tương lai.

    Hiểu thêm về mức độ nghiêm trọng và mức độ ưu tiên

Cần lưu ý là một lỗi có mức độ nghiêm trọng cao luôn luôn có mức độ ưu tiên cao, tức là một lỗi nghiêm trọng sẽ đòi hỏi mức độ ưu tiên cao để giải quyết vấn đề càng nhanh càng tốt. Không bao giờ có một lỗi có mức độ nghiêm trọng cao mà mức độ ưu tiên thấp. Tuy nhiên, một lỗi có thể có mức độ nghiêm trọng thấp nhưng có mức độ ưu tiên cao.
Một ví dụ có thể là tên công ty bị sai chính tả trên màn hình ngay khi khởi chạy ứng dụng. Điều này không gây thiệt hại nghiêm trọng đến môi trường hoặc cuộc sống của mọi người, nhưng có thể gây thiệt hại tiềm tàng cho danh tiếng của công ty và có thể gây tổn hại đến lợi nhuận kinh doanh.

7. Tài liệu đính kèm, bằng chứng

Bất kỳ bằng chứng nào về sự thất bại nên được nắm bắt và gửi cùng với báo cáo lỗi. Đây là một lời giải thích trực quan về mô tả của lỗi và giúp người đánh giá, nhà phát triển hiểu rõ hơn về lỗi. Thực tế, đôi khi chủ quan mà bạn đã không đính kèm một bằng chứng đơn giản như ảnh chụp màn hình, đến khi lập trình viên mở bug report của bạn ra, làm theo chuẩn các bước mà vẫn không tái hiện được. Và thậm chí bạn cũng không tái hiện được, thế là mang tiếng log bug "điêu". Vậy thì, dù bug to hay bug bé, hãy chịu khó đính kèm thêm cái attachment vào, vì "Nói có sách, mách có chứng" mà . Dù không tài hiện được thì cũng đảm bảo rằng lỗi chắc chắn đã từng xảy ra. 

  • Đính kèm TẤT CẢ các tệp có liên quan để giải thích, sao chép và gỡ lỗi: ví dụ như spec, testcase, dẫn chứng confirm với khách hàng, các ứng dụng khác tương tự
  • Highlight các khu vực cần chú ý trong ảnh chụp màn hình, dẫn mắt người xem đến vùng bị lỗi
  • Đính kèm ảnh chụp màn hình trực tiếp vào ticket (không nên nén file ở định dạng .rar , .zip, ...)
  • Tạo video nếu các bước phức tạp (các bước trong mô tả nên khớp với video)
  • Nén các tệp zip quá lớn để đính kèm hoặc có thể upload lên drive attachment của dự án
  • Nếu kích thước tệp vượt quá giới hạn để đính kèm, hãy tách các tệp zip khi nén
  • Một số tool offline cho phép chụp/ record màn hình:
    • Snagit để chụp và quay màn hình
    • Recordmydesktop để record màn hình
    • Gif screen record: record màn hình lưu định dạng ở file gif
    • Qnap: extension trên Chrome cho phép chụp, chỉnh sửa và download ảnh chụp màn hình

8. Các thành phần ảnh hưởng

Dưới quan điểm của một người kiểm thử, hãy nên đưa ra dự đoán hoặc logic mà các chức năng, màn hình khác có thể bị ảnh hưởng từ lỗi này. Từ đó, tester có thể cover được tối đa việc fix bug này rồi nhưng lại gây ra các lỗi khác.

bug report

9. Gán cho ai

Tùy vào cách tổ chức quản lý và hoạt động của từng tổ chức mà sẽ có yêu cầu gán lỗi cho ai xử lý.

Ví dụ:

  • Có team khi tạo bug report thì gán cho leader > Leader xem xét và gán lại cho dev phù hợp
  • Có team khi tester tạo bug thì gán trực tiếp cho dev phát triển chức năng đó.

10. Thời gian phát hiện và fix bug

Ngày và thời gian mà lỗi xảy ra hoặc báo cáo cũng rất cần thiết. Điều này thường hữu ích khi bạn muốn tìm kiếm các lỗi được xác định cho một bản phát hành phần mềm cụ thể hoặc từ khi giai đoạn kiểm thử bắt đầu.

Thời gian cũng có thể giúp ích cho việc estimate và tổng hợp thời gian xử lý cho từng lỗi. Thường ta sẽ có Start date và Due date cho từng ticket.

Theo viblo.asia 

Japan IT Works



Việc làm theo chuyên ngành

Việc làm theo ngành

Việc làm theo tỉnh thành