Automation Testing và lí do khiến nó chưa thể thay thế hoàn toàn phương pháp kiểm thử thủ công

Automation testing (AT) ngày càng trở nên phổ biến và dễ tiếp cận hơn, nhưng Manual Testing (MT) vẫn không mất đi vai trò của mình. Chúng ta đang sống trong một thế giới mà máy móc dần chiếm hết công việc của con người, nhưng tại sao điều đó vẫn chưa vè có vẻ còn lâu mới trở thành hiện thực trong nghề QA? Cùng tìm hiểu xem nhé.

1. Automation Testing là gì?

AT là việc áp dụng các loại công cụ hỗ trợ để triển khai test trên quy mô lớn với lượng data và tốc độ không tưởng đối với cách làm việc thủ công của con người. AT bao gồm việc sử dụng những tool được viết sẵn cho các mục đích cơ bản (tool clone data, tool tấn công ddos,...) và việc Tester chủ động viết ra các đoạn script để tự động hóa việc thực thi testcase cũng như so sánh kết quả, đối chiếu và tìm ra bug. Trên quy mô lớn, AT có khả năng tìm ra đến 70-80% bug của ứng dụng trong thời gian rất ngắn. Tuy nhiên, kết quả đó chỉ có thể khả thi khi và chỉ khi Tester có thể hình dung ra tất cả các scenario có thể xảy ra trong thực tế mà không cần quá nhiều thời gian sử dụng thử ứng dụng. Ví dụ: tôi có màn hình A và theo như thiết kế thì tôi có 6 cách để truy cập được vào màn hình A. Như vậy nếu tôi viết đầy đủ testcase để truy cập vào màn hình A theo cả 6 cách này thì script của tôi có thể tìm ra đủ 80% bug khi truy cập vào màn hình A. Tuy nhiên, nếu tôi không dành đủ thời gian để mày mò sử dụng thử ứng dụng, tôi có thể sẽ không phát hiện ra rằng có một bug từ màn hình B mà khi xảy ra thì nó chuyển tiếp thẳng đến màn hình A. Đây là một bug tiềm ẩn nằm ngoài hiểu biết của tôi về thiết kế của ứng dụng, và bởi thế tôi không thể lường trước được sự tồn tại của nó. Do đó, script của tôi có lỗ hổng và tôi để lọt bug này, mà bug này có thể dẫn đến hoặc làm sai lệch nhiều bug/testcase khác. Như vậy, có thể nói AT không phải là "chén thánh" của nghề QA. AT có những điểm yếu của nó:

• AT lý tưởng có thể tìm ra 80% bug trong chỉ 20% tổng thời gian test thông thường.
• AT chủ yếu dựa phần lớn vào thiết kế và tài liệu yêu cầu hệ thống.
• AT yêu cầu Tester phải có hiểu biết sâu rộng về công nghệ cũng như có kĩ năng code cơ bản.
• AT không có khả năng hoàn thiện ứng dụng mà chỉ loại bỏ được các bug cơ bản.

2. Tại sao AT chưa thể thay thế hoàn toàn MT

Như 4 lý do nêu trên, dễ dàng hiểu được tại sao AT vẫn còn chưa phổ biến trong nghề QA

1. Dù AT có thể tìm ra 80% bug trong chỉ 20% thời gian test, nhưng 20% bug còn lại có thể mất đến 80% thời gian để tìm ra. 20% bug tồn động đó vẫn cần đến sự sáng tạo và những trùng hợp/rủi ro trong quá trình MT. Cá tính và thói quen của Testers thực ra ảnh hưởng rất nhiều đến việc tìm ra những bug tiềm ẩn kiểu này. Những Tester nghịch ngợm hoặc đặc biệt bi quan lại thường rất hay tìm ra những bug mà không ai ngờ tới, trong những flow hết sức không thực tế (bug hiếm) mà tư duy bao quát thông thường không thể dự đoán được.

