Regression Testing
Chạy lại các phần đã chạy đúng trước đây để chắc rằng thay đổi mới không làm hỏng cái cũ. Càng sửa nhiều, càng phải chạy, và đây là lý do chính khiến người ta đầu tư test tự động.
Định nghĩa
Sửa một chỗ, hỏng một chỗ khác. Ai làm phần mềm lâu đều dính. Regression testing là biện pháp có hệ thống để chuyện đó không lọt xuống người dùng: sau mỗi thay đổi, chạy lại những phần vốn đang chạy đúng.
Kiểm thử hồi quy chạy lại chức năng cũ để phát hiện tác dụng phụ của thay đổi mới.
Regression và retest khác nhau
Hai từ này bị dùng lẫn hằng ngày, kể cả trong họp.
| Retest | Regression | |
|---|---|---|
| Chạy cái gì | Đúng case đã fail trước đó | Các case liên quan vốn đang pass |
| Mục đích | Xác nhận defect đã được fix | Phát hiện chức năng cũ bị vỡ |
| Bắt buộc | Có, mỗi defect fix xong | Có, khi thay đổi đủ lớn |
| Tự động hóa | Ít khi, chạy tay là chính | Rất đáng tự động hóa |
Trong Jira, retest là bước đưa defect từ Fixed sang Verified. Còn regression là một đợt chạy riêng, thường trước khi phát hành.
Khi nào chạy
- Trước mỗi lần release, kể cả release nhỏ.
- Sau khi fix nhóm defect có ảnh hưởng chéo, ví dụ sửa hàm tính giá dùng chung.
- Sau khi nâng cấp thư viện, đổi cấu hình server, đổi phiên bản database.
- Sau hotfix trên PROD — phần này hay bị bỏ vì vội, và cũng là chỗ hay vỡ thêm.
Chọn bộ regression khi không đủ thời gian
Chạy lại cả 780 case trước mỗi release là điều không dự án nào kịp làm thủ công. Cách chọn thực dụng:
- Luồng sinh tiền và luồng pháp lý: thanh toán, xuất hóa đơn, tính thuế. Luôn nằm trong bộ.
- Phần vừa bị sửa và phần dùng chung module với nó.
- Phần từng hỏng nhiều lần trong quá khứ. Lịch sử defect là chỉ dẫn tốt.
- Phần người dùng chạm nhiều nhất theo số liệu thực tế.
Giữ bộ này khoảng 15–25% tổng số case, chạy được trong nửa ngày. Rồi mỗi quý xem lại một lần, bỏ bớt case đã lỗi thời.
Ví dụ thực tế
Kế toán phát hiện trước cả QC: 214 giao dịch hoàn vé bị tính phí 0đ, hai ngày sau khi bản build lên PROD. Đội vừa sửa chức năng đổi vé, mà chức năng đó dùng chung hàm tính phí với hoàn vé — chi tiết lúc sửa chẳng ai nghĩ tới. Nhà xe chạy tuyến liên tỉnh, cao điểm hơn 8.700 vé mỗi ngày, nên hai ngày là đủ để con số 214 chồng lên.
Sau vụ đó, bộ regression có thêm 12 case cố định cho toàn bộ nhóm nghiệp vụ liên quan tới phí, bắt buộc chạy trước mọi release chạm vào module vé. Không ai mua thêm công cụ nào cho vụ đó. Chỉ là 12 case được ghi vào một danh sách mà cả team chịu chạy.
Tự động hóa tới đâu
Regression là ứng viên số một cho tự động hóa vì cùng một bộ case chạy đi chạy lại hàng chục lần. Nhưng đừng bắt đầu bằng việc tự động hóa toàn bộ giao diện — mấy script đó gãy mỗi lần đổi layout, rồi cả team quay ra sửa script thay vì test.
Bắt đầu từ API. Ổn định hơn, chạy nhanh hơn, và phần lớn quy tắc nghiệp vụ nằm ở đó. Giao diện chỉ tự động hóa vài luồng xương sống.
Chỗ BA nên để ý
Khi bạn viết CR hoặc yêu cầu thay đổi một quy tắc dùng chung, hãy ghi rõ trong phần đánh giá tác động: những chức năng nào khác đang dùng quy tắc đó. Danh sách đó chính là đầu vào cho QC chọn bộ regression. Bạn là người duy nhất trong dự án nhìn được nghiệp vụ ở phạm vi đủ rộng để liệt kê nó.
