Bug report chuẩn cho fresher: Cách mô tả, mức độ nghiêm trọng và bước tái hiện
4 tháng trước · 11 phút đọc
Bug report là gì và tại sao nó quan trọng với fresher?
Mình nhớ lần đầu tiên log bug trong đợt thực tập. Tìm được một lỗi khá nghiêm trọng: nút "Thanh toán" trên app không phản hồi sau khi nhấn. Mình viết vào Jira: "Bấm nút thanh toán bị lỗi" rồi assign cho dev.
Dev nhắn lại sau 5 phút: "Máy tao bấm vẫn chạy bình thường. Lỗi ở đâu?"
Mình không biết trả lời gì. Không có bước tái hiện, không có môi trường, không có màn hình chụp. Bug report vô dụng, dev không fix được, bug nằm đó.
Đó là lý do bug report là kỹ năng cần học kỹ nhất khi mới vào nghề. Không phải vì quy trình phức tạp, mà vì bug report kém = dev không reproduce được = bug không được fix. Đơn giản vậy thôi.
Một bug report mơ hồ có thể khiến cả team mất thêm ngày để điều tra
Với fresher tester, bug report còn là thứ người ta đánh giá bạn khi phỏng vấn. Nhiều công ty yêu cầu viết bug report mẫu ngay trong bài test tuyển dụng. Viết được chuẩn, bạn ghi điểm ngay lập tức.
Các thành phần bắt buộc trong một bug report
Một bug report chuẩn không cần dài, nhưng cần đủ 7 phần sau. Thiếu một phần là dev sẽ hỏi lại, mất thêm thời gian của cả hai.
Đủ 7 phần này, dev sẽ không cần hỏi thêm câu nào
1. Title (tiêu đề)
Viết ngắn, rõ, đủ 3 yếu tố: [Tính năng] + [Hành động] + [Kết quả lỗi].
- Kém: "Lỗi đăng nhập"
- Tốt: "[Login] Nhập đúng email/password nhưng hiện thông báo 'Sai mật khẩu'"
Title tốt giúp ai đọc cũng hình dung ngay bug xảy ra ở đâu, không cần mở ra đọc hết.
2. Environment (môi trường)
Ghi lại toàn bộ ngữ cảnh kỹ thuật:
- OS: Windows 11 / macOS Ventura / Android 13
- Browser/App version: Chrome 124 / App v2.3.1
- Môi trường server: Staging / Production
Cùng một bug có thể chỉ xảy ra trên Safari nhưng không xảy ra trên Chrome. Nếu không ghi, dev test trên Chrome rồi bảo "không tái hiện được" là chuyện thường.
3. Steps to reproduce (bước tái hiện)
Phần quan trọng nhất. Viết từng bước như hướng dẫn nấu ăn: ai đọc cũng làm được.
1. Truy cập https://demo-shop.com/login
2. Nhập email: [email protected]
3. Nhập password: Test@123
4. Nhấn nút "Đăng nhập"
5. Quan sát thông báo hiện ra
Nhớ: bắt đầu từ trạng thái ban đầu (initial state). "Mở app" là đúng, nhưng cần ghi rõ hơn: "Mở app, chưa đăng nhập, kết nối WiFi".
4. Actual result (kết quả thực tế)
Hệ thống đang làm gì. Mô tả chính xác, không suy đoán.
- Kém: "Bị lỗi"
- Tốt: "Hiện thông báo màu đỏ: 'Sai mật khẩu. Vui lòng thử lại'"
5. Expected result (kết quả mong đợi)
Hệ thống nên làm gì. Dựa vào requirement hoặc logic thông thường.
- Tốt: "Đăng nhập thành công, chuyển về trang Dashboard"
6. Severity (mức độ nghiêm trọng)
Bug ảnh hưởng hệ thống đến mức nào? Mình sẽ giải thích chi tiết ở phần sau.
7. Attachments (file đính kèm)
Chụp màn hình hoặc quay video là bắt buộc với bug UI. Đôi khi nhìn screenshot 5 giây còn hiểu hơn đọc 5 dòng mô tả. Đặt tên file rõ ràng: bug-login-wrong-password-chrome-20240615.png, không phải Screenshot_123.png.
Severity và Priority: hai khái niệm fresher hay nhầm nhất
Đây là điểm mình thấy nhiều bạn mới bị hỏi vấp trong phỏng vấn nhất.
Severity = mức độ bug ảnh hưởng đến hệ thống. Do tester đánh giá dựa trên kỹ thuật.
Priority = mức độ cần fix gấp. Do team/PM quyết định dựa trên business.
Hai thứ này không đi cùng nhau. Bug có thể severity cao nhưng priority thấp - và ngược lại.
Severity là kỹ thuật, Priority là business - hai thứ khác nhau hoàn toàn
Bảng phân loại Severity:
| Mức độ | Ý nghĩa | Ví dụ |
|---|---|---|
| Critical | Hệ thống crash, không dùng được | App crash khi mở, không load được trang chủ |
| High | Tính năng chính bị hỏng | Không thanh toán được, không đăng nhập được |
| Medium | Tính năng phụ bị lỗi | Filter sản phẩm không hoạt động đúng |
| Low | Lỗi nhỏ, UI/cosmetic | Sai màu button, typo trong text |
Ví dụ tình huống phân biệt:
Trên app thương mại điện tử, nút "Yêu thích" bị lỗi không lưu được sản phẩm.
- Severity: Medium (tính năng phụ, không ảnh hưởng mua hàng)
- Priority: Low (team đang tập trung fix bug thanh toán trước)
Ngược lại: Button "Thanh toán" trên trang checkout hiển thị sai tiếng Anh thay vì tiếng Việt.
- Severity: Low (chỉ lỗi hiển thị text, chức năng vẫn chạy)
- Priority: High (sắp ra mắt chiến dịch lớn, cần đúng ngôn ngữ)
Bạn thấy sự khác biệt chưa? Severity nhìn vào hậu quả kỹ thuật. Priority nhìn vào thời điểm và tầm quan trọng với business. Khi mới vào làm, bạn chỉ cần điền đúng Severity - Priority thường do lead hoặc PM điều chỉnh.
Bug report tốt vs bug report kém: so sánh thực tế
Lý thuyết vậy đủ rồi. Xem ngay hai ví dụ để thấy sự khác biệt.
Tình huống: Tester tìm thấy lỗi khi đăng nhập app mobile bằng email/password.
Bug report kém:
Title: Lỗi đăng nhập
Mô tả: Đăng nhập không được. Bị lỗi.
Severity: High
Bug report tốt:
Title: [Login - Android] Nhập đúng email/password vẫn hiện "Sai mật khẩu" - không vào được app
Environment:
- Device: Samsung Galaxy S21, Android 13
- App version: 2.4.1 (build 241)
- Môi trường: Staging
- Network: WiFi
Steps to reproduce:
- Mở app (chưa đăng nhập)
- Nhấn "Đăng nhập bằng Email"
- Nhập email:
[email protected]- Nhập password:
Test@2024- Nhấn nút "Đăng nhập"
Actual result: Hiện thông báo màu đỏ: "Mật khẩu không đúng. Vui lòng thử lại" - không chuyển trang
Expected result: Đăng nhập thành công, chuyển về màn hình Home
Severity: High Priority: High
Attachments: [screenshot-login-error-s21-20240615.png]
Note: Thử lại 3 lần cùng account, cùng kết quả. Account login được trên web browser bình thường.
Bug report tốt giúp dev reproduce trong 2 phút thay vì 2 giờ
Bạn thấy sự chênh lệch chưa? Bug report kém, dev đọc xong không biết bắt đầu từ đâu. Bug report tốt, dev làm theo step-by-step, reproduce được ngay.
Phần Note cuối cùng rất quan trọng nhưng hay bị bỏ qua. Ghi thêm những gì bạn đã thử: đổi tài khoản khác thì sao, thử trên thiết bị khác thế nào, lỗi xảy ra 100% hay ngẫu nhiên. Thông tin này giúp dev khoanh vùng lỗi nhanh hơn nhiều.
Mẹo viết bug report nhanh mà không bỏ sót
Sau khi tìm được bug, mình có thói quen làm theo trình tự này trước khi log:
Bước 1: Chụp màn hình ngay lập tức. Trước khi làm gì khác. Đôi khi bug chỉ xuất hiện một lần rồi biến mất, không reproduce được nữa.
Bước 2: Tái hiện lại bug ít nhất 2 lần. Để chắc không phải lỗi ngẫu nhiên (flaky bug). Nếu lần 2 không tái hiện được, ghi chú vào bug report: "Xảy ra 1/3 lần test".
Bước 3: Xác định scope. Bug này chỉ xảy ra trên Android hay cả iOS? Chỉ tài khoản loại Free hay cả Premium? Tìm thêm thông tin, report sẽ có giá trị hơn nhiều.
Bước 4: Điền title trước, nội dung sau. Title tốt giúp bạn tư duy rõ về bug đang gặp. Nếu không viết được title rõ ràng, có thể bạn chưa hiểu đủ về bug.
4 bước trước khi log - đừng vội điền Jira ngay khi thấy lỗi
Một lưu ý nữa: không đoán mò nguyên nhân bug trong bug report, trừ khi bạn chắc chắn. Viết những gì quan sát được, không viết "Có vẻ do server timeout" hay "Chắc lỗi database". Đó là việc của dev. Nếu bạn muốn ghi chú thêm, dùng phần Note và viết: "Có thể liên quan đến... nhưng chưa xác nhận".
Tải mẫu bug report bên dưới để luyện tập ngay - có cả phiên bản điền tay và hướng dẫn từng trường:
Viết bug report khi phỏng vấn: những điểm cần lưu ý
Nhiều công ty test kỹ năng bug report ngay trong vòng tuyển dụng. Họ đưa cho bạn một app demo hoặc website, yêu cầu tìm bug và viết report trong 30-60 phút.
Bạn cần biết gì để vượt qua?
Ưu tiên bug quan trọng trước. Đừng dành hết thời gian log 10 lỗi typo trong khi bỏ qua 1 lỗi chức năng nghiêm trọng. Tester giỏi biết phân loại và ưu tiên.
Đặt câu hỏi trước khi bắt đầu. "App này nhắm đến user nào? Môi trường test trên browser nào?" Câu hỏi thông minh trước khi làm cho thấy bạn tư duy có hệ thống.
Test có định hướng, không test ngẫu nhiên. Bắt đầu từ luồng chính: đăng ký → đăng nhập → tính năng core → thanh toán/checkout. Sau đó mới test edge case.
Phỏng vấn testing: tư duy có hệ thống quan trọng hơn số lượng bug tìm được
Một điểm mình thấy nhiều bạn bỏ qua: không chỉ tìm bug, còn cần test để confirm không có bug. Nếu bạn test đăng nhập đầy đủ các case và không tìm được lỗi, ghi lại những case đã test. Interviewer thấy bạn test kỹ hơn là chỉ thấy danh sách bug.
Thấy khó lúc đầu là bình thường. Mình biết nhiều bạn 28-32 tuổi chuyển ngành từ kế toán, ngân hàng vào testing, và sau 2-3 tháng luyện tập đã viết bug report tốt hơn cả bạn học IT 4 năm. Kỹ năng này không cần biết code, chỉ cần tỉ mỉ và luyện tập.
Bước tiếp theo: lấy bất kỳ app nào bạn đang dùng hàng ngày, test 30 phút và viết thử 2-3 bug report theo template trên. Đó là cách luyện tập tốt nhất trước khi đi phỏng vấn.
Bài tiếp theo mình sẽ hướng dẫn cách viết test case cho tính năng đăng nhập - case study phổ biến nhất trong phỏng vấn tester. Bookmark lại nhé!