Bug
Cách gọi dân dã của một lỗi trong phần mềm khiến hệ thống chạy sai so với mong đợi. Trong tài liệu chuẩn thì từ chính xác là defect, còn bug là từ cả team dùng hằng ngày.
Định nghĩa
Từ này ai cũng dùng, ít ai định nghĩa. Trong họp bạn nghe "còn 12 bug open", trong biên bản nghiệm thu lại thấy ghi "defect". Hai từ đó trong đời thường là một, nhưng ISTQB tách khá rõ giữa error, defect và failure. Lúc cả team đang truy nguyên nhân, phân biệt được ba từ đó là phân biệt được đang nói về ai làm sai, chỗ nào sai, hay triệu chứng nào vừa nhìn thấy.
Bug là cách gọi hằng ngày của defect: chỗ sai nằm trong sản phẩm, làm hệ thống chạy khác với yêu cầu.
Bug, defect, error, failure, issue
| Từ | Nghĩa theo chuẩn | Ai hay dùng | Ví dụ |
|---|---|---|---|
| Error | Hành động sai của con người | Người truy nguyên nhân | Dev hiểu nhầm quy tắc làm tròn |
| Defect | Chỗ sai nằm trong code hoặc tài liệu | Báo cáo, tài liệu chính thức | Hàm làm tròn dùng sai kiểu dữ liệu |
| Bug | Từ dân dã của defect | Cả team, hằng ngày | "Cái bug làm tròn tiền đó" |
| Failure | Biểu hiện sai khi chạy | QC, người dùng | Hóa đơn hiện 1.000.001đ thay vì 1.000.000đ |
| Issue | Từ bao trùm mọi vấn đề trong Jira | PM, quản lý | Có thể là bug, task, CR hay câu hỏi |
Chuỗi của nó chạy thế này: con người mắc error, sinh ra defect nằm im trong hệ thống, tới khi chạy vào đúng nhánh đó thì lộ ra failure. Còn issue là cái rổ của Jira; lúc cần nói cho chính xác thì nó vô dụng.
Một bug report dùng được gồm gì
Bug viết ẩu thì dev đá qua đá lại, mất nửa ngày chỉ để hiểu chuyện gì đã xảy ra. Tối thiểu phải có:
- Tiêu đề nói được triệu chứng và chỗ xảy ra: "Thanh toán VNPAY: đơn bị trừ tiền hai lần khi bấm Xác nhận liên tiếp".
- Môi trường và bản build: SIT, build 2.4.1, trình duyệt kèm số phiên bản chính xác lúc phát hiện chứ đừng ghi chung chung là Chrome, tài khoản test nào.
- Tiền điều kiện: tài khoản có số dư bao nhiêu, giỏ hàng đang có gì.
- Các bước tái hiện, đánh số, ngắn gọn.
- Kết quả thực tế và kết quả mong đợi, kèm trích dẫn tài liệu nếu có.
- Ảnh chụp màn hình, video ngắn, log hoặc mã giao dịch, cộng severity và priority.
Thiếu mã giao dịch hoặc thời điểm xảy ra là dev không tra được log, và bug đó dễ bị đóng với lý do không tái hiện được.
Ví dụ thực tế
23h50, một khách đặt lịch khám cho khung giờ 8h sáng hôm sau. Hệ thống lưu lịch sang ngày kế tiếp nữa. QC tái hiện 5 trên 5 lần rồi log bug — phòng khám đa khoa này mỗi ngày có khoảng 640 lượt đặt, nên khung giờ khuya có người dùng thật.
Truy ra thì gốc rễ là múi giờ: server để UTC, giao diện tính theo giờ Việt Nam. Một defect, nhưng biểu hiện thành ba failure ở ba màn khác nhau: danh sách lịch hẹn, báo cáo cuối ngày và tin nhắn nhắc lịch. QC log ba bug riêng cũng được, dev sửa một chỗ rồi đóng cả ba — miễn là ba cái đó có liên kết với nhau trong Jira để sau này còn tra lại.
Lỗi hay gặp khi log bug
- Gộp nhiều lỗi vào một ticket. Sửa xong một cái thì trạng thái ticket nửa vời, không ai biết đóng hay để mở.
- Ghi kết quả mong đợi theo cảm tính, không dẫn được tài liệu nào. Đây là mồi cho tranh cãi kéo dài.
- Log bug cho thứ vốn là yêu cầu mới. Cái đó là change request, đừng nhét vào bug list để né quy trình.
- Đặt severity theo cảm xúc lúc phát hiện. Vừa gặp lỗi thì cái gì cũng thấy nghiêm trọng.
Việc của BA
Mỗi sáng trong giai đoạn test, mở bug list và đọc lướt phần mô tả. Bạn tìm hai thứ: bug nào thực chất là yêu cầu chưa rõ, và bug nào lặp lại cùng một nguyên nhân. Cái đầu là việc bạn phải làm rõ ngay trong ngày, cái sau là dấu hiệu tài liệu có chỗ hổng cần vá.
