Có thể thực hiện kiểm thử hồi quy (regression testing) một cách thủ công không ?

Khi nói về kiểm thử hồi quy, chúng tôi-QA thường nghĩ về kiểm thử tự động (automation testing). Điều này hoàn toàn dễ hiểu bởi vì regression test suite và test scenarios sẽ được sử dụng nhiều lần. Nhưng trong bài viết này, chúng ta thử cùng nhìn một cách mới và chi tiết hơn về kiểm thử hồi quy thủ công - manual regression testing. Không code, không scripts, không automation Cùng tìm hiểu lý do tại sao manual regression testing là một ý tưởng tuyệt vời cùng quy trình thực hiện và checklist ở cuối bài viết.

1. Tại sao kiểm thử hồi quy lại cần thiết?

Trong quá trình phát triển, triển khai một phiên bản mới của sản phẩm, việc thay đổi code có thể ảnh hưởng bất ngờ đến chức năng của các tính năng hiện có. Để giảm thiểu tối đa các rủi ro cho sản phẩm phần mềm trước khi được phát hành, kỹ sư QA phải thực hiện kiểm thử hồi quy - regression tests.

Có thể giải thích đơn giản rằng, việc thực hiện giúp kiểm tra xem hệ thống vẫn hoạt động đúng như dự định không khi mà source code có sự chỉnh sửa, cải tiến và nâng cấp. Ví dụ, một vấn đề thường gặp ở trang đăng nhập là địa chỉ đăng nhập đã thành công. Chức năng đăng nhập đang hoạt động đúng.

2. Tại sao lỗi hồi quy (Regression Bugs) xuất hiện?

Có một quote nói về kiểm thử hồi quy như sau: "When you fix one bug, you introduce several newer bugs", (Dịch: Khi sửa 1 lỗi cũ, bạn đang tạo ra thêm những lỗi mới). Chính điều này là nguyên nhân dẫn đến các lỗi hồi quy. Khi mà 2 phần code phụ thuộc nhau, bất kỳ thay đổi một trong hai có thể dẫn đến ảnh hưởng đến phần còn lại. Và thực tế chứng mình rằng, nó thường sẽ xuất hiện ở những vị trí không ngờ tới. Do đó, trước khi đưa sản phẩm ra thị trường, chúng ta phải sửa bất kỳ những sai sót hoặc lỗi hệ thống nào xuất hiện khi thay đổi code.

3. Các bước thực hiện kiểm thử hồi quy thủ công

Điều đầu tiên trược khi thực hiện test automation hay manual. Cần phải nắm được quy trình thực hiện nó một cách rõ ràng:

3.1. Xây dựng chiến lược kiểm thử hồi quy của bạn

Bước đầu tiên này sẽ giúp việc thực hiện đơn giảm hơn rất nhiều: đối với manual regression testing, bạn sẽ có biện pháp để kiểm tra lại toàn bộ hệ thống, hoặc tập trung vào các vùng bị ảnh hưởng và dự đoán được vấn đề. Đôi khi, bạn chỉ có đủ thời gian để kiểm tra một vài lỗi có tiềm năng xuất hiện (trong điều kiện nâng cấp bản phát hành nhanh chóng). Trong trường hợp, muốn kiểm tra toàn bộ app, điều này không thể hoàn thành một cách nhanh trong. Quyết định này được thực hiện dựa trên cân nhắc các ảnh hưởng về độ lớn bản cập nhật, thời gian cập nhật và tần suất kiểm tra của bạn.

3.2. Lên danh sách các tác nhân thay đổi của hệ thống

Sau khi cập nhật sản phẩm, việc lên danh sách là điều cần phải thực hiện. Điều này giúp hiểu rõ hơn về bản chất của việc cập nhật gần đây, trao đổi được với người quản lý sản phẩm. Để đảm bảo bạn không bỏ lỡ bất cứ điều gì, bạn nên trình bày ra giấy hoặc trong một báo cáo. (Directives thường xuyên biến mất ở email)

3.3. Suy nghĩ về những tính năng mà việc cải tiến có thể ảnh hưởng