2. Để tạo ra các scripts AT, Tester cần phải có hiểu biết sâu sắc về thiết kế và yêu cầu hệ thống. Như vậy, Testers phải theo dõi quá trình phát triển từ khi bắt đầu và liên tục cập nhật mọi thay đổi. Nếu Testers bỏ lỡ một vài cuộc họp thì sẽ có lỗ hổng trong hiểu biết của Testers dẫn tới sự sai lệch trong testcase. Hơn nữa, dù có sát sao với dự án đến mức nào thì Testers vẫn có thể hiểu sai lệch hoặc thiếu ý niệm về một vài thành phần chức năng nhất định của hệ thống, điều đó là không thể tránh khỏi. VIệc chỉ dựa hoàn toàn vào thiết kế và tài liệu có thể khiến cho Testers bị khuyết thiếu hiểu biết về cách thực thi thực tế của hệ thống và bởi thế không mường tượng được hết các vấn đề phát sinh.

3. AT yêu cầu Tester phải có kĩ năng code cơ bản và hiểu biết rộng về công nghệ. Tuy nhiên Tester có kĩ năng như vậy không nhiều và không phải là lao động phổ thông. Điều này dẫn tới chi phí sản xuất của ứng dụng bị đội lên cao một cách không cần thiết. Một Tester với kĩ năng tương tự như vậy có thể yêu cầu mức lương từ gấp rưỡi đến gấp 8 lần hoặc hơn nữa so với một Tester phổ thông. Nếu tôi thuê 8 Tester phổ thông để MT từ đầu đến cuối thì tôi vừa có nhiều quan điểm test hơn lại vẫn đảm bảo được chất lượng của ứng dụng. Ngoài ra, cũng có lý do mà Tester phổ thông vẫn được ưu ái. Càng ít hiểu biết về công nghệ, Tester lại càng gần với một người dùng bình thường hơn, điều đó có nghĩa là môi trường test được đảm bảo giống thực tế hơn. Trong lúc thực hiện System test với 8 Tester phổ thông thì tôi cũng đã thực hiện được một vòng Acceptance Test nho nhỏ, một công đôi việc.

4. AT có khả năng loại bỏ phần lớn những bug cơ bản, không những thế, nó cũng theo dõi và khắc phục được nhiều thói quen xấu của lập trình viên. Tuy nhiên AT chỉ dựa trên 1 cơ chế duy nhất là cơ chế so sánh. AT thực hiện các testcase và so sánh kết quả thực tế với kết quả giả định để phát hiện ra sai lệch và kết luận đó là bug. MT, mặt khác, dù cũng so sánh để xác định bug nhưng lại bao gồm một thứ mà AT không có, đó là Defect Tolerance. Defect Tolerance là một trường xét duyệt mà tại đó Tester kết luận một sự sai khác có được coi là bug hay không. Đối với AT, lệch 1 pixel trên màn hình cũng có thể tính là bug, nhưng luôn là quá khó để dev chỉnh sửa chính xác từng pixel trên màn hình, và bởi vậy, MT có thể không coi đó là bug và vì thế tiết kiệm được nhiều effort và thời gian cho dev. Ngoài ra, khi thực sự sử dụng một ứng dụng, Tester không chỉ phát hiện ra bug mà còn đưa ra những đánh giá chủ quan của mình về các yêu cầu phi chức năng như tính dễ sử dụng, tính dễ học hỏi,... để dev team cải thiện trải nghiệm người dùng tốt hơn. Những điều này AT chưa có cách nào làm được.

3. Kết luận:

AT là bước tiến đáng hoan nghênh cho nghề QA tuy nhiên nó chưa hoàn thiện và vẫn còn rất nhiều thiếu sót. AT chưa thể thay thế hoàn toàn MT và thực sự không cần thiết phải thay thế hoàn toàn MT. Sự tham gia của con người trong quá trình kiểm thử và đảm bảo chức năng là rất quan trọng. Nếu bạn vẫn mắc kẹt với việc test thủ công thì hãy thử nâng cao trình độ với một chút kĩ năng AT, tuy nhiên bạn không cần phải cảm thấy xấu hổ về việc đó. Phát triển kĩ năng và quan điểm MT cũng quan trọng như phát triển kĩ năng AT vậy và bạn hoàn toàn có thể hoàn thiện một ứng dụng vừa nhanh vừa đảm bảo chỉ với MT thôi.