Nội dung bài học
Anh Tester sẽ liệt kê một số điểm khác biệt đáng chú ý giữa Regression testing và Retesting để loại bỏ sự nhầm lẫn này.
1. Retesting là gì?
Retesting là một quy trình kiểm tra lại các testcase failed trong lần cuối cùng thực hiện test. Nói chung, tester tìm bug đó trong quá trình kiểm thử và assign lại cho Dev fix. Sau khi Dev fix xong thì đẩy lại cho Tester kiểm tra lại. Quá trình liên tục này được gọi là Re-testing.
Retesting có nghĩa là kiểm tra lại. Khi bạn lặp lại một kiểm thử thì đó chính là retest. Bạn có thể test lại chức năng của phiên bản hiện tại, một bug đã fix, chức năng của phiên bản trước đó hay một test case bạn vừa thực hiện, vv…
Nếu bạn vẫn suy nghĩ tại sao lại phải làm vậy thì hãy theo dõi một vài lý do sau:
-
Hôm qua bạn thực hiện một kiểm thử và gặp phải một khiếm khuyết. Bạn muốn xác nhận các bước và tái hiện lại khiếm khuyết. Vì vậy bạn phải retest.
-
Bạn chạy một kiểm thử tuy nhiên vì một lý do nào đó mà bạn không để ý đến nó (Có thể bạn có điện thoại hoặc bạn đang nói chuyện với một người bạn, vv…). Bạn muốn kiểm tra lại một lần nữa, vì vậy bạn phải retest.
Chắc chắn bạn đã nắm được điều này.
Retesting là khi bạn lặp lại một kiểm thử cho bầt kỳ một lý do nào. Đây là một trong những điều kiện gần đúng với định nghĩa của nó.
2. Regression testing là gì?
Regression testing (kiểm thử hồi quy) là một loại kiểm thử phần mềm được thực hiện để kiểm tra các tính năng và chức năng hiện tại có bị ảnh hưởng khi thay đổi một đoạn code hay không.Kỹ sư đảm bảo chất lượng (QA) thực hiện các bài tập này để xem liệu các sửa đổi để phá vỡ mã hoặc cản trở cách thức hoạt động của ứng dụng hoặc cách nó sử dụng tài nguyên.
Regression testing là một dạng của Retesting. Những đặc trưng của "Why" và "When" là những điểm khác biệt giữa test hồi quy so với retest.
When: khi nào chúng ta thực hiện retest? Khi phần mềm trải qua một sự thay đổi.
Why: tại sao chúng ta phải retest? Để đảm bảo việc thêm mới và thay đổi các tính năng không làm ảnh hưởng đến sự ổn định của các chức năng cũ. Regression là phần thực hiện chung và được yêu cầu khi:
- Một phiên bản mới trở nên có hiệu lực. (Hồi quy tất cả hoặc ít nhất một tính năng quan trọng của phiên bản cũ).
- Bug đã được fix.
Note: Kiểm thử hồi quy toàn bộ ( Exhaustive regression testing) là không thể thực hiện mặc dù rất mong muốn.
Đó là lý do tại sao phải phân tích Regression trước khi bạn nhảy luôn vào thực hiện kiểm thử. Đây là bước quan trọng liên quan đến việc quyết định cần phải thực hiện bao nhiêu Regression cho một ứng dụng.
Thực hiện kiểm thử hồi quy phụ thuộc vào những mức độ nào?
- Tính chất của sự thay đổi
- Mối quan hệ/tác động của sự thay đổi lên các tính năng và hệ thống hiện tại.
- Thời gian có hiệu lực và nguồn lực.
Tester làm thế nào để xác định được mức độ của Regression?
- Dựa vào kinh nghiệm và sự hiểu biết với ứng dụng.
- Việc thảo luận với các deverloper.
- Những nơi mà sự thay đổi được thực hiện. Ví dụ: Nếu sự thay đổi được thực hiện trên trang chủ, thì cần phải quan tâm nhiều hơn so với những trang có lượt truy cập ít hơn.
Tùy thuộc vào các nhân tố khi hoạt động, một tập hợp kiểm thử có thể thực hiện theo một trong những follow sau:
-
Unit Regression
-
Partial Regression
-
Full Regression
Unit regression nghĩa là bạn chỉ cần thực hiện retest đối với sự thay đổi ở module hoặc vùng nào đó của ứng dụng.
Partial regression nghĩa là bạn sẽ thực hiện retest đối với sự thay đổi ở các module kèm theo những tương tác với nó.
Full regression là bạn sẽ phải kiểm tra lại toàn bộ ứng dụng, không phụ thuộc vào vị trí của sự thay đổi.
Điều này dựa trên tình hình (thời gian và nguồn lực sẵn có), mức độ nghiêm trọng của sự thay đổi (mức độ ảnh hưởng của nó), đầu vào của deverlopver, vv... Sẽ hiệu quả hơn khi bạn lựa chọn đúng một bộ kiểm thử so với việc kiểm thử toàn bộ.
Những quan niệm sai lầm về Regression Testing
Có rất nhiều quan niệm sai lầm về Regression Testing:
#1) Regression luôn luôn được thực hiện một cách tự động: Không, Regression cũng được thực hiện bằng cách thủ công.
Lưu ý rằng Regression là một ứng viên hoàn hảo cho kiểm thử tự động. Mức độ của sự lặp đi lặp lại gây tốn thời gian và có thể dẫn đến sự nhàm chán. Ngoài ra những validation quan trọng có thể bị bỏ sót. Kiểm thử tự động là một sự lựa chọn đáng tin cậy, nhanh chóng và hiệu quả.
#2) Regression là không bao giờ hoàn thành: Đúng, nhưng không hoàn toàn. Theo những gì tôi nghĩ thì kiểm thử hồi quy toàn bộ có thể là không thể. Nhưng kiểm thử hồi quy toàn bộ có thể không quá cần thiết.
Giả sử rằng bạn đã thay đổi một lỗi chính tả trên trang chủ. Việc sửa chữa này là rất nhỏ. Nó cũng được độc lập với các khu vực khác của ứng dụng. Vậy, một quá trình retest đơn giản của tính năng này sẽ làm gì. Không cần thực hiện hồi quy tính năng cũ xung quanh trang chủ.
#3) Nó là không cần thiết khi bạn có nhiều công việc chồng chéo nhau trong cùng một khoảng thời gian: Không đúng. Nếu không thực hiện hồi quy sẽ dấn đến việc mất độ tin cậy trong sản phẩm. Bạn sẽ không bao giờ biết được những kỳ vọng đến từ những kịch bản khác nhau của end user.
#4) Nó chính là việc chạy hết từng test case riêng lẻ của bản release trước đó: Không nên chạy lại toàn bộ test case của bản trước đó. Cần lựa chọn đúng những test case phù hợp để test lại. Chiến lược chọn các test case là mấu chốt của vấn đề. Hiểu được sự thay đổi và lựa chọn những test case phù hợp.
Đúng vậy, đó chính là chi tiết của Retesting và Regression Test.
Bây giờ, hãy thực hiện so sánh
3. Sự giống nhau giữa Retesting và Regression Testing
-
Nền tảng của cả hai đều là sự lặp lại.
-
Đều là kỹ thuật Validation và Black box testing.
-
Retest và Regression đều thực hiện được bằng kiểm thử tự động hoặc kiểm thử thủ công.
-
“Người ta phải xác nhận hoặc xóa bỏ nghi ngờ của mình, và biến nó thành sự chắc chắn của ĐÚNG hoặc SAI" (One must verify or expel his doubts, and convert them into the certainty of YES or NO) theo danh ngôn của Thomas Carlyle. Cả Retesting và Regression Test đều thực hiện điều này.
4. Sự khác nhau giữa Retesting và Regression testing
| Re-testing | Regression testing |
|---|---|
| Re-testing được thực hiện để xác nhận lại các trường hợp failed trong lần cuối cùng thực hiện có pass sau khi Dev fix hay không | Kiểm thử hồi quy được thực hiện để xác nhận xem những chương trình hoặc code thay đổi có ảnh hưởng đến tính năng cũ hay không |
| Re-testing được thực hiện dựa trên cơ sở các lỗi đã được fix | Mục đích của kiểm thử hồi quy là khi 1 phần code thay đổi nhưng không được sinh ra bất kì ảnh hưởng nào khác đến các chức năng đã có |
| Xác minh lỗi là một phần của re-testing | Xác minh lỗi không phải là một phần của regression testing |
| Mức độ ưu tiên của re-testing cao hơn kiểm thử hồi quy, vì vậy nó được thực hiện trước khi kiểm thử hồi quy | Dựa vào dự án và nguồn nhân lực, kiểm thử hồi quy có thể được thực hiện song song với kiểm thử chấp nhận |
| Không thể tự động hóa các test case | Có thể sử dụng auto test để kiểm thử hồi quy do kiểm thử thủ công tốn thời gian và nhân lực |
| Kiểm thử chấp nhận là kiểm thử theo kế hoạch | Kiểm thử hồi quy được coi là kiểm thử chung |
| Test lại các case failed | Được thực hiện cho các case passed |
| Kiểm tra lại để đảm bảo rằng các lỗi đã được fix | Check các ảnh hưởng không mong đợi |
| Re-testing thực thi 1 lỗi với cùng 1 dữ liệu, cùng 1 môi trường nhưng đầu vào khác nhau là 1 bản built mới | Kiểm thử hồi quy được thực hiện khi có bất kì chỉnh sửa hoặc thay đổi nào đó. Nó trở thành bắt buộc trong dự án |
Zalo
Anh Tester
facebook.com/anhtester
Đường dẫu khó chân vẫn cần bước đi
Đời dẫu khổ tâm vẫn cần nghĩ thấu