8 lý do tại sao kiểm thử thủ công vẫn cần thiết

Có nhiều cách tiếp cận kiểm thử phần mềm khác nhau, nhưng nhìn chung, chúng có thể được chia thành kiểm thử thủ công và kiểm thử tự động. Chúng tôi đã viết khá nhiều bài về kiểm thử tự động và người ta có thể nghĩ rằng không có giới hạn nào đối với tự động hóa và có thể tự động hóa mọi thứ. Mặc dù chúng tôi ngày càng có sẵn nhiều công cụ và khung tự động hóa thử nghiệm, nhưng không phải mọi thứ đều có thể và nên được tự động hóa. Trong một số trường hợp, sẽ rẻ hơn và tốt hơn nếu sử dụng thử nghiệm thủ công. Bài viết này sẽ thảo luận về tám khía cạnh tại sao kiểm thử thủ công vẫn cần thiết và trong những tình huống nào có thể sử dụng kiểm thử thủ công thay vì kiểm thử tự động.

1. Thời gian

Mặc dù bản thân các bài kiểm tra tự động sẽ thực thi nhanh hơn và với ít đầu vào hơn từ người kiểm tra, việc thiết lập cơ sở hạ tầng tự động hóa có thể tốn nhiều thời gian. Trong một số trường hợp, sẽ nhanh hơn nếu thực hiện kiểm thử thủ công hơn là kiểm thử tự động. Việc thiết lập môi trường tự động và kiểm tra tự động sẽ dễ dàng hơn trong giai đoạn đầu của dự án khi ít tốn thời gian hơn. Tuy nhiên, nếu dự án rất phức tạp và có nhiều thành phần được kết nối với nhau, môi trường tự động hóa và thiết lập thử nghiệm sẽ tiêu tốn nhiều thời gian và tài nguyên hơn. Trong một số trường hợp, nếu dự án quá phức tạp, việc tạo môi trường tự động hóa và kiểm tra tự động cho dự án có thể là không thể hoặc quá tốn kém.

2. Sự tiếp xúc của con người

Hơn nữa, các bài kiểm tra tự động không có cảm giác của con người. Rốt cuộc, chính máy tính đang chạy thử nghiệm và kiểm tra các giá trị. Đối với người dùng cuối, tính thẩm mỹ trực quan của ứng dụng cũng quan trọng như chức năng chính xác của các tính năng của ứng dụng. Trong hầu hết các trường hợp, kiểm tra tự động sẽ chỉ kiểm tra xem giá trị của nhãn văn bản có trên màn hình hay không, nhưng sẽ không kiểm tra vị trí của nhãn trên màn hình. Trong những trường hợp như vậy, kiểm tra thủ công sẽ thuận tiện vì giao diện trực quan của phần tử có thể được xác minh dễ dàng. Nếu giao diện người dùng phức tạp (ví dụ: nhiều hoạt ảnh hoặc phần tử tương tác), thì cách nhanh hơn và rẻ hơn là thử nghiệm thủ công và chỉ tự động hóa SDK và/hoặc phần API để đảm bảo rằng logic nghiệp vụ không có bất kỳ hồi quy nào. Có các giải pháp kiểm tra trực quan tự động đánh giá các chi tiết trực quan của phần mềm,

3. Cần có kinh nghiệm

Nếu các bài kiểm tra tự động được viết kém và không tuân theo các phương pháp hay nhất, thì kết quả của bài kiểm tra đó có thể gây hiểu lầm và do đó khiến các hoạt động này trở nên vô dụng. Dựa trên kinh nghiệm của chúng tôi khi làm việc với nhiều dự án tự động hóa thử nghiệm, bạn nên giao cho các kỹ sư có kinh nghiệm nhiệm vụ lập kế hoạch và thực hiện tự động hóa thử nghiệm. Những kỹ sư này sẽ tuân theo các phương pháp hay nhất để tạo môi trường thử nghiệm, viết thử nghiệm và duy trì mã. Kiểm thử tự động phải được bảo trì và kiểm tra hàng ngày.

4. Bảo mật

Đối với các dự án phức tạp, bạn nên đánh giá cẩn thận tất cả các quyền cần thiết để thực hiện kiểm thử. Trong một số dự án, các kỹ sư tự động hóa thử nghiệm có thể không có toàn quyền truy cập vào hệ thống và có các hạn chế đối với những hệ thống và môi trường mà người thử nghiệm đã được cấp quyền truy cập. Trong những trường hợp như vậy, điều quan trọng là phải cân nhắc xem có nên sử dụng thử nghiệm tự động hay không. Bạn không thể tự động kiểm tra trên các hệ thống mà bạn không có cấp độ truy cập cần thiết.

