Make a Different in Software Testing Basics - Phần 2

Phần 2 - Re-testing and Regression testing

Định nghĩa về Re-testing và Regression testing

  • Re-testing: được thực hiện để kiểm tra các test case (TC) đã không thành công trong lần trước đó, sau khi lỗi được phát hiện và khắc phục bởi Dev, ứng dụng nên được kiểm tra lại (re-testing) để xác nhận rằng lỗi ban đầu đó đã được gỡ bỏ thành công. Đây còn được gọi là kiểm tra xác nhận (confirmation testing).

  • Regression testing: là kiểm tra ứng dụng khi mà code đã có sự thay đổi để đảm bảo rằng code mới không ảnh hưởng đến các tính năng/ chức năng hiện tại của ứng dụng.

Sự khác nhau giữa Re-testing và Regression testing

Re-testing Regression testing
Re-testing được thực hiện để đảm bảo rằng các trường hợp kiểm thử (test case - TC) mà bị thất bại (fail) trong lần thực hiện cuối cùng cần phải thành công (pass) sau khi Dev đã khắc phục chúng. Regression testing được thực hiện để đảm bảo rằng những thay đổi như khi sửa lỗi hoặc có những cải thiện hoặc nâng cấp gần đây không nên có bất kỳ ảnh hưởng xấu nào đến các phần không thay đổi.
Re-testing được thực hiện cùng một môi trường với cùng một data nhưng khác phiên bản (trên bản sửa lỗi mới). Regression testing không được thực hiện trên các bản sửa lỗi cụ thể. Nó được lên kế hoạch từ trước cho các function cụ thể hoặc toàn bộ hệ thống.
Trong Re-testing chỉ bao gồm các TC mà bị fail trước đó, còn có thể gọi là kiểm thử cho các chức năng đã bị fail trong phiên bản trước. Trong Regression testing có thể bao gồm các TC đã pass trước đó, còn có thể nói là kiểm thử cho các chức năng đã làm việc ổn định trước đó.
Các TC cho Re-testing không được chuẩn bị trước mà chỉ thực hiện lại các TC không thành công trước đó. Các TC trong Regression testing mà được sử dụng thì có thể tập hợp từ đặc tả chức năng, yêu cầu hệ thống, hướng dẫn sử dụng hoặc các báo cáo lỗi liên quan đến các sự cố được khắc phục.
Chúng ta không thể tự động hoá các TC cụ thể trong Re-testing. Chúng ta có thể triển khai Automation testing để phục vụ cho Regression testing. Regression testing một cách thủ công có xu hướng trở nên đắt đỏ, tốn kém và tốn thời gian hơn với mỗi lần phát hành mới của một dự án lớn.
Việc xác minh lỗi đã được sửa chữa là một phần của Re-testing. Việc xác minh lỗi thì không nằm trong Regression testing.
Độ ưu tiên của Re-testing là cao hơn so với Regression testing vì vậy nó phải được thực hiện trước Regression testing. Dựa trên tình hình dự án và sự sẵn có của các nguồn lực, Regression testing có thể được thực hiện song song với Re-testing.
Mục đích của Re-testing là để đảm bảo rằng lỗi/ vấn đề ban đầu gặp phải đã được giải quyết và chức năng hoạt động như dự kiến. Mục đích của Regression testing là để tìm ra các ảnh hưởng xấu mà chúng ta không mong đợi.

Kết luận

Các lỗi/ vấn đề đã được tìm thấy bởi tester trong khi thực hiện kiểm thử ứng dụng. Chúng đã được khắc phục bởi Dev và đưa ra phiên bản mới.

  • Trong Re-testing, chúng ta sẽ kiểm tra lại để xem hết bị lỗi/ vấn đề mà mình đã gặp chưa? Nếu đã được sửa xong thì mình kết thúc ở đây. Ngược lại, nếu vẫn còn lỗi thì mở lại vấn đề với đầy đủ thông tin để Dev sửa lại.

  • Trong Regression testing, vấn đề là mình lo lắng sau khi Dev đã sửa lỗi đó xong nhưng trong quá trình Dev làm việc thì có thể làm phát sinh ra lỗi ở chỗ nào đó trong code dẫn đến việc sinh ra lỗi ở một vài chức năng nào đó (có thể có liên quan đến chức năng đang được sửa lỗi). Chúng ta thực hiện test lại để xem sự thay đổi khi khắc phục lỗi trên có gây ra những hậu quả không mong muốn hay không? Nếu có thì cần phải loại bỏ chúng.

Re-testing và Regression testing có các mục tiêu và độ ưu tiên khác nhau, nhưng chúng cũng quan trọng đối với sự thành công của dự án.

Những phần trước cùng chủ đề "Make a Different in Software Testing Basics":


All Rights Reserved