Mở đầu — vì sao bài này quan trọng
Bạn đã đi qua một chặng đường dài trong khóa học: cấu hình Jira, thiết kế workflow, viết JQL, quản lý sprint, làm roadmap. Nhưng có một mảng mà rất nhiều PM Việt Nam vẫn "làm tạm bợ" trong Jira — đó là quản lý test (test management). Tôi đã chứng kiến vô số team ghi kết quả kiểm thử vào... phần comment của một issue, hoặc dán link Google Sheet vào description, hoặc tệ hơn — QA gửi kết quả test qua Zalo. Đến lúc release, không ai trả lời được câu hỏi tưởng chừng đơn giản: "Story này đã được test đầy đủ chưa? Bao nhiêu phần trăm test case pass?"
Lý do gốc rễ nằm ở một sự thật kỹ thuật mà bài học này sẽ làm rõ: một issue trong Jira được thiết kế để mô tả một đơn vị công việc phát triển (development unit), chứ không phải một test case. Chúng có bản chất khác nhau hoàn toàn. Khi bạn cố nhét test case vào issue thường, bạn đang dùng sai công cụ, và cái giá phải trả là mất khả năng truy vết (traceability), báo cáo chất lượng mù mờ, và những cuộc họp release đầy tranh cãi.
Bài này giúp bạn — với vai trò PM — hiểu khi nào cần một công cụ test management chuyên dụng, hai cái tên phổ biến nhất trong hệ sinh thái Atlassian là Zephyr và Xray hoạt động ra sao, và quan trọng nhất: đọc dữ liệu chất lượng từ chúng để ra quyết định. Bạn không cần trở thành QA lead, nhưng bạn phải hiểu đủ để không bị "bịt mắt" về chất lượng sản phẩm mình đang giao.
Khái niệm cốt lõi
Vì sao issue thường không thay được test case
Hãy nhìn kỹ vào cấu trúc dữ liệu. Một issue (Story, Task, Bug) trong Jira có: summary, description, assignee, status, một workflow tuyến tính (To Do → In Progress → Done). Nó trả lời câu hỏi "công việc này đã xong chưa?".
Một test case lại có cấu trúc rất khác:
- Các bước thực hiện (test steps): bước 1 làm gì, bước 2 làm gì — thường là 5-15 bước tuần tự.
- Dữ liệu đầu vào (test data) cho mỗi bước.
- Kết quả mong đợi (expected result) cho mỗi bước hoặc cho toàn bộ.
- Điều kiện tiên quyết (precondition) trước khi chạy.
Issue thường không mô hình hóa được điều này. Bạn không thể "chạy lại" một Story và ghi nhận 5 kết quả khác nhau qua 5 sprint mà vẫn giữ lịch sử rõ ràng. Đó chính là lý do tồn tại của công cụ test management chuyên dụng.
Bốn thực thể (entity) bạn phải nắm
Cả Zephyr lẫn Xray đều xoay quanh bốn khái niệm nền tảng. Nắm được bốn cái này là bạn đọc được mọi báo cáo test:
- Test (Test Case): định nghĩa một kịch bản kiểm thử — gồm các bước và kết quả mong đợi. Đây là "khuôn".
- Test Set / Test Cycle (Test Plan): một nhóm các test được gom lại theo mục đích — ví dụ "Regression suite cho release 2.5" hoặc "Smoke test cho tính năng thanh toán".
- Test Execution / Test Run: một lần chạy thực tế một hoặc nhiều test trong một môi trường cụ thể (ví dụ: chạy trên staging, build 2.5.1). Đây là nơi status Pass/Fail/Blocked/WIP được ghi nhận. Một test case có nhiều execution theo thời gian.
- Traceability (truy vết): mối liên kết giữa Requirement (Story) ↔ Test ↔ Bug ↔ Execution. Đây là "vũ khí" thật sự của công cụ test management, và cũng là thứ PM cần nhất.
Zephyr vs Xray — khác biệt cho PM
Cả hai đều là app cài thêm (marketplace app) trong Jira Cloud/Data Center. Điểm khác biệt bạn cần biết ở tầm PM:
- Zephyr (Zephyr Squad / Zephyr Scale): giao diện thân thiện, dễ tiếp cận, hướng đến team QA làm test thủ công (manual) là chính. Zephyr Scale mạnh về tổ chức test case dạng thư mục (folder tree), tái sử dụng test, và reporting đẹp. Test case thường được lưu ở kho riêng, không phải mỗi test là một issue.
- Xray: tiếp cận theo triết lý "test là issue type". Test, Test Set, Test Plan, Test Execution đều là các issue type trong Jira — nghĩa là bạn dùng JQL query được cả chúng (nhớ lại Bài 8-9). Xray mạnh về tự động hóa (automation) — tích hợp Cucumber/BDD, import kết quả từ JUnit, TestNG, Robot Framework qua REST API, phù hợp team có nhiều test tự động và pipeline CI/CD.
Tình huống thực tế
Ví dụ 1: Fintech Sài Gòn — cái giá của test case trong comment
Một công ty fintech tại TP.HCM (khoảng 40 người, làm ví điện tử) trước đây quản lý test hoàn toàn bằng cách: QA nhận Story, test xong thì comment "Đã test OK trên staging" hoặc "Fail bước 3". Trong một sprint bình thường thì tạm ổn.
Vấn đề bùng nổ ở release version 3.0 với tính năng chuyển tiền liên ngân hàng. Đội có khoảng 180 test case trải trên 25 Story. Khi tổng hợp để release, PM hỏi QA lead: "Đã test hết chưa?". Câu trả lời là một file Excel tổng hợp thủ công mất 1,5 ngày để làm, và vẫn sót: có 12 test case regression từ tính năng cũ chưa ai chạy lại. Kết quả — release bị lỗi ở luồng hoàn tiền (refund), phải hotfix trong đêm, và mất niềm tin của một đối tác ngân hàng.
Sau sự cố, họ cài Zephyr Scale. Test case được tổ chức thành folder theo module (Chuyển tiền, Nạp/Rút, Refund...). Mỗi release tạo một Test Cycle mới, clone lại toàn bộ regression suite, QA chỉ việc chạy và đánh Pass/Fail. PM giờ mở dashboard thấy ngay: "Release 3.1 — 156/180 test executed, 148 pass, 6 fail, 2 blocked, 24 chưa chạy". Con số 24 chưa chạy đó chính là thứ trước đây bị bỏ sót một cách vô hình.
Bài học: khi số lượng test case và số lần regression tăng, việc thiếu khái niệm "execution tách biệt khỏi test case" khiến bạn không bao giờ biết mình còn thiếu gì. Công cụ chuyên dụng biến "không biết" thành một con số cụ thể.
Ví dụ 2: Team SaaS dùng Xray để truy vết requirement
Một startup SaaS (sản phẩm quản lý kho, team dev + QA khoảng 15 người) chọn Xray vì đội đã có sẵn bộ test tự động chạy trên CI. Họ tận dụng đặc điểm "test là issue" của Xray.
Quy trình của họ: mỗi Story bắt buộc link tới ít nhất một Test. Pipeline CI sau mỗi lần merge sẽ tự động chạy test và import kết quả JUnit XML vào Xray qua REST API, tạo ra một Test Execution mới gắn với build. PM của team này mỗi sáng chạy một JQL đơn giản kiểu:
issuetype = Story AND fixVersion = "2.6" AND issue in requirementsWithFailedTests()
Câu này (dùng hàm JQL riêng của Xray) trả về đúng danh sách Story trong release 2.6 mà đang có test fail. Trong daily stand-up (nhớ Bài 12), PM không hỏi chung chung "tính năng chạy ổn chưa" nữa mà chỉ đúng vào các Story có test đỏ.
Có lần, hàm này lộ ra một Story được dev đánh "Done" nhưng coverage = No Test — tức chưa hề có test case nào link vào. Đó là một requirement bị bỏ quên khỏi lưới an toàn. PM kịp yêu cầu bổ sung test trước khi release.
Bài học: sức mạnh thật của test management với PM không phải là "đếm pass/fail" mà là traceability — biết requirement nào đã được kiểm thử, requirement nào đang đỏ, requirement nào chưa hề có test. Với Xray, vì test là issue nên PM dùng lại đúng kỹ năng JQL đã học để tự trả lời những câu này.
Ví dụ 3: Agency và bài học "đừng dùng Jira Bug làm test case"
Một agency ở Đà Nẵng làm outsource cho khách Nhật từng có thói quen tạo mỗi test case thành một... issue type "Test" tự chế trong Jira (không dùng app nào), rồi cho nó chạy qua workflow To Do → Testing → Pass/Fail. Nghe có vẻ hợp lý.
Nhưng đến sprint thứ hai họ gặp bế tắc: một test case "Kiểm tra upload ảnh sản phẩm" cần được chạy lại ở mỗi sprint. Với mô hình issue, một khi issue đã chuyển sang "Pass" thì lịch sử lần chạy trước bị ghi đè. Muốn giữ lịch sử, họ phải clone issue mỗi sprint — dẫn tới 400+ issue "Test" rác trong backlog, làm loạn cả velocity report và JQL. Board trở nên không đọc nổi.
Họ chuyển sang Zephyr Squad. Test case giờ nằm ngoài luồng issue thường, và mỗi sprint chỉ tạo một execution mới trỏ về cùng test case — lịch sử được giữ nguyên, backlog sạch trở lại.
Bài học: tự "chế" test management bằng issue type thường thất bại đúng ở điểm cốt lõi — issue không tách được "định nghĩa test" khỏi "kết quả từng lần chạy". Đừng đi lại con đường này.
Hướng dẫn từng bước
Đây là quy trình thực dụng để một team bắt đầu quản lý test tử tế trong Jira. Tôi viết theo hướng PM điều phối, không đi sâu vào thao tác QA.
Bước 1 — Quyết định có cần công cụ chuyên dụng không. Nếu team bạn có dưới ~20 test case và hầu như không regression, một checklist trong Confluence (Bài 22) có thể đủ. Khi bạn bắt đầu regression đều đặn mỗi sprint, hoặc số test case vượt vài chục, hoặc khách hàng yêu cầu báo cáo chất lượng — đó là tín hiệu cần Zephyr/Xray.
Bước 2 — Chọn công cụ. Team làm manual testing là chính, muốn giao diện dễ: chọn Zephyr. Team có automation, CI/CD, muốn query test bằng JQL và truy vết chặt: chọn Xray. Cài từ Atlassian Marketplace (Bài 58 nói kỹ về marketplace), nhớ kiểm tra chi phí theo số user.
Bước 3 — Thiết kế cấu trúc test case. Cùng QA lead thống nhất cách tổ chức: theo module/tính năng (folder trong Zephyr, hoặc label/component trong Xray). Đặt quy ước tên rõ ràng, ví dụ: [Thanh toán] Chuyển tiền — số dư không đủ.
Bước 4 — Bắt buộc liên kết Test ↔ Story. Đây là bước PM phải kiên quyết. Định nghĩa trong Definition of Done (Bài 15): một Story chỉ được coi là "Done" khi đã có test case link vào và test đã chạy. Đây là nền tảng của traceability.
Bước 5 — Tạo Test Cycle/Execution cho mỗi lần kiểm thử. Mỗi sprint hoặc mỗi release, tạo một chu kỳ chạy mới thay vì sửa kết quả cũ. Với automation (Xray), cấu hình pipeline import kết quả tự động.
Bước 6 — Đọc và hành động trên báo cáo. Dựng một gadget/dashboard (Bài 19) hiển thị: tỉ lệ test đã chạy, tỉ lệ pass, số requirement chưa có test, số requirement đang có test fail. Dùng những con số này trong stand-up, sprint review (Bài 13) và họp release (Bài 27).
Lỗi thường gặp & mẹo
Lỗi 1 — Nhét kết quả test vào comment hoặc description. Đây là lỗi kinh điển đã nói ở phần mở đầu. Nó xóa sạch khả năng báo cáo và truy vết. Mẹo: coi comment chỉ để trao đổi, kết quả test luôn nằm trong execution.
Lỗi 2 — Sửa đè kết quả lần chạy cũ. Khi bạn edit một execution cũ thay vì tạo mới, bạn mất lịch sử — không so sánh được sprint này với sprint trước. Mẹo: mỗi lần kiểm thử là một execution/cycle mới.
Lỗi 3 — Không link Test với Story. Có bộ test đẹp nhưng không gắn với requirement thì mất luôn traceability — thứ giá trị nhất với PM. Mẹo: biến việc link thành một phần của Definition of Done, không thương lượng.
Lỗi 4 — Nhầm "test pass 100%" với "chất lượng tốt". Pass 100% trên một bộ test chỉ phủ 30% tính năng là ảo giác an toàn. Mẹo: theo dõi thêm coverage (bao nhiêu requirement có test), không chỉ pass rate.
Lỗi 5 — Bỏ quên status "Blocked". Nhiều team chỉ nhìn Pass/Fail mà quên "Blocked" (không chạy được vì môi trường/dependency). Test blocked là rủi ro ẩn. Mẹo: trong report luôn tách riêng Blocked và "chưa chạy".
Mẹo cho PM Việt Nam: bạn không cần tự viết hay chạy test case. Việc của bạn là (1) đảm bảo team có công cụ đúng, (2) đảm bảo mọi Story đều link test, (3) đọc được dashboard chất lượng và dùng nó để ra quyết định release. Ba việc đó đã đủ tạo khác biệt lớn.
Bài tập thực hành
- Phân tích tình huống hiện tại: Nhìn lại team/dự án bạn đang làm (hoặc dự án gần nhất). Kết quả test hiện đang được lưu ở đâu — comment, Excel, Zalo, hay công cụ chuyên dụng? Viết ra 3 rủi ro cụ thể của cách làm hiện tại dựa trên các lỗi đã học.
- Thiết kế một test case đúng chuẩn: Chọn một tính năng đơn giản (ví dụ: "Đăng nhập bằng OTP"). Viết một test case gồm: precondition, 5 bước thực hiện, kết quả mong đợi cho mỗi bước. So sánh nó với một Story thường để tự thấy vì sao issue không chứa nổi cấu trúc này.
- Mô phỏng traceability: Với tính năng ở bài 2, vẽ sơ đồ liên kết Story → Test → Execution → Bug (nếu fail). Chỉ ra: nếu test fail ở lần chạy thứ 2, bạn sẽ tạo Bug và link nó về đâu.
- Ra quyết định công cụ: Giả định team bạn có 60 test case, 40% là test tự động chạy trên CI, và cần báo cáo chất lượng cho khách hàng mỗi release. Bạn chọn Zephyr hay Xray? Viết 3 câu lý giải dựa trên đặc điểm hai công cụ.
- Câu hỏi release: Viết ra 4 câu hỏi mà bạn — với vai trò PM — sẽ hỏi trước khi đồng ý release, sao cho tất cả đều trả lời được bằng dữ liệu từ công cụ test management (gợi ý: bám vào pass rate, coverage, blocked, requirement chưa có test).
Tóm tắt
Điểm cốt lõi của bài này rất đơn giản nhưng dễ bị xem nhẹ: một issue trong Jira là đơn vị công việc phát triển, không phải test case. Test case có cấu trúc riêng — các bước, kết quả mong đợi — và quan trọng nhất, nó có status theo từng lần chạy, được chạy đi chạy lại qua nhiều sprint và release. Cố nhét test case vào issue thường sẽ phá vỡ khả năng báo cáo và truy vết.
Đó là lý do tồn tại của Zephyr (thân thiện, hướng manual testing) và Xray (test là issue, mạnh về automation và JQL). Bốn thực thể cần nắm: Test, Test Set/Plan, Test Execution, và sợi dây quý giá nhất — Traceability giữa Requirement, Test, Bug và Execution.
Với vai trò PM, bạn không cần biết viết test, nhưng bạn phải biết đọc dữ liệu chất lượng: bao nhiêu test đã chạy, pass rate, coverage, và đâu là requirement chưa có lưới an toàn. Chính những con số đó biến câu hỏi mơ hồ "đã test đủ chưa?" thành một quyết định release có cơ sở — và đó là điều tách biệt một PM chuyên nghiệp với người chỉ "đoán" về chất lượng.