👌 Rất nhiều bạn vẫn không phân biệt rõ sự khác nhau giữa confirmation và regression testing, trong bài này mình sẽ chia sẻ thông tin cơ bản và giúp bạn phân biệt được những điểm giống và khác nhau giữa confirmation và regression testing.
Trước tiên mình sẽ giới thiệu về confirmation testing, sau đó là regression testing và phân biệt sự khác nhau giữa hai loại kiểm thử này.
Confirmation testing – Kiểm thử xác nhận
Confirmation Testing (kiểm thử xác nhận) hay còn gọi là re-testing (kiểm thử lại) được thực hiện sau khi một màn hình chức năng hay một API đã được “fix bug” (sửa lỗi) hay thay đổi yêu cầu (change request)nhằm đảm bảo lỗi đó đã được sửa/thay đổi thành công và hoạt động như mong đợi.
Phạm vi thực hiện confirmation testing thường cố định và tập trung vào đối tượng cần được kiểm thử. Khi thực hiện confirmation testing, tester sẽ thao tác tương tự như quy trình kiểm thử trước đó vào thời điểm tìm ra lỗi này.
Xem thêm regression testing
Thời điểm thực hiện confirmation testing?
- Thực hiện trước Regression Testing.
- Khi dev xác nhận bug post trước đó đã được fix.
- Khi khách hàng yêu cầu Retest: Là yêu cầu trực tiếp từ khách hàng nhằm đảm bảo chất lượng sản phẩm.
- Khi bug bị Dev từ chối: Trong trường hợp này, Tester sẽ reproduce lại bug bằng cách Retest để kiểm tra tính hợp lệ của bug đã post.
Xem thêm edge case
Một số ưu và nhược điểm của confirmation testing
Một số ưu điểm của confirmation testing là giúp bạn đảm bảo chất lượng của hệ thống nói chung và các chức năng của sản phẩm nói riêng khi đã phát hành cho người dùng trên môi trường thực tế. Giúp mình xác nhận rằng (các) lỗi đã phát hiện trước đó đã được khắc phục thành công. Thường không cần phải tốn nhiều thời gian chuẩn bị môi trường kiểm thử do đã thực hiện trước đó rồi (khi bạn kiểm thử và phát hiện ra lỗi). Và giúp nhóm phát triển phần mềm và người dùng có trải nghiệm tốt hơn khi lỗi trong hệ thống phần mềm ngày càng ít (do đã được sửa hết rồi 😇).
Tuy nhiên, trong quá trình thực hiện confirmation testing cũng có một số nhược điểm. Thứ nhất là tốn nhiều thời gian thực hiện kiểm thử do phần lớn những trường hợp này là manual (thủ công). Một số trường hợp quan trọng sẽ được chọn để tự động hoá, đa phần các trường hợp khác sẽ không được tự động hoá, do chúng ta chỉ thực hiện một vài lần. Thứ hai, trong trường hợp một lỗi được sửa vào thời gian cách xa lúc kiểm thử lần đầu (khi phát hiện lỗi) thì chúng ta phải “xây dựng” môi trường cũ để có thể tái hiện lỗi trên đó và kiểm thử với phần source code (mã nguồn) mới để chắc chắn rằng chúng ta đã sửa đúng thứ cần sửa.
Các bước thực hiện confirmation testing hiệu quả
Nếu bạn chỉ thực hiện kiểm thử xác nhận trên bản code mới, bạn sẽ chỉ xác nhận được rằng lỗi “không tái hiện được” trên môi trường này. Bạn có tự tin và chắc rằng lỗi đã được sửa, loại bỏ thành công?
Để tăng độ tin cậy rằng lỗi đã được sửa thành công, tuy tốn thời gian hơn cách tiếp cận trên, bạn nên thực hiện các bước sau:
- Tái hiện được lỗi trên môi trường hiện tại (ví dụ trên môi trường UAT)
- Deploy bản build mới lên môi trường nào đó (thường là DEV rồi đến UAT)
- Thực hiện lại “các bước tái hiện lỗi” (được ghi trong “con bug”)
- Xác nhận lỗi KHÔNG còn xảy ra nữa, nghĩa là đã được sửa xong
- Cập nhật trạng thái bug theo kết quả kiểm thử (ví dụ Verified hay Reopened)
- Cập nhật test case liên quan (nếu có)
Regression testing – Kiểm thử hồi quy
Regression Testing thường được thực hiện sau khi hệ thống phần mềm (system) hay một mô-đun (module) nào đó vừa có sự thay đổi, ví dụ như thay đổi yêu cầu hoặc sửa lỗi (fix bug) hoặc thậm chí hệ thống của máy chủ (server) hoặc điện thoại nâng cấp hệ điều hành hay bản vá lỗi, nhằm đảm bảo mọi chức năng hiện có của phần mềm vẫn hoạt động như mong đợi.
Phạm vi thực hiện regression test phụ thuộc vào nhiều yếu tố như độ lớn của hệ thống đang được kiểm thử, độ lớn (size) và mức độ rủi ro (cao/thấp) của lần thay đổi vừa được thực hiện.
Nguồn: qamadness
Thời điểm thực hiện regression testing
Thường thì kiểm thử hồi quy sẽ được thực hiện ngay sau kiểm thử xác nhận (confirmation testing). Tuỳ vào thời gian mình có mà phạm vi kiểm thử hồi quy sẽ “rộng hay hẹp.” Ít nhất phải kiểm thử các chức năng xung quanh nằm cùng màn hình với chức năng (ví dụ 1 nút nào đó) vừa có sự thay đổi.
Ngoài việc regression testing sau khi sửa lỗi, một số trường hợp khác cũng thường cần thực hiện regression testing là:
- Sau khi thay đổi một yêu cầu hiện có
- Nâng cấp hệ điều hành của server, thiết bị di động
- Cập nhật bản vá lỗi của thư viện nào đó trong hệ thống
Một số ưu và nhược điểm của regression testing
Việc thực hiện kiểm thử hồi quy đúng và hợp lý sẽ giúp chúng ta bảo đảm sự ổn định của hệ thống dù thay đổi mã nguồn thường xuyên. Giúp nhóm mình hoàn toàn tự tin release (phát hành) một bản mã nguồn mới cho khách hàng khi phát hiện kịp thời những lỗi mới phát sinh do quá trình triển khai thực hiện các thay đổi yêu cầu hay thêm yêu cầu mới vào hệ thống.
Tuy nhiên, với một số thay đổi nhỏ nhưng chúng ta cần phải kiểm thử lại toàn bộ các chức năng hiện hữu trong hệ thống để bảo đảm chúng vẫn đang hoạt động như cũ, ví dụ như nâng cấp một chức năng cốt lõi (core) trong hệ thống mà nhiều chức năng khác đều có sử dụng nó. Nếu không áp dụng kiểm thử tự động thì điều này rất mất thời gian, đôi khi sửa code trong 1 tiếng nhưng cần 1 tuần để có thể “regression testing lại toàn bộ hệ thống.” Để tránh nhược điểm này, chúng ta nên nghĩ đến việc áp dụng kiểm thử tự động ở nhiều mức độ khác nhau từ unit testing (kiểm thử đơn vị) đến system testing (kiểm thử mức hệ thống).
Các bước thực hiện regression testing hiệu quả
Ba bước cơ bản để thực hiện kiểm thử hồi quy hiệu quả:
- Xác định phạm vi kiểm thử
- Cập nhật test case liên quan
- Kiểm thử và đánh giá lại phạm vi trong lúc kiểm thử
Để kiểm thử hồi quy hiệu quả, nghĩa là kiểm thử đúng khu vực có khả năng bị ảnh hưởng và tiết kiệm thời gian cũng như nhân lực thì chúng ta cần xác định đúng phạm vi kiểm thử.
Để xác định đúng và hiệu quả phạm vi cần kiểm thử, tester nên thảo luận với lập trình viên để khoanh vùng các phần có thay đổi code, cùng với kiến thức của tester về mối liên quan giữa các chức năng trong cùng hệ thống như:
- Kiểm thử trong phạm vi cùng màn hình/API có thay đổi
- Kiểm thử trong phạm vi cùng mô-đun (module)
- Kiểm thử cả hệ thống có thực hiện thay đổi
- Kiểm thử cả các chức năng liên quan ở các hệ thống khác
Xem xét tập test case cần thực hiện, có thể cần bổ sung thêm test case mới hoặc thay đổi test case hiện có. Nên cập nhật test case trước khi tiến hành kiểm thử hồi quy. Nếu có kiểm thử tự động thì có thể phải cập nhật test case hiện có cho tương ứng với UI và chức năng mới.
Trong quá trình thực hiện việc kiểm thử hồi quy, dựa vào kết quả kiểm thử hiện tại, bạn cũng cần đánh giá lại phạm vi ảnh hưởng (đã xác định) để việc kiểm thử hiệu quả hơn. Ví dụ như cần mở rộng phạm vi hoặc thu hẹp, hoặc kết thúc kiểm thử sớm hơn dự định.
Một số phương pháp tiếp cận thực hiện regression testing
Như đã đề cập ở trên, không phải lúc nào chúng ta cũng thực hiện test lại toàn bộ hệ thống. Dưới đây là một số phương pháp tiếp cận kiểm thử hồi quy hiệu quả tùy trường hợp.
- Complete regression testing: Kiểm thử lại tất cả mọi trường hợp. Cách này tốn nhiều thời gian, đặc biệt khi thực hiện thủ công, nhưng giúp tăng độ tin cậy rằng mọi thứ vẫn hoạt động như cũ. Nên chọn cách này khi có thay đổi lớn hoặc thay đổi những thành phần cốt lõi của hệ thống. Nếu bạn có một bộ test case tự động bao phủ hầu hết các chức năng chính, thì có thể lên lịch chạy ít nhất 1 lần/tuần vào ngày cuối tuần.
- Selective regression testing: Chỉ kiểm thử những khu vực chính của hệ thống thông qua một danh sách các test case đã được chọn sẵn. Khi có bất kỳ thay đổi nào, chúng ta cũng cần thực hiện lại nhóm test case này để bảo đảm mọi chức năng chính vẫn đang hoạt động ổn.
- Progressive regression testing: Cách tiếp cận này thường được áp dụng khi có sự thay đổi lớn trong yêu cầu, nghĩa là bộ test case cũ không còn phù hợp với yêu cầu mới này. Khi đó, chúng ta cần viết test case mới trước khi thực hiện kiểm thử hồi quy này.
Sự khác nhau giữa confirmation testing và regression testing
Để dễ so sánh, chúng ta cùng xem qua ví dụ này. Khi đang kiểm thử trên hệ thống, một tester phát hiện và báo lỗi (hay gọi là report bug hay log bug) sau:
- Mã lỗi: USR-06
- Mô tả lỗi: Người dùng thay đổi mật khẩu thành công khi sử dụng lại mật khẩu hiện tại
Sau khi lập trình viên đã sửa lỗi này, không cho phép người dùng sử dụng mật khẩu hiện tại để làm “mật khẩu mới” khi thay đổi mật khẩu. Việc đầu tiên tester sẽ làm là thực hiện lại các bước thay đổi mật khẩu trên bản build mới để xem có thể thay đổi mật khẩu với mật khẩu hiện tại được không. Mong muốn của tester (và mọi người trong nhóm) là không cho phép điều này. Nghĩa là tester (trong vai người dùng) sẽ phải sử dụng một mật khẩu mới đúng nghĩa, khác mật khẩu hiện tại đang sử dụng. Đây là confirmation testing – kiểm thử xác nhận.
Sau đó, tester cần thảo luận sơ với lập trình viên trên để đánh giá các khu vực (chức năng) có thể bị ảnh hưởng bởi thay đổi trên. Sau đó tiến hành kiểm tra lại các chức năng có liên quan ví dụ như Tạo tài khoản mới thành công với mật khẩu hợp lệ (giống với một tài khoản đang có trong hệ thống). Kiểm thử lại chức năng đăng nhập để đảm bảo đăng nhập thành công với mật khẩu mới (sau khi đã thay đổi thành công.). Đây là regression testing – kiểm thử hồi quy.
Khía cạnh | Confirmation Testing | Regression Testing |
Khái niệm | Kiểm thử xác nhận tương đương với việc thực hiện lại việc kiểm thử một hoặc nhiều test case (trường hợp kiểm thử) sau khi một lỗi phần mềm đã được sửa, nhằm đảm bảo lỗi đã được sửa thành công. | Kiểm thử hồi quy là quá trình kiểm thử để bảo đảm rằng các thay đổi vừa được thực hiện (ví dụ sửa lỗi phần mềm) không ảnh hưởng đến các chức năng hiện có của phần mềm đó, và không phát sinh lỗi mới. |
Thời điểm thực hiện | Sau khi lỗi đã được sửa và thường được thực hiện trước regression testing | Nên thực hiện sau khi phần mềm có sự thay đổi (ví dụ sửa lỗi hay thay đổi chức năng). Thường sẽ được thực hiện sau khi đã hoàn tất confirmation testing. |
Phương pháp tiếp cận | Chạy lại bộ test case cũ, hoặc chỉ một test case khi chỉ cần kiểm tra lại 1 lỗi nào đó (trên thực tế mọi người hay gọi là “verify bug”) | Tùy trường hợp sẽ tái sử dụng bộ test đã được chọn lựa trước đó dành riêng cho việc regression. Chúng là những test case bao phủ các chức năng chính trong hệ thống. Hoặc cần bổ sung thêm test case mới trước khi thực hiện regression testing. |
Đối tượng | Các chức năng được thực hiện thay đổi, sửa chữa, hoặc thêm mới, và bug vừa được fix,.. | Các chức năng khác trong hệ thống mà có liên quan đến chức năng được thực hiện thay đổi. |
Mục đích | Đảm bảo lỗi đã được sửa thành công và chức năng bị lỗi đã hoạt động theo mong đợi | Đảm bảo các chức năng liên quan (có thể bị ảnh hưởng bởi sự thay đổi) trong phần mềm không bị ảnh hưởng sau khi thực hiện thay đổi đó. Nói cách khác, bảo đảm không phát sinh lỗi mới sau khi thực hiện việc thay đổi. |
Cám ơn anh Sơn và chị An đã xem và góp ý cho bài tiểu luận cuối khoá của em, khoá FK54 lớp Fresher Tester).
Cám ơn anh chị và mọi người đã xem hết bài viết của em.
Trân Lê