Regression Testing: Cách lập kế hoạch và thực hiện regression test hiệu quả
một tháng trước · 10 phút đọc
Regression testing là gì và tại sao không thể bỏ qua?
Mình nhớ lần đầu tham gia dự án, team dev vừa fix một bug nhỏ trong module thanh toán. Mình nghĩ: "Chỉ sửa một dòng code, test lại tính năng đó là đủ." Kết quả? Khách hàng báo không thêm được sản phẩm vào giỏ hàng - một tính năng hoàn toàn khác. Không ai test lại phần cũ sau khi sửa. Bug nổ production vào đúng ngày sale lớn.
Đó là lúc mình thật sự hiểu kiểm thử hồi quy (regression testing) quan trọng đến mức nào.
Regression testing là quá trình test lại các tính năng đã hoạt động trước đó, sau mỗi lần có thay đổi trong code. Lý do đơn giản: code trong một hệ thống phần mềm thường kết nối với nhau. Sửa chỗ A có thể vô tình làm hỏng chỗ B - ngay cả khi B trông có vẻ không liên quan gì.
Một thay đổi nhỏ có thể kéo theo lỗi ở tính năng tưởng không liên quan
Nếu bạn hỏi "thay đổi nhỏ thì cần test lại nhiều thứ vậy không?", câu trả lời là: phụ thuộc vào cách bạn chọn test case. Không ai test lại toàn bộ hệ thống mỗi lần - đó là lý do cần biết cách lập kế hoạch regression cho hợp lý.
Về bản chất, regression testing không phải để tìm bug mới - mà để đảm bảo bug cũ không xuất hiện lại và thay đổi mới không phá vỡ thứ đang chạy tốt.
Khi nào cần chạy regression test?
Không phải lúc nào cũng cần chạy toàn bộ regression. Nhưng có những thời điểm mà bỏ qua là rủi ro rất lớn.
Bắt buộc chạy regression khi:
- Dev vừa fix bug và merge code lên nhánh chính
- Team release tính năng mới (dù lớn hay nhỏ)
- Refactor code - tức là viết lại code bên trong nhưng kết quả đầu ra vẫn phải giống cũ
- Thay đổi cấu hình hệ thống, database, hoặc thư viện bên thứ ba
- Trước mỗi sprint release trong dự án Agile
5 thời điểm không nên bỏ qua regression - đặc biệt trước release
Trong dự án Agile mà mình hay làm, mỗi sprint kéo dài 2 tuần. Cuối sprint, trước khi demo với khách hàng, team luôn dành 1-2 ngày chạy regression cho các tính năng cũ. Không phải test tất cả - mà test những phần có khả năng bị ảnh hưởng bởi code thay đổi trong sprint đó.
Bạn có thể thắc mắc: "Dev đã test rồi, mình test lại làm gì?" Dev test để xác nhận code họ viết hoạt động đúng logic. Tester chạy regression để xác nhận toàn bộ hệ thống vẫn hoạt động đúng từ góc nhìn người dùng. Hai việc này bổ sung cho nhau, không thay thế nhau.
Một dấu hiệu nhận biết nữa: nếu bạn đang dùng Jira và thấy nhiều ticket "bug fix" được close trong một sprint, đó là lúc cần cẩn thận hơn với regression. Fix nhiều = thay đổi nhiều = rủi ro cao hơn.
Cách chọn test case cho regression
Đây là phần nhiều fresher hay nhầm nhất: nghĩ rằng regression = test lại tất cả mọi thứ. Không phải vậy. Test tất cả tốn thời gian mà không hiệu quả. Vấn đề là chọn đúng test case.
Có 3 tiêu chí chính để chọn:
1. Tính năng có liên quan đến thay đổi Dev vừa sửa module đăng nhập → cần test đăng nhập, đăng xuất, quên mật khẩu, phân quyền người dùng. Những thứ dùng chung token hoặc session với đăng nhập đều có nguy cơ bị ảnh hưởng.
2. Tính năng quan trọng với người dùng (critical path) Dù không liên quan trực tiếp, luôn test những tính năng cốt lõi: thanh toán, tạo tài khoản, tìm kiếm, checkout. Nếu những thứ này hỏng, người dùng không dùng được app.
3. Tính năng từng có bug trước đây Bug xuất hiện một lần thường có xu hướng xuất hiện lại, đặc biệt sau các thay đổi liên quan. Giữ danh sách những khu vực "dễ vỡ" này để ưu tiên.
3 tiêu chí chọn test case - thiếu một trong ba là dễ bỏ sót lỗi
Mình hay dùng một quy tắc đơn giản: vẽ sơ đồ tác động (impact map) ngay khi nhận thông tin về thay đổi. Hỏi dev: "Chỗ này thay đổi có ảnh hưởng đến module nào khác không?" Câu trả lời của dev kết hợp với kiến thức về hệ thống sẽ giúp bạn khoanh vùng chính xác hơn nhiều.
Với fresher, điều này nghe có vẻ khó vì chưa quen hệ thống. Bình thường thôi - mình cũng mất 1-2 tháng đầu mới bắt đầu nhận ra pattern. Cứ hỏi dev hoặc tester senior, đừng ngại.
Cách ưu tiên test case khi không đủ thời gian
Deadline gấp là thực tế trong nghề tester. Không phải lúc nào cũng có đủ thời gian test hết danh sách. Biết cách ưu tiên giúp bạn tối ưu coverage trong thời gian giới hạn.
Mình thường dùng ma trận ưu tiên đơn giản dựa trên 2 yếu tố: mức độ rủi ro (xảy ra lỗi thì hậu quả nặng cỡ nào) và khả năng bị ảnh hưởng (thay đổi lần này có dễ làm hỏng chỗ này không).
| Rủi ro cao | Rủi ro thấp |
|---|---|
| Ưu tiên 1: Test ngay, kỹ nhất | Ưu tiên 3: Test nếu còn thời gian |
| Ưu tiên 2: Test sau khi xong P1 | Ưu tiên 4: Có thể bỏ qua lần này |
(Hàng trên: khả năng bị ảnh hưởng cao. Hàng dưới: khả năng bị ảnh hưởng thấp)
Ma trận 4 ô giúp quyết định nhanh khi thời gian eo hẹp
Ví dụ cụ thể: app thương mại điện tử, dev vừa thay đổi logic tính phí ship.
- P1: Tính phí ship (liên quan trực tiếp + rủi ro cao nếu tính sai)
- P1: Tổng tiền thanh toán (phụ thuộc phí ship + ảnh hưởng trực tiếp đến doanh thu)
- P2: Màn hình giỏ hàng (hiển thị phí ship + người dùng nhìn thấy)
- P3: Lịch sử đơn hàng (ít liên quan đến logic phí ship)
- P4: Trang hồ sơ cá nhân (không liên quan)
Với cách phân loại này, ngay cả khi chỉ có 2 tiếng, bạn vẫn cover được những điểm quan trọng nhất.
Một mẹo nhỏ: trong Jira, bạn có thể gắn label hoặc priority cho từng test case regression. Khi sprint gấp, lọc theo priority để biết làm gì trước mà không cần đọc lại từ đầu.
Công cụ hỗ trợ regression testing: Jira và TestLink
Viết test case ra giấy hay Excel rồi chạy tay được - nhưng khi dự án có vài trăm test case, bạn cần công cụ để quản lý cho có hệ thống.
Hai công cụ mình hay dùng nhất:
Jira
Jira không phải công cụ quản lý test case thuần túy, nhưng kết hợp với plugin như Zephyr Scale hoặc Xray, nó trở nên rất mạnh. Bạn có thể:
- Tạo test cycle (chu kỳ kiểm thử) riêng cho từng sprint
- Link test case với user story hoặc bug ticket
- Theo dõi tiến độ chạy test theo thời gian thực
- Báo cáo kết quả regression trực tiếp trên Jira dashboard
Trong thực tế, mình thường tạo một ticket dạng "Regression Testing - Sprint X" và checklist các tính năng cần test bên trong. Đơn giản nhưng đủ dùng cho team nhỏ.
Jira + Xray hoặc Zephyr giúp quản lý regression có hệ thống hơn
TestLink
TestLink là công cụ quản lý test case miễn phí, thiết kế riêng cho tester. Phù hợp nếu team chưa có ngân sách cho Jira premium plugin.
Các tính năng chính:
- Tổ chức test case theo dạng cây (test suite → test case)
- Tạo test plan và gán test case vào plan
- Chạy test và ghi kết quả pass/fail trực tiếp
- Xuất báo cáo ra PDF hoặc Excel
TestLink phù hợp hơn cho team có nhiều test case cần quản lý dài hạn. Jira phù hợp hơn khi cả team đã dùng Jira cho task management và muốn tích hợp luôn.
Với fresher, lời khuyên của mình là học Jira trước - vì hầu hết công ty ở Việt Nam hiện tại đang dùng Jira. Nắm được cách tạo ticket, gắn label, tạo filter là đã đủ để làm việc được ngay.
Cách lập kế hoạch regression test trong dự án Agile
Agile có nhịp sprint nhanh - thường 2 tuần. Điều đó có nghĩa regression cũng phải được lên kế hoạch từ sớm, không phải đợi đến ngày cuối mới nghĩ.
Mình thường làm theo quy trình sau:
Ngày 1-2 sprint: Nhận thông tin về các tính năng sẽ thay đổi. Bắt đầu identify tập test case regression cần chạy.
Ngày 3-10: Dev đang code, mình cập nhật/viết thêm test case mới nếu cần. Review lại test case regression cũ để đảm bảo vẫn còn phù hợp với hệ thống.
Ngày 11-12: Dev done, mình bắt đầu chạy regression. Ưu tiên theo ma trận đã chia ở trên.
Ngày 13: Tổng hợp kết quả. Báo cáo cho team lead và stakeholder.
Ngày 14: Sprint review + retrospective. Góp ý về quy trình nếu có gì cần cải thiện.
Lên kế hoạch regression từ ngày 1 - không phải đợi dev xong mới nghĩ
Một lỗi phổ biến mình hay thấy ở fresher: đợi dev xong 100% mới bắt đầu lên kế hoạch regression. Đến lúc đó thường chỉ còn 1-2 ngày, test được gì hay nấy. Kết quả là bỏ sót test case, coverage thấp, bug lọt.
Chuẩn bị sớm không có nghĩa là test sớm - mà là biết sẽ test gì khi đến thời điểm. Khác nhau hoàn toàn.
Nếu team bạn dùng Jira, tạo sẵn một filter lưu danh sách test case regression. Mỗi sprint chỉ cần review lại danh sách đó thay vì xây dựng từ đầu. Tiết kiệm được 30-40% thời gian chuẩn bị.