Lầm tưởng thường gặp về test tự động

Bài đăng này đã không được cập nhật trong 2 năm

Không khó để thấy được lợi ích của việc test tự động trong quá trình phát triển của sản phẩm - giúp thời gian release nhanh hơn, mở rộng phạm vi kiểm tra, thực hiện kiểm tra thường xuyên, phản hồi nhanh hơn cho nhóm phát triển, tuy nhiên nhiều tổ chức chưa thực hiện hay đầu tư vào test tự động. Rất khó để hiểu được những hạn chế của test tự động. Trong bài này, chúng ta sẽ khảo sát một số những lầm tưởng phổ biến nhất về test tự động và chúng tác động tới sự thành công như thế nào.

1. Test tự động tốt hơn test manual

Đề cập trong bài đăng trên blog của Michael Bolton "Testing vs. Checking", test tự động không phải là test thực. Đó chỉ là “checking the fact” (kiểm tra sự thật). Khi chúng ta hiểu về hệ thống, chúng ta có thể thực thi sự hiểu biết đó dưới dạng check bằng cách chạy script tự động. Tuy nhiên, testing là một cuộc điều tra nhằm mục đích có được thông tin mới về hệ thống bằng cách test khám phá. Testing đòi hỏi con người phải đưa ra quyết định về tính hữu dụng của hệ thống. Chúng ta có thể phát hiện những dị thường không lường trước được. Chúng ta phải công nhận với nhau rằng phương pháp nào cũng có mặt tốt mặt chưa tốt, nhưng cả hai phương pháp đều cần để đảm bảo về chất lượng của ứng dụng.

2. Có thể kiểm thử tự động 100%

Cũng giống như manual testing, thực tế không thể đảm bảo kiểm thử 100%. Chúng ta có thể tăng phạm vi kiểm thử bằng cách chạy script tự động với nhiều dữ liệu hơn, nhiều loại cấu hình hơn (về hệ điều hành, trình duyệt,...) nhưng đạt được 100% vẫn là một mục tiêu không hề thực tế. Khi nói đến test tự động, có nhiều bài kiểm tra không có nghĩa là chất lượng tốt hơn, cho phép tự tin hơn về chất lượng. Tất cả phụ thuộc vào việc thiết kế script tốt như thế nào. Thay vì nhắm đến phạm vi test đầy đủ, hãy tập trung vào các vùng quan trọng nhất của chức năng.

3. ROI (Return on Investment - Hồi vốn) nhanh

Khi thực hiện test tự động, cần thực hiện nhiều hoạt động khác thay vì chỉ viết test case (ví dụ chọn framework phù hợp để test). Thông thường, framework cần hỗ trợ các hoạt động một cách hữu hiệu nhất, chẳng hạn như cung cấp một số script sẵn, export báo cáo, ... Phát triển framework cũng là một dự án. Nó đòi hỏi dev lành nghề và tốn nhiều thời gian để xây dựng. Ngay cả khi một framework có đầy đủ chức năng được đưa ra, tạo script tự động ban đầu cũng mất nhiều thời gian hơn thực hiện cùng một bài test bằng tay. Do đó, khi cần có phản hồi nhanh về tính năng mới vừa được phát triển, việc kiểm tra bằng tay thường nhanh hơn test tự động. Tuy nhiên, ROI trong thời gian dài sẽ được hồi lại khi chúng ta cần phải thực hiện các test case tương tự trong khoảng thời gian đều đặn.

4. Tỷ lệ phát hiện lỗi cao hơn thông qua kiểm tra tự động

Mặc dù nhiều cách test tự động có khả năng thực hiện các hoạt động phức tạp nhưng không thể so với trí thông minh của con người. Con người có thể phát hiện những bất thường không mong muốn trong ứng dụng khi test khám phá nhiều hơn là chạy một tập test script. Trớ trêu thay, nhiều người mong đợi automation testing tìm ra nhiều lỗi hơn vì họ nghĩ rằng kiểm thử tự động làm tăng phạm vi kiểm tra. Automation test rất tốt trong việc thực hiện test hồi quy- sau khi đã thêm một tính năng mới vào hệ thống hiện có, chúng ta cần phải đảm bảo rằng chúng không phá vỡ chức năng hiện tại và chúng ta cần thông tin đó càng nhanh càng tốt. Trong hầu hết các trường hợp, bug có xu hướng ít xảy ra ở các chức năng cũ hơn so với chức năng mới đang được phát triển.

