1. Khái niệm
- Retesting (Kiểm tra lại): là một loại thử nghiệm được thực hiện để kiểm tra các case Failed trong lần thực hiện cuối cùng thành các case Passed sau khi các lỗi đã được fix.
- Regression testing (Kiểm tra hồi quy): là một loại kiểm thử phần mềm được thực hiện để kiểm tra xem thay đổi code có làm xáo trộn hay ảnh hưởng đến các tính năng và chức năng hiện tại của Ứng dụng không.
2. Retesting
- Kiểm tra lại được thực hiện để đảm bảo rằng lỗi được sửa bằng cách chạy lặp lại cùng một trường hợp kiểm thử. Nó được chạy trên cùng một nơi thay đổi đã được thực hiện.
- Ngoài ra, nó không liên quan đến việc kiểm tra các phần khác của phần mềm. Hơn nữa, Kiểm tra lại có nghĩa là chỉ kiểm tra lại một phần nhất định của ứng dụng. Kiểm tra lại không xem xét nó sẽ ảnh hưởng như thế nào trong phần khác hoặc trong toàn bộ ứng dụng.
- Việc kiểm tra lại chỉ được thực hiện đối với các trường hợp Thử nghiệm thất bại. Khi có ít thời gian Thử nghiệm lại được ưu tiên hơn so với thử nghiệm hồi quy. Ví dụ: Bạn phải thực hiện test cho 1 màn hình với lượng test case bằng 500. Sau khi thực hiện test 500 case đó, có 30 test case fail. Vì vậy, bạn sẽ report 30 bug và gán cho Developer. Sau khi bug được fixed bởi developer, bạn sẽ thực hiện verify lại những bug này. Làm thế nào để xác minh lại 30 bug đã được fixed đó? Đương nhiên là bạn phải thực thi lại 30 test case lỗi. Đó chính là Retesting.
3. Regression testing
- Kiểm tra hồi quy được thực hiện để đảm bảo rằng sự thay đổi trong một phần của phần mềm không ảnh hưởng đến các phần khác của ứng dụng.
- Hồi quy là thực hiện lại các trường hợp thử nghiệm cho phần không thay đổi để thấy rằng chức năng không bị thay đổi và đang hoạt động tốt.
- Chu trình như sau: Design New Test => Execute test => Re test => Regression test
- Khi một lỗi được báo cáo, nhóm Dev sẽ sửa lỗi. Có khả năng dev sẽ thay đổi code và có thể dẫn đến các ảnh hưởng có thể không nhìn thấy ngay lập tức. Vì vậy, bất cứ khi nào thay đổi code, nhóm QA phải đảm bảo rằng không có ảnh hưởng của phần thay đổi đối với các phần khác của hệ thống.
- Ví dụ 1: Cũng với ví dụ như trên. Bạn có 500 test case và bạn thực hiện test tất cả chúng. Có 470 test case pass, 30 test case fail. Khi đó developer sẽ fix chúng, sau đó bạn thực hiện Retesting trên tất cả các test case fail. Điều gì sẽ xảy ra với 470 test case pass? Chúng ta cần thực hiện test lại chúng để kiểm tra rằng không có bất kỳ bug nào phát sinh trong quá trình dev fix bug. Vì vậy, chúng ta cần thực hiện kiểm thử hồi quy để đảm bảo không có bất kỳ tác động nào của việc sửa code trên phần mềm.
- Trong quá trình kiểm thử hồi quy, việc kiểm thử toàn bộ lại các case pass là không thể, vì vậy các trường hợp kiểm thử thường phụ thuộc vào yêu cầu của khách hàng cũng như việc đánh giá mức độ ảnh hưởng của việc thay đổi code trong phần mềm.
- Kiểm thử hồi quy cũng có thể được thực hiện bởi kiểm thử tự động, việc kiểm thử lặp đi lặp lại các case sẽ rất tốn thời gian khi thực hiện kiểm thử thủ công.
- Ví dụ 2: Như chúng ta đã biết khách hàng có thể thay đổi requirement ở bất cứ thời điểm nào. Vì vậy để thỏa mãn sự thay đổi của khách hàng, developer cần thay đổi logic và code của họ. Sau khi developer thay đổi code, chúng ta cần thực hiện regression testing trên những test case đã pass trước đó.
Tóm lại, chúng ta sử dụng kiểm thử hồi quy trong các tình huống sau:
- Khi fix bug
- Khi thêm tính năng mới
- Khi xóa một tính năng bất kỳ
- Khi thay đổi requirement
4. So sánh giữa Retesting với Regression testing
| Regression Testing | Re-testing |
|---|---|
| - Regression Testing (Kiểm tra hồi quy) được thực hiện để xác nhận xem một chương trình hoặc thay đổi code gần đây có ảnh hưởng xấu đến các tính năng hiện có hay không | - Re-testing (Kiểm tra lại) được thực hiện để xác nhận các trường hợp thử nghiệm Failed thì trong lần thực hiện cuối cùng được Passed sau khi các lỗi được khắc phục |
| - Mục đích của Kiểm tra hồi quy là việc thay đổi code mới nhất sẽ không ảnh hưởng đến các chức năng hiện có | - Kiểm tra lại được thực hiện trên cơ sở các Defect được fix |
| - Xác minh lỗi không phải là một phần của Kiểm tra hồi quy | - Xác minh lỗi là một phần của kiểm tra lại |
| - Dựa trên tính sẵn có tài nguyên của dự án, Kiểm tra hồi quy có thể được tiến hành song song với Kiểm tra lại | - Ưu tiên kiểm tra lại cao hơn kiểm tra hồi quy, do đó, nó được thực hiện trước khi kiểm tra hồi quy |
| - Có thể kiểm thử automation để kiểm tra hồi quy, Kiểm tra thủ công có thể tốn kém và mất thời gian | - Bạn không thể kiểm thử automation các trường hợp kiểm tra để kiểm tra lại |
| - Kiểm tra hồi quy được gọi là kiểm tra chung | - Kiểm tra lại là một thử nghiệm theo kế hoạch |
| - Kiểm tra hồi quy được thực hiện cho các trường hợp kiểm tra đã PASSED | - Việc kiểm tra lại chỉ được thực hiện đối với các trường hợp thử nghiệm FAILED |
| - Kiểm tra hồi quy kiểm tra các ảnh hưởng không mong muốn | - Kiểm tra lại đảm bảo rằng lỗi ban đầu đã được dev fixed thành công |
| - Kiểm tra hồi quy chỉ được thực hiện khi có bất kỳ sửa đổi hoặc thay đổi nào là bắt buộc trong một dự án hiện có | - Kiểm tra lại thực hiện một lỗi với cùng một dữ liệu và cùng một môi trường với các đầu vào khác nhau với một kịch bản mới |
5. Kết luận
Lỗi được ghi lại bởi tester trong khi thử nghiệm ứng dụng và được fix bởi dev trong dự án.
- Trong Kiểm tra lại, QA/Tester sẽ kiểm tra lỗi tương tự cho dù đã sửa hay không sử dụng các bước đã được đề cập trong lỗi.
- Trong kiểm tra hồi quy, QA/Tester sẽ kiểm tra lỗi được fix tương tự hoặc chức năng mới được thực hiện mà không bị ảnh hưởng đến phần không thay đổi khác của ứng dụng, không phá vỡ chức năng hoạt động trước đó cũng như không sinh ra lỗi.
6. Tài liệu tham khảo
https://www.guru99.com/re-testing-vs-regression-testing.html https://www.testingdocs.com/regression-testing-vs-re-testing
