Theo chuẩn IEEE610.12-90, kiểm thử hồi quy là "Sự kiểm tra lại có lựa chọn của một hệ thống hay thành phần để xác minh là những sự thay đổi không gây ra những hậu quả không mong muốn ...". Trên thực tế, quan niệm này là chỉ ra rằng phần mềm mà đã qua được các kiểm tra trước đó vẫn có thể được kiểm tra lại. Beizer định nghĩa đó là sự lặp lại các kiểm tra để chỉ ra rằng cách hoạt động của phần mềm không bị thay đổi, ngoại trừ tới mức như yêu cầu. Hiển nhiên là sự thỏa hiệp phải được thực hiện giữa sự đảm bảo được đưa ra bởi kiểm thử hồi quy mỗi lần thực hiện một sự thay đổi và những tài nguyên được yêu cầu thực hiện điều đó.
Regression Testing tập trung vào việc tìm kiếm lỗi sau khi xảy ra việc
thay đổi code. Đặc biệt, nó tìm kiếm theo cách hồi quy ( đệ quy) hoặc
kiểm tra các bug cũ có bị lại hay không. Hồi quy như vậy xảy bất cứ khi
nào mà chức năng phần mềm trước đây làm việc đúng đã ngưng làm việc theo
mong đợi. Điển hình, hồi quy xảy ra như là một kết quả không mong muốn
của việc thay đổi chương trình, khi phần code của phần mềm mới được phát
triển xung đột với code cũ đang có. Phương pháp thông thường của kiểm
tra hồi quy là bao gồm việc chạy lại các kiểm thử trước đây và kiểm tra
xem có lỗi đã được fixed trước đây bị lỗi lại (bị lại các lỗi cũ đã
fixed rồi). Độ sâu của việc kiểm thử phụ thuộc vào các giai đoạn trong
quá trình phát hành và rủi ro của các tính năng được thêm vào. Chúng có
thể được hoàn thành – vì việc thay đổi đã thêm vào sau bản phát hành
hoặc coi nó là mạo hiểm, rất hời hợt, bao gồm các kiểm thử trường hợp
đúng (positive) trên từng chức năng – nếu các thay đổi được thêm vào
trước khi phát hành hoặc coi nó ít rủi ro.
Regression Testing không phải là 1 cấp độ kiểm thử, nó chỉ đơn thuần kiểm tra lại phần mềm sau
khi có một sự thay đổi xảy ra, để bảo đảm phiên bản phần mềm mới thực hiện tốt
các chức năng như phiên bản cũ và sự thay đổi không gây ra lỗi mới trên
những chức năng vốn đã làm việc tốt. Regression test có thể thực hiện
tại mọi mức kiểm tra.
Ví dụ: một phần mềm đang phát triển khi kiểm thử cho thấy nó chạy tốt các chức năng A, B và C. Khi có thay đổi code của chức năng C, nếu chỉ kiểm thử chức năng C thì chưa đủ, cần phải kiểm thử lại tất cả các chức năng khác liên quan đến chức năng C, trong ví dụ này là A và B. Lý do là khi C thay đổi, nó có thể sẽ làm A và B không còn làm việc đúng nữa.
Mặc dù không là một cấp độ kiểm thử, thực tế lại cho thấy Regression Test là một trong những loại kiểm thử tốn nhiều thời gian và công sức nhất. Tuy thế, việc bỏ qua Regression Test là "không được phép" vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta "tưởng rằng" những lỗi đó hoặc không có hoặc đã được kiểm tra và sửa chữa rồi!.
Ví dụ: một phần mềm đang phát triển khi kiểm thử cho thấy nó chạy tốt các chức năng A, B và C. Khi có thay đổi code của chức năng C, nếu chỉ kiểm thử chức năng C thì chưa đủ, cần phải kiểm thử lại tất cả các chức năng khác liên quan đến chức năng C, trong ví dụ này là A và B. Lý do là khi C thay đổi, nó có thể sẽ làm A và B không còn làm việc đúng nữa.
Mặc dù không là một cấp độ kiểm thử, thực tế lại cho thấy Regression Test là một trong những loại kiểm thử tốn nhiều thời gian và công sức nhất. Tuy thế, việc bỏ qua Regression Test là "không được phép" vì có thể dẫn đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta "tưởng rằng" những lỗi đó hoặc không có hoặc đã được kiểm tra và sửa chữa rồi!.