Một điểm cần ghi nhớ là test tự động chỉ kiểm tra những gì chúng đã được lập trình ra. Các kịch bản có tốt hay không hoàn toàn phụ thuộc vào người viết kịch bản hiểu như nào về hệ thống. Script có thể pass nhưng những sai sót lớn có thể không được chú ý làm sai lệch về chất lượng của sản phẩm. Về bản chất, testing có thể chứng minh được có bug chứ không thể chứng minh được hệ thống không có bug.

5. Yêu cầu về giao diện thường xuyên thay đổi

Với test manual, chúng ta nhận thấy những gì người dùng trải nghiệm khi tương tác với ứng dụng. Với test automation, chúng ta có thể thử nghiệm các kết thúc đầu cuối và tích hợp bên thứ ba khi chúng ta không thể kiểm tra theo cách khác. Chúng ta cũng có thể cung cấp script cho khách hàng và người dùng cuối để họ có thể tự đánh giá được phạm vi kiểm tra.

Tuy nhiên, giao diện người dùng luôn thay đổi để nâng cao thiết kế trực quan và khả năng sử dụng và test tự động sẽ không thể giữ nguyên do thay đổi giao diện người dùng mà không thay đổi chức năng.

Kiểm tra tự động trên giao diện người dùng cũng chậm hơn rất nhiều so với ở mức unit hoặc lớp API và do đó, phản hồi cho nhóm phát triển cũng chậm hơn. Có thể mất vài giờ để phát hiện một lỗi được phát hiện và báo cáo lại cho các nhà phát triển. Và như vậy, thời gian để tìm hiểu nguyên nhân gây lỗi rồi fix cũng sẽ tốn thời gian hơn.

Hiểu được ngữ cảnh cũng như khi nào dùng test tự động là rất quan trọng. Test tự động nên là một phần của hoạt động phát triển, vì vậy dev chịu trách nhiệm viết unit test, tester thì viết script kiểm tra việc thực thi và duy trì các bài kiểm tra chấp nhận tại API và / hoặc UI.

6. Mất lòng tin và tin cậy vào test tự động

Điều cuối cùng không phải là một lầm tưởng về test tự động, nhưng là một tác dụng phụ khi thực hiện test tự động sai. Bạn dành nhiều giờ để viết script hoàn hảo, sử dụng các công cụ tốt nhất nhưng nếu việc kiểm tra tự động không giúp ích cho nhóm thì cũng là vô giá trị.

Nếu nhóm thực hiện test tự động không đúng họ hoặc là buông xuôi trong sự sợ hãi không rõ hoặc phải nhân đôi nỗ lực kiểm tra hồi quy. Nếu kiểm tra tự động chậm, cho kết quả không liên tục thì nó có thể gây nhầm lẫn cho nhóm hơn là cung cấp tính an toàn và tăng cường sự tự tin.

Đừng ngại loại bỏ kiểm tra tự động khi thường thất bại hoặc cho kết quả không nhất quán. Thay vào đó, chúng ta hướng đến một bộ bài kiểm tra sạch, đáng tin cậy có thể đưa ra các chỉ dẫn chính xác về tình trạng của ứng dụng.

Kết luận

Test Automation là sự đầu tư dài hạn. Cần phải có thời gian và chuyên môn trong việc phát triển và duy trì test script. Test tự động không phải nỗ lực một lần là đủ, bạn cần giám sát và cập nhật liên tục.

Thay vì nhắm đến việc thay thế manual QA hoặc mong muốn kiểm tra tự động để tìm ra nhiều lỗi, chúng ta nên chấp nhận những lợi ích mà nó mang lại cho nhóm, chẳng hạn như giảm thời gian test khám phá, có thể tái sử dụng script lâu dài.