Bài viết được sự cho phép của vntesters.com
Kiểm thử qui hồi – Regression Testing
Kiểm thử qui hồi, hiểu một cách đơn giản, là phương thức kiểm thử để xem ứng dụng ở phiên bản mới có làm thay đổi hoặc có ảnh hưởng gì đến các chức năng đã có sẵn của ứng dụng hay không. Các lỗi (bug) từng xảy có còn lặp lại hay không. Tuy nhiên, vấn đê hấp dẫn chúng ta cần tìm hiểu ở đây là vì sao chúng ta gọi cách kiểm thử này là “Regression Testing”?
Theo cách nhìn của mình, kiểm thử qui hồi được đặt tên như vậy là vì, khi chúng ta phát hiện một vấn đề của phiên bản mới, chúng ta phải quay về (regress) lại phiên bản trước đó.
Mô hình phát triển phần mềm Agile
Agile ngày càng thay thế mô hình truyền thống Thác Nước (Waterfall) là dựa vào ý tưởng tăng tốc độ quy trình phát triển phần mềm, rút ngắn thời gian đưa sản phẩm đến tay khách hàng, tăng cường lấy phản hồi và chỉnh sửa ứng dụng nhầm đáp ứng nhanh nhất sự thay đổi yêu cầu của khách hàng.
Kiểm thử qui hồi trong môi trường Agile
Với đặc điểm của mô hình Thác Nước, sản phẩm đến tay của kỹ sư kiểm thử không quá liên tục, các kỹ sư kiểm thử có đủ thời gian để thiết kế kịch bản kiểm thử, tiến hành kiểm thử chức năng mới và làm cả kiểm thử qui hồi trong khi đợi các phiên bản cập nhật từ đội ngũ phát triển ứng dụng.
Với mô hình Agile thì ngược lại, tốc độ ra phiên bản mới của ứng dụng có thể tính theo tuần, thậm chí là theo ngày, giờ. Kiểm thử các chức năng mới đồng thời kiểm thử qui hồi các chức năng cũ đã tạo nên một áp lực không nhỏ lên đội ngũ kiểm thử phần mềm.
Một câu chuyện kinh điển
Khi bắt đầu dự án, một đội ngũ phát triển được thiết lập với tỉ lệ 3 dev : 1 tester. Giả thiết rằng chúng ta có 6 kỹ sư phát triển và 2 kỹ sư kiểm thử. Mô hình Agile được thiết lập với mỗi 2 tuần cho một Sprint. Mọi thứ bắt đầu.
Ở Sprint đầu tiên, chúng ta bắt đầu với những chức năng cơ bản (ví dụ khoảng 10 chức năng), kỹ sư kiểm thử bắt đầu thiết kế các kịch bản kiểm thử tiến hành kiểm thử (ví dụ khoàng 100 kịch bản). Mọi chuyện tốt đẹp. Sprint đầu tiên nhận được đánh giá tốt từ khách hàng.
Qua sprint thứ hai, kỹ sư phát triển tiếp tục làm những chức năng mới – cũng khoảng 10 chức năng, và kỹ sư kiểm thử cũng làm những việc như sprint đầu tiên – với thêm 100 kịch bản mới; cộng với 100 kịch bản cũ cần làm kiểm thử qui hồi. À được, chỉ 200 kịch bản thôi, mọi chuyện vẫn còn trong tầm kiểm soát.
Qua sprint tiếp theo, kỹ sư phát triển chỉ cần làm 8 chức năng mới và chỉnh sửa 2 chức năng cũ do nhu cầu khách hàng thay đổi so với ban đầu. Lúc này, 2 kỹ sư kiểm thử không chỉ phải thiết kế kịch bản kiểm thử cho 8 chức năng mới, mà còn phải kiểm tra và cập nhật 200 kịch bản cũ để đáp ứng yêu cầu mới của khách hàng. Cuối cùng, là thực thi toàn bộ khoảng 300 kịch bản. Bạn đã cảm thấy có gì đó “sai sai” chưa?
Qua khoảng vài sprint kế tiếp, 3 kỹ sư phát triển vẫn đáp ứng được số lượng chức năng và yêu cầu thay đổi của khách hàng, nhưng với 2 kỹ sư kiểm thử, số lược kịch bản cần tạo ra và cập nhật, chỉnh sửa càng lúc càng nhiều, số lượng kịch bản cần thực thi của sprint sau nhiều hơn sprint trước.
Một sự mệt mỏi bắt đầu lan tỏa. Sự thiếu thời gian để hoàn thành kiểm thử ứng dụng trước khi đưa đến tay khách hàng càng lúc càng hiện rõ. Nguy cơ bỏ sót lỗi (miss bug) càng lúc càng cao. Yêu cầu thêm nhân sư cho kiểm thử được đưa ra liên tục cho các cấp lãnh đạo, đi kèm với nó là việc tăng chi phí cho đội ngũ phát triển.
Quá nhiều vấn đề phát sinh, phải không?
Kiểm thử tự động
Với những vấn đề ở trên, tự động hóa là câu trả lời all-in-one (giải pháp cho tất cả) cuối cùng mà chúng ta nhận thấy. Vấn đề còn lại là, làm sao để tự động hóa việc kiểm thử một các hiệu quả?
Bài viết gốc được đăng tải tại vntesters.com
Có thể bạn quan tâm:
- 10 bước để bắt đầu áp dụng kiểm thử tự động vào dự án
- Xu Hướng Kiểm Thử Phần Mềm
- Các mức độ kiểm thử được sử dụng trong kiểm thử chức năng của một phần mềm
Xem thêm Việc làm Developer hấp dẫn trên TopDev