Đây là bước bạn lên danh sách các tính năng mà việc thay đổi sản phẩm có thể ảnh hưởng tới vì nó nằm trong tầm kiểm soát của bạn (có thể sử dụng notebook hoặc Google doc). Bạn có thể sẽ phải xác nhận nhiều tính năng như các cài đặt tài khoản của tổ chức, thông tin người sử dụng, admin và quyền cài đặt,.. ví dụ nếu ứng dụng của bạn chuyển từ hỗ trợ xác thực hai yếu tố thành xác thực đa yếu tố

3.4. Lựa chọn các bổ sung testing components hoặc khu vực có vấn đề đã biết sẽ được sử dụng

Có xảy ra lỗi với sản phẩm không? Tồn tại các tính năng thường xuyên bị hỏng, yêu cầu các hỗ trợ không tương xứng và các bugs QA tìm thấy Có thể là những khu vực hoặc tính năng thường xuyên được sử dụng nhất

• Dễ bị ảnh hưởng khi cập nhật
• Thường xuyên bị sử dụng sai bởi users
• Dễ bị hacking Bạn sẽ cần cân nhắc một vài yếu tố kiểm tra bao gồm cả trong vòng test này để hiểu rõ hơn vùng đang gặp vấn đề. Một số những yếu tố cụ thể trong testing mobile apps như: loại thiết bị, cách thức kết nối, định vị,…

3.5. Hiểu rõ khu vực kiểm tra bằng cách chia nhỏ thành từng phần

Một vài công cụ quản lý test như TestRail hay JIRA, akaAT có thể giúp bạn chia nhỏ một danh sách lớn các chức năng đang chạy thành các trường hợp test độc lập và gợi ý các trường hợp test khác Exploratory test prompts chỉ định các đặc điểm hoặc vị trí cụ thể và dựa vào kinh nghiệm của tester thiết kế các trường hợp kiểm tra của riêng họ một cách trực quan, không giống như các trường hợp test, cung cấp cho người thử nghiệm các phương thức rõ ràng. Hai cách tiếp cận này thường được sử dụng kết hợp hoặc kiểm tra chéo nhau.

3.6. Cung cấp bằng chứng bằng báo cáo bug

Cho dù bạn đang thực hiện regression testing với một team 5 hoặc 50 tester, một thứ chắc chắn rằng: bạn cần phải nhất quán trong báo cáo các lỗi thông qua các bản bug reports. Báo cáo bug phải thể hiện được: tên chức năng, môi trường, các bước dẫn đến lỗi (có thể thêm minh chứng bằng ảnh màn hình hoặc video), mong đợi kết quả, kết quả thực tế, đánh giá mức độ quan trọng của vấn đề.

3.7. Xác nhận phạm vi testing với tài nguyên testing

Regression testing yêu cầu phải tuân theo chính xác bug reports, cho dù bạn có đang quản lý một team có 5 hay 50 thành viên. (Lặp lại bên trên: cân nhắc bỏ )

3.8. Lưu và khả năng sử dụng lại các test cases của bạn

Kiểm tra lại exploratory test prompts của bạn và các test cases ở vòng test này và quyết định xem các test này phù hợp với cách tiếp cận phương pháp regression testing của bạn như nào.

• Trường hợp test nào có thể được sử dụng lại?
• Trường hợp test nào phải viết lại trước khi được sử dụng lại?
• Trường hợp test nào không cần thiết trong kế hoạch vòng test regression tiếp theo của bạn.

Lưu, tạo mẫu hoặc copy các test case và prompts sử dụng test management tool của bạn cho vòng test tiếp theo của regression testing, nó sẽ giúp việc lên kế hoạch kiểm tra và phân công công việc một cách dễ dàng hơn. Độ lớn và phức tạp của regression testing có thể sẽ rất khó để tính được, nhưng bằng việc sử dụng quy trình này, bạn có thể giúp team và bản thân đi đúng hướng.

Tổng kết

Sự phụ thuộc nhau trong software có thể khiến một thay đổi dù rất nhỏ cũng có tác động đến các tính năng và khả năng tích hợp khác. Manual regression tessting giúp hỗ trợ việc xác định các yếu tố ảnh hưởng một cách chính xác. Để làm được điều đó, đòi hỏi bạn cũng phải biết rõ ràng, chi tiết các điều kiện tiên quyết của mọi chức năng, bao gồm cả phiên bản cũ và mới. Nhờ vậy, nó sẽ giúp bạn tiết kiệm rất rất nhiều thời gian.