Những mẹo giúp Tester viết Bug Report nhanh hơn

Bug là những lỗi phần mềm trong chương trình hoặc hệ thống máy tính khiến cho kết quả trả về không được chính xác hoặc không đạt hiệu quả như mong muốn. Hiểu một cách đơn giản hơn, bug là lỗi xuất hiện trong quá trình viết code mà bất cứ người lập trình viên nào cũng khó tránh khỏi.

Bug report là mô tả lỗi xảy ra khi thực thi test phần mềm, thường hay được Dev nhà mình gọi vui là log Bug hay report Bug. Bug report thường được Tester thực hiện trên các phần mềm quản lý tasks như Jooto, Backlog, Redmine, Jira,…

Cấu trúc bug

  • Defect ID: tên bug 
  • Title: Miêu tả ngắn gọn bug 
  • Description: Miêu tả chi tiết bug 
  • Severity: Mức độ nguy hại của bug 
  • Status: Trạng thái hiện tại của bug 
  • Steps to Pre-produce: Các bước mô tả 
  • Priority: Độ ưu tiên 
  • Creator: Người phát hiện bug 
  • Create date: Ngày báo cáo bug 
  • Assign to: Người chịu trách nhiệm về bug 
  • Close date: ngày close bug 
  • Attached: ảnh hoặc video mô tả

Một số dạng thường gặp của bug 

  • Không thực hiện chức năng được yêu cầu.
  • Những yêu cầu đầu vào không được hiểu rõ. 
  • Một phần hay toàn bộ đặc tính không được hoàn thành. 
  • Không theo luồng công việc. 
  • Lỗi giao diện. 
  • Tốc độ xử lý, lỗi cấu hình, bộ nhớ. 
  • Lỗi về document. 
  • Vấn đề với xử lý dữ liệu hoặc luồng dữ liệu vào ra. 
  • Vấn đề với đặc quyền người dùng hoặc bảo mật.

Những yếu tố nào để đánh giá một bug report tốt?

Bất cứ ai cũng có thể viết một báo cáo lỗi. Nhưng không phải ai cũng có thể viết một báo cáo lỗi hiệu quả để Dev có thể tái hiện được, chấp nhận Bug và thực hiện fix.
Vậy làm thế nào để có thể phân biệt được Bug report có chất lượng tốt và chất lượng trung bình? Dưới đây là một vài tiêu chí đánh giá tiêu biểu để xác định:

Tiêu chí Bug report chất lượng tốt Bug report chất lượng trung bình
Lượng thông tin Chứa đầy đủ thông tin về vấn đề cần sửa Thiếu thông tin hoặc thông tin không rõ ràng
Tái hiện lỗi Có thể tái hiện được Không thể tái hiện
Hỗ trợ teamwork Tạo nên được tiền đề phối hợp giữa Dev và Tester Gây tranh cãi hoặc không hợp tác giữa Dev và Tester
Tiến trình xử lý bug Bug được sửa nhanh, triệt để và ít có nguy cơ ảnh hưởng đến các chức năng khác liên quan Bug không được sửa hoặc sửa nhưng không đạt yêu cầu, ảnh hưởng đến các chức năng khác

Format bug report đơn giản và đầy đủ những thông tin cần thiết

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: [Change password] STILL CAN change password successful when input curent password incorrectly

Không nên viết: [Change password] When input curent 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 high light 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.

 Xem thêm: Bộ từ vựng tiếng Anh giúp bạn viết Bug nhanh hơn 

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ấpthô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 do hiệu năng: RAM 16GB, 4GB miễn phí, Intel Core i5- 2300 CPU @ 2.80ghZ64-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 ngya 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ênCầ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.

Mối quan hệ giữa priority và severity

  • High Priority – High Severity: bug có độ nghiêm trọng cao – độ ưu tiên cao. 

Ví dụ: lỗi crash app, ảnh hưởng rất lớn đến hệ thống cần phải fix ngay.

  • High Severity – Low Priority: bug có độ nghiêm trọng cao – độ ưu tiên thấp

Ví dụ: Trong app đọc truyện, khi đến câu chuyện thứ 100 thì không hiển thị nội dung chuyện, tuy nhiên để đọc đến câu chuyện thứ 100 thì người chơi cần phải đọc trong 1 khoảng thời gian dài, do đó đây là 1 lỗi nghiêm trọng nhưng có thể từ từ fix.

  • High Priority – Low Severity: bug có độ nghiêm trọng thấp – độ ưu tiên cao

Ví dụ: sai tên logo công ty, tuy không ảnh hưởng đến hệ thống nhưng lại ảnh hướng lớn đến hình ảnh công ty nên cần được ưu tiên fix trước.

  • Low Priority – Low Severity bug: bug có độ nghiêm trọng thấp – độ ưu tiên thấp

Ví dụ: bug sai vị trí button.

Leave a Reply

Your email address will not be published. Required fields are marked *