Smoke test và regression test: chọn bộ kiểm tra sau một thay đổi nhỏ
6 giờ tới · 10 phút đọc
Chọn smoke test hay regression test - câu hỏi thực tế
Mỗi lần code thay đổi, tester phải quyết định: chạy bộ test nào trước? Chạy hết thì tốn thời gian, bỏ qua thì rủi ro. Bài này trả lời trực tiếp câu hỏi đó qua một release giả định cụ thể.
Trước khi đi vào ví dụ, cần nắm rõ hai khái niệm:
Smoke test (kiểm tra sống còn) là bộ test tối thiểu xác nhận hệ thống có thể khởi động và thực hiện được các luồng chính nhất. Mục tiêu: phát hiện sớm lỗi nghiêm trọng trước khi đầu tư thêm thời gian kiểm thử. Thường chạy trong 10-30 phút.
Regression test (kiểm tra hồi quy) là bộ test xác nhận các tính năng đã hoạt động trước đây vẫn còn hoạt động đúng sau khi có thay đổi. Phạm vi rộng hơn nhiều - có thể từ vài giờ đến vài ngày tùy dự án.
Hai loại này không thay thế nhau. Chúng phục vụ mục tiêu khác nhau và thường được dùng theo thứ tự: smoke test trước, regression test sau nếu smoke qua.
Smoke test là cửa vào, regression test là hàng rào - thiếu cái nào cũng hở
Trong vòng đời phát triển phần mềm (SDLC), cả hai đều nằm trong giai đoạn System Testing và Regression Testing - thường xuất hiện ở cuối mỗi sprint hoặc trước khi release. Nếu bạn chưa quen với SDLC, có thể tham khảo tài liệu ISTQB Foundation Level để có nền tảng trước: ISTQB Foundation Level Syllabus.
Release giả định: hotfix cho module thanh toán
Lưu ý: Ví dụ sau là giả định bài tập minh họa, không phải dữ liệu thực tế.
Bối cảnh: Ứng dụng e-commerce có 3 module chính - Sản phẩm, Giỏ hàng, Thanh toán. Dev vừa sửa một lỗi nhỏ trong module Thanh toán: thay đổi cách tính phí vận chuyển khi áp dụng mã giảm giá.
Thay đổi cụ thể (giả định):
- File bị sửa:
checkout/shipping_calculator.js - Logic thay đổi: phí vận chuyển giờ tính trên giá sau giảm thay vì giá gốc
- Không có thay đổi nào ở database schema hay API contract
Phạm vi thay đổi quyết định phạm vi test - thay đổi nhỏ không có nghĩa là rủi ro nhỏ
Bước 1: Xác định impact area
Trước khi chọn bộ test, tester cần hỏi dev (hoặc xem diff trên Git):
- Module nào bị chạm? → Thanh toán
- Có thay đổi shared component không? → Không
- Có thay đổi API response format không? → Không
- Tính năng nào phụ thuộc vào logic vừa sửa? → Toàn bộ luồng checkout có mã giảm giá
Việc này gọi là impact analysis - phân tích phạm vi ảnh hưởng. Không làm bước này thì không có cơ sở để chọn test case.
Bước 2: Chọn smoke test cases
Sau khi deploy lên môi trường test, chạy smoke test trước. Tiêu chí chọn case vào smoke: luồng chính nhất, không thể thiếu.
| # | Test case | Pass condition |
|---|---|---|
| S1 | Mở trang chủ, trang sản phẩm load được | HTTP 200, không lỗi console nghiêm trọng |
| S2 | Thêm sản phẩm vào giỏ hàng | Số lượng trong giỏ tăng đúng |
| S3 | Vào trang checkout, điền thông tin | Form hiển thị, không lỗi JS |
| S4 | Nhập mã giảm giá hợp lệ, xem tổng tiền | Tổng tiền cập nhật, phí ship tính đúng theo logic mới |
| S5 | Bấm đặt hàng (dùng tài khoản test) | Đơn được tạo, nhận confirmation |
5 case này mất khoảng 15-20 phút nếu chạy manual. Nếu S4 fail ngay - tức là logic mới sai hoàn toàn - không cần chạy thêm gì cả. Trả về dev.
Điều kiện dừng smoke test:
- Bất kỳ case nào trong S1-S3 fail → block, không test tiếp, raise bug ngay
- S4 hoặc S5 fail → tùy severity, có thể raise bug và chạy tiếp các luồng không liên quan, hoặc block tùy team quy định
Chọn regression test cases sau smoke qua
Smoke test qua nghĩa là hệ thống sống được. Nhưng luồng checkout có mã giảm giá còn nhiều nhánh hơn 5 case trên. Lúc này cần regression test có chọn lọc.
Risk-based selection là cách chọn: ưu tiên case có rủi ro cao nhất nếu sai.
Không phải test hết, mà test đúng chỗ rủi ro nhất
Regression cases cho release này (giả định)
Nhóm 1 - Liên quan trực tiếp đến thay đổi (ưu tiên cao nhất):
| # | Test case | Lý do chọn |
|---|---|---|
| R1 | Mã giảm giá % + miễn phí ship | Edge case: ship = 0, tính trên 0 có lỗi không? |
| R2 | Mã giảm giá % + phí ship bình thường | Happy path của logic mới |
| R3 | Mã giảm giá cố định (VD: -50k) + ship | Logic khác với mã % |
| R4 | Không có mã giảm giá, ship bình thường | Đảm bảo không hỏng luồng cũ |
| R5 | Mã giảm giá hết hạn / không hợp lệ | Error handling không bị ảnh hưởng |
Nhóm 2 - Không liên quan nhưng nằm cùng luồng checkout:
| # | Test case | Lý do chọn |
|---|---|---|
| R6 | Thay đổi địa chỉ giao hàng sau khi nhập mã | Ship có tính lại không? |
| R7 | Đặt hàng nhiều sản phẩm cùng lúc | Tổng tiền tính đúng? |
Nhóm 3 - Không liên quan, có thể bỏ qua sprint này:
- Luồng đăng ký tài khoản mới
- Tìm kiếm sản phẩm
- Trang lịch sử đơn hàng (của đơn cũ)
Nhóm 3 không chạm vào code vừa thay đổi, không có shared dependency → bỏ qua để tiết kiệm thời gian. Đây là quyết định có căn cứ, không phải bỏ bừa.
Điều kiện dừng regression
Theo ISTQB, điều kiện dừng (exit criteria) thường bao gồm:
- Tất cả case trong Nhóm 1 pass
- Không còn bug Priority 1 hoặc Priority 2 nào open
- Coverage đạt mức team đã thỏa thuận trước release
Nếu R1 hoặc R2 fail, đó là block - không release dù các case khác đều pass. Nếu R6 fail nhưng R1-R5 pass, tùy team: có thể release kèm known issue nếu severity cho phép.
Giới hạn của cách tiếp cận này
Cách chọn test dựa trên impact analysis và risk không phải không có điểm yếu.
Giới hạn 1: Phụ thuộc vào thông tin từ dev. Nếu dev khai sai scope thay đổi (hoặc không biết mình đã chạm vào gì), phân tích của tester sẽ sai theo. Cách giảm rủi ro: tự xem Git diff, không chỉ hỏi miệng.
Giới hạn 2: Không phát hiện lỗi tiềm ẩn ở module không test. Nhóm 3 bị bỏ qua có lý - nhưng nếu có side effect ẩn mà không ai biết, nó sẽ lọt qua. Đây là trade-off chấp nhận được khi thời gian có hạn, nhưng cần ghi rõ trong test report.
Giới hạn 3: Smoke test không thể thay thế regression. Một số team chạy smoke qua rồi release thẳng. Rủi ro cao nếu thay đổi có nhiều dependency ẩn.
Mọi quyết định test đều là đánh đổi - quan trọng là ghi lại lý do
Giới hạn 4: Coverage metric có thể gây nhầm. 100% case pass không có nghĩa là không có bug - chỉ có nghĩa là không có bug trong số case đã viết. Đây là lý do tại sao test case design (viết case đủ tốt) quan trọng không kém việc chạy test.
Một điểm cần nhắc thêm: bài này tập trung vào manual testing cho release nhỏ. Nếu dự án đã có automation, smoke test và regression test thường được tích hợp vào CI/CD pipeline - khi đó tiêu chí chọn case vẫn giống nhau, nhưng việc thực thi được tự động hóa.
Template chọn test nhanh sau release nhỏ
Dưới đây là template câu hỏi tester có thể dùng ngay khi nhận thông báo deploy. Đây là mẫu giả định để minh họa - điều chỉnh theo quy trình thực tế của team.
Tải template chọn test sau release
Hướng dẫn dùng template:
- Điền thông tin thay đổi từ Git diff hoặc release note
- Trả lời từng câu hỏi trong phần Impact Analysis
- Dựa vào điểm rủi ro để quyết định phạm vi smoke và regression
- Ghi lại lý do bỏ qua nhóm test nào - phần này quan trọng cho audit sau này
Template không thay thế được phán đoán của tester - nó chỉ giúp không bỏ sót câu hỏi quan trọng
Khi nào nên chạy full regression
Có những tình huống risk-based selection không đủ an toàn:
- Thay đổi ở shared utility hoặc core library dùng toàn app
- Thay đổi database schema
- Upgrade framework hoặc thư viện third-party
- Release trước ngày có traffic cao (sale, event)
Trong những trường hợp này, chạy full regression dù mất thêm thời gian là quyết định hợp lý.
Tài liệu tham khảo
- ISTQB Foundation Level Syllabus - phần Test Levels và Test Types: ISTQB Foundation Level Syllabus v4.0
- Định nghĩa smoke test và sanity test trong ngữ cảnh SDLC thường bị nhầm lẫn. Smoke test kiểm tra toàn hệ thống ở mức bề mặt; sanity test đi sâu hơn vào một tính năng cụ thể sau khi fix. Hai loại này không giống nhau dù hay bị dùng lẫn.
Bài viết dựa trên ISTQB Foundation Level Syllabus v4.0 và tài liệu công cụ chính thức. Người đọc nên kiểm tra phiên bản mới nhất tại trang chủ ISTQB.