Test Management Trong ISTQB: Quản Lý Test Plan Và Test Case
4 tháng trước · 11 phút đọc
Test management là gì và tại sao ISTQB nhấn mạnh?
Mình nhớ lần đầu đọc syllabus ISTQB Foundation, phần Test Management trông có vẻ "hành chính" nhất - toàn test plan, risk, resource. Nhiều bạn fresher hay bỏ qua phần này để tập trung vào test technique. Sai lầm.
Test management không phải việc của manager. Đây là nền tảng để mọi hoạt động testing có hướng đi. Không có test plan rõ ràng, team test theo bản năng - ai thích test gì thì test, cuối sprint không biết đã cover được gì.
Test management là khung xương, test case chỉ là thịt
ISTQB định nghĩa test management bao gồm:
- Lập kế hoạch kiểm thử (test planning)
- Giám sát và kiểm soát (monitoring & control)
- Quản lý rủi ro (risk management)
- Quản lý defect (defect management)
Về mặt thực tế đi làm, bạn sẽ thấy những thứ này xuất hiện dưới dạng: ai viết test plan, ai assign test case, làm sao biết test xong chưa, bug được track ở đâu.
Phần này chiếm 22.5% (ISTQB Guru) câu hỏi trong đề thi ISTQB Foundation - không phải nhỏ. Và trong phỏng vấn tester, câu "Bạn đã từng lập test plan chưa?" xuất hiện nhiều hơn bạn nghĩ.
Cấu trúc test plan theo ISTQB
Test plan là tài liệu mô tả phạm vi, cách tiếp cận, nguồn lực và lịch trình cho hoạt động testing. Nghe phức tạp, nhưng thực ra trả lời 5 câu hỏi cơ bản:
- Test cái gì? (scope)
- Test như thế nào? (approach)
- Ai test? (resources)
- Test khi nào? (schedule)
- Rủi ro là gì? (risks)
5 câu hỏi này giúp test plan không bỏ sót phần quan trọng
ISTQB Foundation dựa theo IEEE 829 liệt kê các thành phần của test plan. Phiên bản đầy đủ gồm hơn 15 mục - nhưng với dự án nhỏ hoặc fresher mới đi làm, bạn không cần cả 15 mục đó ngay.
Mình thường hướng dẫn bạn mới bắt đầu với 7 mục cốt lõi:
| Mục | Nội dung |
|---|---|
| Test scope | Tính năng nào được test, tính năng nào không |
| Test approach | Manual hay automation, test level nào (unit/integration/system) |
| Entry/exit criteria | Điều kiện bắt đầu và điều kiện kết thúc testing |
| Test environment | Môi trường test (browser, OS, device) |
| Resources | Ai phụ trách phần nào |
| Schedule | Timeline từng giai đoạn |
| Risks | Rủi ro tiềm ẩn và cách xử lý |
Bạn đang tự học và muốn có template để luyện? Tải ở đây: Tải template test plan
Entry/exit criteria là phần nhiều bạn fresher hay bỏ qua nhất. Entry criteria là điều kiện để BẮT ĐẦU test - ví dụ: build ổn định, môi trường ready, test case đã review xong. Exit criteria là khi nào DỪNG - ví dụ: 95% test case pass, không có critical bug open.
Thiếu entry/exit criteria, testing kéo dài vô tận hoặc kết thúc quá sớm vì "deadline rồi".
Tổ chức test case hiệu quả
Viết test case không khó. Viết test case có tổ chức mới là kỹ năng.
Bạn đang review PR. Thấy folder test case gồm 200 file đặt tên test1.xlsx, test_final.xlsx, test_final_v2_use_this.xlsx. Không ai biết bắt đầu từ đâu. Đây là hậu quả của việc không có cấu trúc test case từ đầu.
Đặt tên file rõ ràng tiết kiệm 30 phút mỗi lần cần tìm lại
ISTQB không quy định format test case cụ thể, nhưng các thành phần cơ bản cần có:
- Test case ID: định danh duy nhất (ví dụ: TC_LOGIN_001)
- Test case name: mô tả ngắn về mục đích
- Precondition: điều kiện tiên quyết trước khi thực thi
- Test steps: các bước thực hiện cụ thể
- Expected result: kết quả mong đợi
- Actual result: kết quả thực tế (điền khi chạy)
- Status: Pass/Fail/Blocked/Not run
Cách tổ chức theo module là phổ biến nhất. Một app thương mại điện tử có thể chia: Login → Product → Cart → Checkout → Payment. Mỗi module là một nhóm test case riêng, có prefix riêng.
Ngoài ra, mình hay phân loại theo test type trong mỗi module:
- Happy path (luồng chính, input đúng)
- Negative test (input sai, edge case)
- Boundary test (giá trị biên)
Không cần nhớ hết ngay. Đi làm thực tế, bạn sẽ quen dần. Quan trọng là hiểu tại sao phân loại: để khi có ít thời gian, bạn biết ưu tiên chạy happy path trước, negative test sau.
Bạn muốn xem template test case cụ thể để thực hành? Tải ở đây: Tải template test case HTML
Quản lý rủi ro trong testing
Risk-based testing là một trong những khái niệm ISTQB nhấn mạnh nhất, và cũng là thứ phân biệt tester có kinh nghiệm với tester chỉ biết chạy theo checklist.
Tại sao cần quản lý rủi ro? Vì không bao giờ đủ thời gian test tất cả mọi thứ. Luôn có deadline, luôn có resource constraint. Bạn phải chọn test cái gì trước - và lựa chọn đó nên dựa trên rủi ro, không phải cảm tính.
Ưu tiên test những gì rủi ro cao trước khi hết thời gian
ISTQB phân biệt hai loại rủi ro chính:
Product risk - rủi ro liên quan đến chất lượng sản phẩm:
- Tính năng thanh toán bị lỗi → mất tiền khách hàng
- Dữ liệu cá nhân bị lộ → vi phạm bảo mật
- App crash khi có nhiều user đồng thời
Project risk - rủi ro ảnh hưởng đến dự án:
- Thiếu resource tester
- Môi trường test không ổn định
- Requirement thay đổi liên tục
Trong thực tế, bạn sẽ làm việc chủ yếu với product risk. Cách đánh giá đơn giản nhất là Risk Matrix: chấm điểm mỗi tính năng theo 2 chiều - likelihood (khả năng xảy ra lỗi) và impact (mức độ ảnh hưởng nếu lỗi xảy ra).
| Tính năng | Likelihood (1-5) | Impact (1-5) | Risk Score | Ưu tiên |
|---|---|---|---|---|
| Đăng nhập | 3 | 5 | 15 | Cao |
| Đổi avatar | 2 | 1 | 2 | Thấp |
| Thanh toán | 4 | 5 | 20 | Rất cao |
Tính năng có Risk Score cao nhất → test trước, viết nhiều test case hơn, test kỹ hơn.
Mình từng skip risk assessment vì nghĩ "dự án nhỏ, biết hết rồi". Kết quả: dành 2 ngày test tính năng ít quan trọng, đến ngày release mới phát hiện bug nghiêm trọng ở thanh toán. Không đủ thời gian fix đúng cách. Bài học đắt giá.
Monitoring, control và các chỉ số theo dõi
Lập xong test plan không phải xong. Phần monitoring & control là để đảm bảo testing đang đi đúng hướng - không vượt schedule, không miss scope.
Bao nhiêu lần bạn thấy team test "chạy ào ào" nhưng đến cuối sprint không ai biết còn bao nhiêu test case chưa chạy?
Số liệu không biết nói dối - tracking giúp bạn biết sự thật sớm hơn
ISTQB đề cập các test metrics (chỉ số kiểm thử) thường dùng để monitor:
- Test case execution rate: bao nhiêu % test case đã chạy
- Pass rate: bao nhiêu % test case pass
- Defect density: số lỗi / số tính năng hoặc số dòng code
- Defect detection efficiency (DDE): % lỗi tìm được trước khi release
Với fresher, bạn không cần tính DDE ngay. Nhưng biết track 2 chỉ số đơn giản nhất: "test case còn lại" và "bug open" - hai con số này cho biết dự án đang ở đâu.
Khi thực tế lệch kế hoạch (và sẽ lệch), đó là lúc control - điều chỉnh: thêm resource, giảm scope, extend timeline. Test manager làm điều này; nhưng tester hiểu quy trình sẽ chủ động report sớm thay vì để đến deadline mới báo.
Defect lifecycle cũng thuộc phần này. Một bug đi qua các trạng thái: New → Assigned → In Progress → Fixed → Retest → Closed (hoặc Reopened). Bạn cần hiểu để report bug đúng, theo dõi bug đúng, không bỏ sót retest.
Thiếu monitoring = không biết testing đang đủ hay thiếu. Biết mà không control = biết rồi để đó. Cả hai đều nguy hiểm như nhau.
Chuẩn bị phỏng vấn với kiến thức test management
Phỏng vấn tester fresher thường hỏi về test management theo 3 hướng: định nghĩa, ví dụ thực tế, và câu hỏi tình huống.
Câu hỏi định nghĩa - trả lời ngắn, dùng từ ISTQB nhưng giải thích bằng lời thường:
"Test plan là gì?" → "Tài liệu mô tả sẽ test cái gì, test như thế nào, ai test, test khi nào và rủi ro là gì."
"Entry/exit criteria là gì?" → "Entry criteria là điều kiện để bắt đầu test - như build ổn định, môi trường ready. Exit criteria là điều kiện để dừng - như 95% test case pass, không có critical bug."
Trả lời phỏng vấn không cần thuộc lòng - hiểu rõ thì diễn đạt tự nhiên hơn
Câu hỏi ví dụ - luôn chuẩn bị 1-2 ví dụ cụ thể từ dự án thực hành:
"Bạn có kinh nghiệm lập test plan không?" → Dù chưa đi làm, nếu bạn đã luyện template trên dự án nhỏ, câu trả lời là có. Mô tả app bạn test, scope bao gồm gì, risk bạn xác định.
Câu hỏi tình huống thường gặp:
- "Nếu không đủ thời gian test hết, bạn làm gì?" → Dùng risk-based testing, ưu tiên tính năng risk cao
- "Làm sao biết test đã đủ chưa?" → Dựa vào exit criteria đã định nghĩa từ đầu
- "Khi phát hiện bug gần deadline, bạn xử lý sao?" → Report ngay với severity/priority rõ ràng, để team quyết định fix hay defer
Mình hay thấy bạn fresher học xong lý thuyết nhưng không thực hành viết test plan. Kết quả là phỏng vấn hỏi "bạn đã viết test plan chưa" thì lúng túng.
Lời khuyên thực tế: lấy một app nhỏ (như trang đăng nhập, form đặt hàng) và tự lập test plan theo template. Làm xong 1-2 lần, câu trả lời phỏng vấn sẽ tự nhiên hơn rất nhiều.
30 tuổi chuyển ngành vẫn không muộn. Lớp mình từng có bạn từ kế toán, không biết gì về testing, sau 6 tháng luyện đề ISTQB và thực hành project nhỏ - pass Foundation, phỏng vấn tự tin, nhận offer fresher tester. Điểm khác biệt: bạn ấy làm đủ bộ test plan + test case thực tế thay vì chỉ đọc lý thuyết.
Test kỹ 1 lần > fix lỗi nhiều lần. Comment bên dưới nếu bạn cần mình giải thích thêm phần nào nhé!