Jira Cơ Bản Cho Tester: Quản Lý Bug Và Test Case
6 tháng trước · 14 phút đọc
Jira là gì và tại sao tester cần biết?
Mình nhớ hồi mới vào nghề, được assign vào project nhưng không biết báo bug ở đâu. Dev hỏi "Jira ticket số bao nhiêu?" - mình đứng hình. Từ hôm đó mình tự học Jira trong 2 ngày, và nhận ra đây là công cụ tester nào cũng phải biết.
Jira là phần mềm quản lý dự án của Atlassian, được 42% (ElectroIQ Jira Statistics [2025]) công ty phần mềm trên thế giới sử dụng. Với tester, Jira là nơi bạn:
- Ghi lại bug tìm được (log bug)
- Theo dõi tiến trình xử lý bug
- Quản lý danh sách test case cần chạy
- Báo cáo kết quả test cho team
Jira là "nhật ký công việc" chung của cả team - dev, tester, và PM đều nhìn vào đây
Tại sao không dùng Excel? Được, nhưng Excel không có workflow tự động, không gửi thông báo cho dev khi có bug mới, không track ai đang xử lý gì. Jira giải quyết hết những điểm đó.
Fresher cần biết: Bạn không cần quyền admin để dùng Jira hiệu quả. Hầu hết các thao tác tạo issue, log bug, comment - đều làm được với quyền thành viên thông thường. PM hoặc Scrum Master sẽ setup project, bạn chỉ cần biết dùng.
Hiểu các khái niệm cơ bản trước khi dùng
Dùng Jira mà không hiểu thuật ngữ thì rất dễ nhầm lẫn. Mình liệt kê những khái niệm bạn sẽ gặp mỗi ngày:
Issue - đơn vị công việc cơ bản nhất trong Jira. Mọi thứ đều là issue: bug, task, test case, yêu cầu tính năng. Cứ nghĩ issue như một "phiếu công việc" vậy.
Issue Type - loại issue. Phổ biến nhất với tester:
- Bug: lỗi phần mềm tìm được khi test
- Task: việc cần làm (ví dụ: "viết test case cho tính năng đăng nhập")
- Story: tính năng người dùng cần (thường do PM tạo)
- Sub-task: việc nhỏ thuộc về một issue lớn hơn
Project - không gian làm việc của cả team. Mỗi dự án phần mềm thường có 1 project Jira riêng.
Sprint - chu kỳ làm việc ngắn, thường 2 tuần. Team commit hoàn thành một số lượng công việc nhất định trong sprint.
Board - giao diện kanban hiển thị các issue theo cột trạng thái. Thường có: To Do → In Progress → Done.
Board dạng kanban giúp cả team nhìn thấy ai đang làm gì chỉ trong 5 giây
Status - trạng thái hiện tại của issue. Ví dụ: Open → In Progress → Resolved → Closed. Với bug, dev sẽ chuyển sang "Resolved" sau khi fix, tester verify xong thì đóng thành "Closed".
Assignee - người được giao xử lý issue. Bug mới thường assign cho dev, sau khi fix thì assign lại cho tester để verify.
Priority - mức độ ưu tiên: Blocker, Critical, Major, Minor, Trivial. Mình sẽ giải thích cách chọn đúng ở phần log bug bên dưới.
Hiểu 7 khái niệm này là đủ để làm việc. Jira còn nhiều tính năng khác nhưng fresher chưa cần đến ngay.
Cách tạo issue và log bug đúng chuẩn
Bug report tệ là nguyên nhân số 1 làm dev khó chịu với tester. Mình từng viết bug report kiểu "Bấm vào nút thì bị lỗi" - dev hỏi lại 5 câu mới reproduce được. Mất thêm 30 phút của cả hai người.
Dưới đây là cách tạo bug issue trong Jira đúng chuẩn:
Bước 1: Tạo issue mới Bấm nút Create (thường ở thanh menu trên cùng). Chọn Issue Type = Bug.
Bước 2: Điền Summary (tiêu đề) Summary phải ngắn, đủ thông tin để đọc qua biết ngay bug ở đâu:
- ❌ "Lỗi đăng nhập"
- ✅ "[Đăng nhập] App crash khi nhập password có ký tự đặc biệt @#$"
Format gợi ý: [Tên tính năng] + Hành vi bất thường + Điều kiện xảy ra
Bước 3: Chọn Priority
- Blocker: App không dùng được, ảnh hưởng tất cả user
- Critical: Tính năng quan trọng bị hỏng, không có cách workaround
- Major: Tính năng bị lỗi nhưng có cách khác để dùng tạm
- Minor: Lỗi nhỏ, ảnh hưởng ít, chưa cần fix ngay
- Trivial: Typo, lỗi hiển thị nhỏ, không ảnh hưởng chức năng
Chọn sai priority là nguồn gốc của mọi tranh cãi giữa tester và dev - cẩn thận phần này
Bước 4: Viết Description Đây là phần quan trọng nhất. Template chuẩn:
**Môi trường:**
- OS: Windows 11 / macOS 13
- Browser: Chrome 120 / App version 2.1.3
- Tài khoản test: [email protected]
**Steps to Reproduce (Các bước tái hiện lỗi):**
1. Mở trang đăng nhập tại https://demo.app/login
2. Nhập username: [email protected]
3. Nhập password: Test@#$123
4. Bấm nút "Đăng nhập"
**Expected Result (Kết quả mong đợi):**
Chuyển hướng đến trang Dashboard
**Actual Result (Kết quả thực tế):**
App hiển thị màn hình trắng, console báo lỗi: "TypeError: Cannot read property 'token' of undefined"
**Attachment:**
[Screenshot + video recording đính kèm]
Bước 5: Đính kèm bằng chứng Kéo thả file screenshot hoặc video vào ô Attachment. Bug có video reproduce thường được fix nhanh hơn 40-50% vì dev không mất thời gian hỏi thêm.
Tải template bug report đầy đủ tại đây: Tải template bug report Jira
Theo dõi vòng đời của bug (Bug Lifecycle)
Bug không phải tạo xong là hết việc. Tester phải theo dõi đến khi bug thực sự được đóng lại. Mình từng bỏ sót bước verify sau fix - bug cũ tái xuất ở production, team mất cả ngày xử lý.
Vòng đời của bug trong Jira thường đi theo hướng sau:
Open → Bug vừa được tạo, chưa ai xử lý In Progress → Dev đang fix Resolved → Dev đã fix, chuyển lại cho tester verify Closed → Tester xác nhận fix đúng, đóng bug Reopened → Tester verify thấy vẫn còn lỗi, mở lại
Tester phải chủ động verify và đóng bug - không phải ngồi chờ dev báo 'xong rồi'
Một số team còn có thêm trạng thái Won't Fix (lỗi được thừa nhận nhưng team quyết định không fix vì ít ảnh hưởng) và Duplicate (bug đã có người báo trước).
Tester cần làm gì ở từng bước?
Khi bug chuyển sang Resolved: Nhận thông báo qua email hoặc Jira. Vào kiểm tra dev fix những gì (thường dev comment vào issue). Reproduce lại đúng steps cũ để verify.
Nếu fix đúng: Comment "Verified. Closing." và chuyển sang Closed.
Nếu vẫn còn lỗi: Comment chi tiết vấn đề còn lại, chuyển sang Reopened và assign lại cho dev.
Mẹo nhỏ: Đặt filter Jira để hiển thị tất cả bug đang ở trạng thái Resolved mà bạn là Reporter. Mỗi sáng check danh sách này trước - đừng để bug tồn đọng chờ verify quá 2 ngày.
Quản lý test case trong Jira
Jira không có tính năng test case chuyên dụng như TestRail hay Zephyr - nhưng bạn vẫn dùng Jira để track test case được, chỉ cần biết cách.
Cách 1: Dùng Task issue để quản lý test case
Mỗi tính năng cần test, tạo 1 Task với tên "[Test Case] Tính năng đăng nhập". Trong Description viết danh sách test case theo bảng:
| ID | Tên test case | Điều kiện | Expected Result | Status |
|----|---------------|-----------|-----------------|--------|
| TC01 | Đăng nhập đúng | User hợp lệ, pass đúng | Vào Dashboard | Pass |
| TC02 | Sai password | Password sai 1 lần | Hiện thông báo lỗi | Pass |
| TC03 | Tài khoản bị khóa | Sai pass 5 lần | Hiện màn hình khóa | Fail |
Cách 2: Dùng Sub-task cho từng test case
Tạo 1 Story/Task chính cho tính năng. Tạo Sub-task cho từng test case. Mỗi Sub-task có status riêng: To Do → In Progress → Pass/Fail.
Cách 2 rõ hơn khi cần báo cáo tiến độ test - PM nhìn vào board biết ngay bao nhiêu % test case đã chạy
Mình thường dùng Cách 1 khi test nhanh, Cách 2 khi sprint dài cần báo cáo chi tiết hơn.
Liên kết bug với test case
Khi chạy test case TC03 và phát hiện bug, bạn tạo Bug issue riêng rồi link vào test case đó. Trong Jira, mở issue → bấm Link → chọn "is tested by" hoặc "relates to" → nhập số issue bug.
Cách này giúp team thấy ngay: test case này tìm ra bao nhiêu bug, bug nào đang liên quan đến test case nào.
Nếu bạn muốn học hệ thống bài bản hơn về quy trình test và quản lý test case, khóa Kiểm thử phần mềm trên F8 có phần thực hành workflow khá thực tế - phù hợp nếu bạn đang chuẩn bị đi xin việc vị trí manual tester junior.
Workflow thực tế trong một sprint
Hiểu lý thuyết là một chuyện. Nhìn vào workflow thực tế của tester trong sprint mới thấy Jira kết nối lại như thế nào.
Giả sử team đang chạy sprint 2 tuần cho app thương mại điện tử:
Ngày 1-2: Sprint planning PM tạo các Story mô tả tính năng mới. Tester đọc Story, tạo Task "Viết test case cho [tính năng X]". Assign cho bản thân, chuyển sang In Progress.
Ngày 3-5: Viết test case Viết xong test case, comment vào Story để dev và PM review. Chuyển Task sang Done.
Ngày 6-10: Test và log bug Dev bàn giao tính năng, tester bắt đầu chạy test case. Mỗi bug tìm được → tạo Bug issue → assign cho dev tương ứng. Cập nhật status test case trong Task.
Workflow 2 tuần sprint - tester không chỉ test cuối sprint mà tham gia từ ngày đầu
Ngày 11-12: Verify bug fix Dev fix bug và chuyển sang Resolved. Tester check email/Jira notification, vào verify từng bug. Pass → Closed. Fail → Reopen + comment chi tiết.
Ngày 13-14: Regression testing Trước khi kết thúc sprint, chạy lại kiểm thử hồi quy (regression testing) - tức là test lại các tính năng cũ để đảm bảo code mới không làm hỏng gì. Tạo Task "Regression testing sprint 2" và track kết quả.
Ngày 14: Sprint review Báo cáo cho team: bao nhiêu test case đã chạy, bao nhiêu bug tìm được, bao nhiêu bug đã đóng, còn bao nhiêu bug open. Jira có sẵn dashboard và report, bạn chỉ cần biết cách đọc số liệu.
Thấy chưa? Tester không phải "ngồi chờ dev xong mới làm". Cả sprint đều có việc cụ thể trong Jira.
Mẹo dùng Jira hiệu quả cho fresher
Bạn sẽ không phải học Jira một mình - nhưng những mẹo này giúp bạn làm việc chuyên nghiệp hơn ngay từ ngày đầu.
Dùng filter để không bỏ sót việc
Vào Jira → Issues → Create Filter. Tạo filter:
reporter = currentUser() AND status = Resolved→ tất cả bug bạn báo đang chờ verifyassignee = currentUser() AND status != Done→ việc đang assigned cho bạn chưa xongproject = XYZ AND type = Bug AND created >= -7d→ bug mới trong 7 ngày qua
Save filter và bookmark lại. Đầu ngày mở 3 filter này trước - đảm bảo không bỏ sót gì.
Viết comment có ích
Comment trong issue không phải để chat. Mỗi comment phải có thông tin mới:
- ✅ "Verified trên Chrome 120, Windows 11. Fixed. Closing."
- ✅ "Reopen - lỗi vẫn còn khi dùng special character dạng Unicode (ví dụ: ấy)"
- ❌ "Ok mình check nhé"
- ❌ "Cảm ơn anh đã fix"
Comment ngắn mà đủ thông tin tiết kiệm thời gian cho cả team
Dùng keyboard shortcut
C- tạo issue mới từ bất kỳ đâu[- mở/đóng sidebar/- tìm kiếm nhanhE- edit issue đang mở
Đặt câu hỏi đúng cách khi bị block
Thỉnh thoảng bạn không biết assign bug cho ai, không rõ workflow của team. Đừng mò mẫm - hỏi PM hoặc senior tester. Câu hỏi tốt: "Trong project này, khi tìm được bug trong tính năng thanh toán thì mình assign cho ai?"
Câu hỏi này cho thấy bạn hiểu workflow, chỉ cần thông tin cụ thể - chứ không phải hỏi "mình phải làm gì với bug vậy anh?"
Tải checklist thực hành Jira cho fresher: Tải checklist thực hành Jira cho fresher
Chuẩn bị để xin việc với Jira
Phỏng vấn manual tester junior, câu hỏi về Jira xuất hiện ở phần lớn buổi phỏng vấn. Không phải vì Jira khó - mà vì interviewer muốn biết bạn đã thực sự làm việc trong môi trường thực tế chưa.
Câu hỏi phổ biến nhất:
- "Bạn đã dùng tool quản lý bug nào? Quy trình báo bug của bạn như thế nào?"
- "Kể cho mình nghe về một bug phức tạp bạn tìm được?"
- "Làm thế nào bạn track test case trong project?"
Cách trả lời nếu chưa có kinh nghiệm thực tế:
Dùng Jira free plan (Jira free plan) để tự tạo project, simulate workflow. Tạo vài bug report mẫu, chụp screenshot, đưa vào portfolio. Khi phỏng vấn: "Mình chưa có kinh nghiệm dự án thực tế, nhưng mình đã tự học Jira bằng cách tạo project demo và thực hành log bug, track test case theo quy trình chuẩn."
Câu trả lời đó trung thực, cho thấy chủ động học - tốt hơn nhiều so với nói "Mình biết Jira" mà không chứng minh được.
Portfolio có screenshot Jira thực tế sẽ tạo ấn tượng khác biệt so với CV chỉ liệt kê tên công cụ
Những gì nên có trong CV/portfolio:
- Screenshot board Jira với vài bug issue bạn tạo
- 1-2 bug report mẫu viết chi tiết
- Bảng test case cho tính năng đơn giản (đăng nhập, đăng ký)
25 hay 32 tuổi chưa biết Jira vẫn kịp học trước phỏng vấn. Mình từng đào tạo bạn học 32 tuổi chuyển ngành từ kế toán - mất 3 ngày học Jira từ đầu, và xin được việc tester junior sau 2 tháng. Thời gian không phải vấn đề, quan trọng là bạn có portfolio thực hành chứng minh được.
Bắt đầu từ bài này: tạo Jira free account, lập project demo, viết 5 bug report theo template ở phần 3. Làm xong 5 bug report đó, bạn đã có thứ để nói trong phỏng vấn rồi.