Jira cho tester mới: Từ tạo bug đến theo dõi trạng thái công việc
3 tháng trước · 9 phút đọc
Jira là gì và tại sao tester cần biết?
Jira là công cụ quản lý công việc phổ biến nhất trong các team phần mềm hiện nay. Nếu bạn đang học testing hoặc vừa vào công ty đầu tiên, khả năng cao team của bạn đang dùng Jira để theo dõi bug, task và tiến độ dự án.
Vấn đề là nhiều tester mới học testing rất kỹ - viết test case tốt, tìm bug giỏi - nhưng lại loay hoay khi báo cáo bug lên Jira. Bug tìm được nhưng không ai xử lý vì viết issue không đủ thông tin. Hoặc gắn sai priority, dev không biết cần fix gấp hay để sau.
Jira giúp team nhìn thấy toàn bộ trạng thái công việc trong một màn hình
Jira không khó học. Bạn chỉ cần hiểu 3 thứ cốt lõi: issue là gì, workflow hoạt động thế nào, và cách trao đổi đúng chỗ. Phần còn lại học dần trong công việc.
Bug, task và sub-task: đừng nhầm lẫn 3 thứ này
Đây là chỗ nhiều tester mới hay nhầm nhất. Jira có nhiều loại issue, nhưng bạn sẽ gặp chủ yếu 3 loại này:
Bug - lỗi phần mềm. Dùng khi bạn phát hiện thứ gì đó hoạt động sai so với yêu cầu. Ví dụ: nút "Đặt hàng" trên Shopee clone bị lỗi không chuyển trang sau khi bấm.
Task - công việc cần làm, không phải lỗi. Ví dụ: "Viết test case cho tính năng đăng nhập", "Review test plan sprint 3". Task thường do lead giao hoặc bạn tự tạo để theo dõi công việc của mình.
Sub-task - công việc con nằm trong một Task hoặc Story. Ví dụ: Task là "Test tính năng thanh toán", sub-task có thể là "Test thanh toán qua MoMo", "Test thanh toán qua thẻ Visa".
Chọn đúng loại issue giúp team filter và báo cáo chính xác hơn
Tại sao cần phân biệt? Vì Jira cho phép filter và báo cáo theo loại issue. Nếu bạn tạo bug nhưng chọn nhầm thành Task, PM hoặc lead khi xem báo cáo số lượng bug sẽ bị sai. Nghe nhỏ nhưng ảnh hưởng đến cả quyết định của team.
Tạo bug report trên Jira: từng bước cụ thể
Mình nhớ lần đầu tạo bug trên Jira, điền đúng 2 trường: tên bug và description rồi... bấm Save. Dev nhận issue, nhắn lại: "Bug này reproduce ở đâu vậy? Bước thực hiện?" Mất thêm 30 phút trao đổi qua lại chỉ để mô tả đủ thông tin.
Sau đây là cấu trúc một bug report đầy đủ trên Jira:
Summary - Tiêu đề ngắn gọn, đủ để hiểu vấn đề. Không viết "Bug trang checkout" mà viết "[Checkout] Nút Đặt hàng không phản hồi sau khi bấm - không chuyển trang xác nhận".
Issue Type - Chọn Bug (quan trọng như phần trước đã nói).
Priority - Gắn độ ưu tiên:
- Highest/Critical: crash app, mất dữ liệu, lỗi thanh toán
- High: tính năng chính không dùng được
- Medium: tính năng phụ bị ảnh hưởng, có cách workaround
- Low: lỗi giao diện nhỏ, typo
Description - Phần này cần kỹ nhất. Mình thường dùng template sau:
**Steps to reproduce:**
1. Mở trang checkout
2. Điền đủ thông tin giao hàng
3. Bấm nút "Đặt hàng"
**Expected result:**
Chuyển đến trang xác nhận đơn hàng
**Actual result:**
Trang không phản hồi, nút bị mờ, không có thông báo lỗi
**Environment:**
- Browser: Chrome 124
- OS: Windows 11
- URL: https://staging.example.com/checkout
Steps to reproduce rõ ràng giúp dev reproduce bug nhanh, không cần hỏi thêm
Attachment - Đính kèm screenshot hoặc video recording. Đây là phần nhiều tester mới hay bỏ qua. Nhưng thực tế, một screenshot khoanh đỏ vùng bị lỗi tiết kiệm cho dev 15-20 phút tìm hiểu. Video ngắn 30 giây còn tốt hơn khi bug liên quan đến animation hoặc flow nhiều bước.
Jira cho phép kéo thả file trực tiếp vào ô Attachment. PNG, MP4, GIF đều được. Mình thường dùng ShareX (Windows) hoặc Loom để record nhanh.
Workflow Jira: bug của bạn đang ở đâu?
Sau khi tạo bug xong, bạn cần biết bug đó đang ở trạng thái nào. Đây gọi là workflow - tức là vòng đời của một issue từ khi tạo đến khi đóng lại.
Workflow cơ bản mà hầu hết team dùng:
| Trạng thái | Ý nghĩa | Ai xử lý? |
|---|---|---|
| Open / To Do | Bug vừa tạo, chưa ai nhận | Tester tạo |
| In Progress | Dev đang fix | Dev |
| In Review / Code Review | Code đã xong, chờ review | Lead/Dev khác |
| Ready for Test | Dev fix xong, chờ tester verify | Dev chuyển |
| Resolved | Tester verify xong, bug đã fix | Tester đóng |
| Closed | Done hoàn toàn | PM/Lead |
| Reopened | Tester verify thấy vẫn còn lỗi | Tester |
Nắm workflow giúp bạn biết cần làm gì ở mỗi bước, không bị thụ động
Phần quan trọng nhất với tester là 2 trạng thái: Ready for Test và Reopened.
Khi bug chuyển sang Ready for Test, đó là tín hiệu dev đã fix xong và đang chờ bạn verify. Bạn cần test lại đúng scenario của bug đó, kiểm tra thêm các edge case liên quan. Nếu fix đúng, chuyển sang Resolved. Nếu vẫn còn lỗi hoặc fix sai chỗ, chuyển sang Reopened và comment rõ lý do.
Lưu ý: mỗi team có thể tùy chỉnh workflow khác nhau. Bạn mới vào team nên hỏi lead "Workflow của mình như thế nào?" thay vì tự đoán. Đừng ngại hỏi - đây là câu hỏi hoàn toàn bình thường.
Trao đổi với dev đúng chỗ: dùng comment, đừng nhắn Zalo
Bạn tìm được bug, tạo issue xong. Dev bảo "Mình không reproduce được". Phản xạ tự nhiên của nhiều tester mới là nhắn Zalo hoặc hỏi trực tiếp. Xong cuộc trò chuyện đó không ai lưu lại, vài ngày sau không ai nhớ đã thống nhất gì.
Jira có tính năng Comment ngay trong issue. Đây là nơi đúng để trao đổi mọi thứ liên quan đến bug đó. Lý do:
- Toàn bộ lịch sử trao đổi được lưu lại, ai vào sau cũng đọc được
- PM và lead nhìn thấy tiến độ xử lý
- Khi audit hoặc báo cáo sprint, có đầy đủ thông tin
Comment trong Jira = hồ sơ bug đầy đủ, tránh tranh cãi "ai nói gì" sau này
Cách comment hiệu quả:
Tag đúng người - dùng @mention. @dev_name Mình đã retest trên staging build 1.2.3, vẫn còn lỗi ở bước 3. Xem video đính kèm.
Đính kèm evidence trong comment - Nếu retest thấy vẫn lỗi, đừng chỉ viết "vẫn lỗi". Đính kèm screenshot mới, ghi rõ environment và build version bạn test.
Ghi ngắn, đủ thông tin - Comment không cần dài. "Verified fixed trên Chrome 124, Windows 11, build 1.2.4. Chuyển Resolved." là đủ.
Một điều nữa: khi bạn verify xong và bug đã fix, nhớ thay đổi trạng thái issue ngay trong lúc comment. Đừng để bug nằm ở Ready for Test 3 ngày sau khi bạn đã verify xong - dev và PM sẽ tưởng bạn chưa kiểm tra.
Gắn priority đúng: đừng để mọi bug đều là Critical
Mình từng thấy một tester mới gắn tất cả bug tìm được là Priority: Highest. Logic của bạn ấy là "mình tìm được bug này quan trọng nên gắn cao cho chắc". Kết quả? Dev nhìn vào backlog thấy 30 bug Highest, không biết cái nào thật sự cần fix trước. Cả team mất 1 buổi họp để re-prioritize.
Priority không phản ánh "bug này quan trọng với mình", mà phản ánh mức độ ảnh hưởng đến user và hệ thống.
Highest / Critical: Hệ thống crash, user không dùng được tính năng cốt lõi, mất dữ liệu, lỗ hổng bảo mật. Ví dụ: app crash khi bấm thanh toán, user không đăng nhập được.
High: Tính năng chính bị ảnh hưởng nhưng hệ thống vẫn chạy. Ví dụ: filter sản phẩm trả kết quả sai, nút Back không hoạt động trên trang checkout.
Medium: Tính năng phụ bị lỗi, có cách làm thay thế (workaround). Ví dụ: sort sản phẩm theo giá hiển thị sai thứ tự nhưng user vẫn mua được.
Low: Lỗi giao diện, typo, màu sắc sai, padding lệch. Không ảnh hưởng chức năng.
Gắn đúng priority = giúp team tập trung vào bug thật sự quan trọng
Khi không chắc nên gắn Medium hay High, hỏi lead. Tốt hơn là hỏi 1 câu trước khi gắn sai và phải đi sửa lại sau. Và nếu bạn mới vào, lead thường happy được hỏi - nó cho thấy bạn cẩn thận.
Một tip nhỏ: một số team có thêm trường Severity (mức độ nghiêm trọng về kỹ thuật) tách riêng khỏi Priority. Priority do PM/lead quyết định dựa trên business impact, còn Severity do tester đánh giá dựa trên kỹ thuật. Nếu team bạn có cả hai, hỏi rõ cách dùng ngay từ đầu.