5. Thử nghiệm thăm dò

Exploratory testing là một loại thử nghiệm trong đó các trường hợp thử nghiệm không được tạo trước, nhưng người thử nghiệm sẽ kiểm tra hệ thống một cách nhanh chóng. Nó có thể giúp tester nhanh chóng xác định các lỗi lớn, từ đó giúp tạo ra một sản phẩm thực sự cần thiết. Mặc dù rất đơn giản và dễ thực hiện, nhưng thử nghiệm khám phá không thể thực hiện được với thử nghiệm tự động vì thử nghiệm tự động bao gồm các kịch bản thử nghiệm được viết bởi kỹ sư thử nghiệm. Các tình huống này không linh hoạt và máy tính sẽ chỉ kiểm tra những thứ được viết để kiểm tra và xác minh – không hơn không kém.

6. Không phải mọi thứ đều có thể tự động hóa

Như tôi đã nói trước đây, điều đó không được khuyến khích cũng như không thể tự động hóa mọi thứ. Nếu bạn có một sản phẩm di động và bạn cần xác thực cách sản phẩm đó hoạt động trên nhiều thiết bị/kích thước màn hình/phiên bản hệ điều hành/nhà sản xuất – việc tự động hóa điều đó là không thực tế và nhiều điện thoại cũ không hỗ trợ tự động hóa. Có thể xảy ra tình huống không có công cụ tự động hóa cho nền tảng hoặc loại thiết bị cụ thể.

Một ví dụ khác là một ứng dụng điện thoại mà bạn nên thử gọi các dịch vụ Khẩn cấp. Trong trường hợp này, điều quan trọng là phải suy nghĩ trước và cân nhắc những rủi ro tiềm ẩn có thể gặp phải khi tự động hóa các bài kiểm tra chức năng như vậy. Trong trường hợp này, chức năng chính cần kiểm tra sẽ là khởi chạy màn hình cuộc gọi, chứ không phải bản thân cuộc gọi. Như đã nói, điều quan trọng là phải biết thử nghiệm nào đủ ổn định để thử nghiệm tự động vì kịch bản này có thể thất bại tại một số điểm và trong trường hợp đó, các thử nghiệm như vậy có thể gây rắc rối không chỉ cho các kỹ sư thử nghiệm mà còn cho chính công ty.

Đôi khi thông tin cần kiểm tra được hiển thị trong một thời gian rất ngắn hoặc không thể phát hiện được, và vì lý do này, kiểm tra thủ công sẽ tốt hơn vì kiểm tra tự động sẽ cần một khoảng thời gian và/hoặc quyền truy cập để phát hiện một phần tử, trong khi một con người nhìn thấy nó ngay lập tức. Ngoài ra, do khả năng của khung kiểm tra hoặc công cụ, có thể có các hạn chế đối với việc đọc và định vị, chẳng hạn như một thành phần trong thông báo đẩy. Một lần nữa, điều này có thể được kiểm tra một cách dễ dàng bằng tay.

7. Sự ổn định

Hơn nữa, giả sử một ứng dụng đang được phát triển và nó chưa đạt đến phiên bản rất ổn định. Trong trường hợp đó, không có lý do gì để lãng phí tài nguyên và thời gian trong việc tạo và tạo môi trường tự động hóa cũng như các bài kiểm tra tự động vì các bài kiểm tra sẽ cần cập nhật liên tục sau mỗi lần cập nhật phiên bản ứng dụng. Tất nhiên, các trường hợp và kịch bản thử nghiệm dù sao cũng phải được kiểm tra để duy trì kết quả mong muốn, nhưng khi một ứng dụng không ổn định, kết quả của thử nghiệm tự động có nhiều khả năng là sai. Nếu ứng dụng ổn định, các bài kiểm tra tự động cũng sẽ ổn định và khách quan. Trước đó, tốt hơn hết bạn nên bắt đầu thử nghiệm ứng dụng theo cách thủ công để nhận được kết quả có giá trị. Nhưng một khi sản phẩm đã được tung ra thị trường và bạn cần đảm bảo không có hồi quy giữa các bản cập nhật gia tăng, tự động hóa thử nghiệm có thể rất hữu ích.