Giới thiệu

Bạn đã bao giờ phát hiện ra lỗi khi chỉ đơn giản là thử nghiệm một ứng dụng chưa? Trong kiểm thử phần mềm, bạn không phải lúc nào cũng cần chuẩn bị kịch bản chi tiết để kiểm tra một trường hợp đơn giản. Đó chính là sức mạnh của kiểm thử không kế hoạch. Hai phương pháp quan trọng trong kiểm thử không kế hoạch là kiểm thử Ad-Hoc và kiểm thử Exploratory.

Mặc dù kiểm thử Ad-Hoc và kiểm thử Exploratory có vẻ tương tự nhau, nhưng chúng không hoàn toàn giống nhau. Bài viết này sẽ giải thích những điểm khác biệt chính, giúp bạn hiểu khi nào nên sử dụng mỗi phương pháp để phát hiện nhiều lỗi hơn và cung cấp sản phẩm tốt hơn.

1. Định nghĩa

Kiểm thử Ad-Hoc

Kiểm thử Ad-Hoc là một phương pháp kiểm thử không có kế hoạch, liên tục. Nó được thực hiện mà không cần tài liệu, kịch bản kiểm thử hay kế hoạch nào. Mục tiêu chính là tìm ra lỗi một cách nhanh chóng bằng cách thử nghiệm ngẫu nhiên. Phương pháp này hoàn toàn dựa vào kinh nghiệm và sự sáng tạo của người kiểm thử.

Ví dụ, bạn được giao nhiệm vụ kiểm thử trang đăng nhập. Mục tiêu chính ở đây là phát hiện bất kỳ lỗi nào trên trang này, vì vậy bạn không liệt kê các kịch bản kiểm thử và bước kiểm thử. Bạn chỉ việc nhấp ngẫu nhiên vào bất kỳ nút nào để xem có lỗi phát sinh hay không.

Kiểm thử Exploratory

Kiểm thử Exploratory cũng là một phương pháp kiểm thử linh hoạt và thích ứng, nhưng theo cách có chủ đích hơn. Nó không yêu cầu một kịch bản chi tiết để thực hiện, nhưng ít nhất có một mục tiêu cụ thể để theo dõi. Người kiểm thử tìm hiểu về ứng dụng, tạo ra các bài kiểm thử và thực hiện chúng cùng một lúc. Đây không phải là hành động nhấp chuột ngẫu nhiên. Người kiểm thử áp dụng kiến thức và trực giác của mình để điều tra các kịch bản khác nhau dựa trên mục tiêu đã định, và điều chỉnh các bước tiếp theo dựa trên những gì họ khám phá ra.

Trong cùng một ví dụ, bạn cũng được giao nhiệm vụ kiểm thử trang đăng nhập. Nhưng bây giờ bạn đã xác định mục tiêu của mình để đảm bảo rằng quy trình đăng nhập có thể hoạt động đúng cách. Mặc dù bạn không cần kịch bản kiểm thử và các bước kiểm thử cụ thể, bạn vẫn sẽ có một số kịch bản tổng quát, chẳng hạn như điều gì xảy ra khi bạn sử dụng mật khẩu sai, để lại một trường trống, hoặc cố gắng đăng nhập bằng email thay vì tên người dùng. Bạn không chỉ nhấp ngẫu nhiên; bạn đang khám phá dựa trên một mục đích cụ thể, tập trung.

2. Điểm chung

Kiểm thử Ad-Hoc và Exploratory có những đặc điểm chung: cả hai đều không có kịch bản và không phụ thuộc vào các kịch bản kiểm thử đã được viết trước hay các quy trình chính thức. Chúng phụ thuộc vào kỹ năng, kiến thức và kinh nghiệm của người kiểm thử. Bằng cách kích thích hành vi của người dùng, chúng hiệu quả trong việc phát hiện lỗi mà kiểm thử chính thức có thể bỏ qua. Điều này phân biệt chúng với kiểm thử chính thức, theo dõi các kịch bản kiểm thử chi tiết và tài liệu, và tập trung chặt chẽ vào các yêu cầu đã được định nghĩa trước.

3. Sự khác biệt giữa Kiểm thử Exploratory và Kiểm thử Ad-Hoc

Mục tiêu

Kiểm thử Ad-Hoc chỉ có một mục tiêu chính: tìm ra càng nhiều lỗi càng tốt, càng nhanh càng tốt. Đây là một bước kiểm tra nhanh chóng cho các khuyết điểm có thể ảnh hưởng đến trải nghiệm người dùng và đảm bảo tính ổn định của tính năng.

Ngược lại, mục tiêu của kiểm thử Exploratory tập trung vào hai phần ngang nhau: liên tục tìm hiểu về ứng dụng và tìm ra lỗi mới trong một khu vực cụ thể. Khám phá ứng dụng là nền tảng cho việc kiểm thử hiệu quả. Bằng cách chủ động khám phá và hiểu cách hệ thống hoạt động, bạn có thể phát hiện ra lỗi mới và phức tạp mà một bài kiểm thử đã viết trước có thể bỏ lỡ. Mục tiêu của việc tìm ra lỗi mới là kết quả cuối cùng của quá trình này. Đó là kết quả cụ thể chứng minh giá trị của việc khám phá. Do đó, bạn không thể đạt được một mục tiêu mà không có mục tiêu kia; chúng là hai phần liên kết của một quá trình toàn diện.

Kế hoạch

Một trong những điểm khác biệt chính giữa kiểm thử Ad-Hoc và kiểm thử Exploratory là kế hoạch. Vì mục đích chính của kiểm thử Ad-Hoc là tìm ra càng nhiều lỗi càng tốt, bạn sẽ không dành thời gian lên kế hoạch chính xác những gì cần làm. Bạn chỉ cần nhận các yêu cầu và thử các hành động khác nhau dựa hoàn toàn vào kinh nghiệm của bạn để xem có vấn đề gì xảy ra hay không.

Kiểm thử Exploratory, mặc dù cũng linh hoạt và không có kịch bản, nhưng được hướng dẫn bởi một mục tiêu rõ ràng. Bạn không dựa vào các bước kiểm thử chính thức hay kịch bản chi tiết, nhưng sẽ có một số ý định trong đầu. Những điều này xuất phát từ kinh nghiệm của bạn và những gì bạn đã khám phá về các tính năng để phát hiện các khuyết điểm có thể xảy ra.

Phương pháp tiếp cận

Khi nói đến phương pháp kiểm thử, kiểm thử Ad-Hoc là một quá trình ngẫu nhiên và không có tổ chức. Với Ad-Hoc, “số lần nhấp chuột quan trọng hơn từng giây”. Càng nhiều lần nhấp chuột được thực hiện, khả năng phát hiện lỗi mới càng cao. Bạn xem mỗi lần nhấp chuột ngẫu nhiên như một cơ hội để tìm ra lỗi. Do đó, kết quả kiểm thử của bạn cũng trở nên không thể đoán trước. Đôi khi, bạn chỉ cần vài lần nhấp chuột để phát hiện một lỗi nghiêm trọng, trong khi trong một số trường hợp, bạn phải mất hàng giờ mà không có phát hiện nào có giá trị.

Kiểm thử Exploratory có mục đích rõ ràng hơn. Bạn không cần chuẩn bị một kế hoạch chi tiết để cho biết những gì bạn cần làm ở mỗi bước, nhưng bạn cần một “quy trình suy nghĩ”. Một test charter thường được sử dụng để định nghĩa ngắn gọn phạm vi kiểm thử và mục tiêu cho các phiên kiểm thử. Với sự hướng dẫn này, bạn chủ động tìm hiểu về hệ thống, hình thành ý định từ các quan sát, quyết định các bước tiếp theo và phát hiện những vấn đề sâu hơn. Nó tạo ra một “chuỗi suy nghĩ” qua quá trình kiểm thử của bạn, loại bỏ sự thiên lệch và ngẫu nhiên của phương pháp Ad-Hoc.

Tài liệu

Kiểm thử Ad-Hoc không có tài liệu nào. Dữ liệu kiểm thử trong phiên Ad-Hoc là không thể kế thừa. Ví dụ, bạn nhấp vào cùng một “nút đăng nhập” mỗi lần bạn muốn kiểm tra một lỗi trên trang đăng nhập để tìm ra một lỗi phổ biến. Nút này không có bất kỳ khuyết điểm nào lần này, nhưng điều đó không có nghĩa là nó sẽ không có bất kỳ xung đột nào với phần mềm sau các bản cập nhật. Đó là lý do tại sao bạn sẽ thực hiện nhiều lần nhấp chuột hơn, thay vì ghi lại từng lần nhấp.

Ngược lại, kiểm thử Exploratory là về việc liên tục khám phá và kiểm thử. Sử dụng cùng một ví dụ, bạn có thể xác định phạm vi kiểm thử của mình cho phương thức đăng nhập (thông qua Email trong phiên 1, thông qua Google trong phiên 2, v.v.), để khám phá cách phần mềm của bạn hoạt động và đảm bảo tất cả các cổng đăng nhập hoạt động đúng. Do đó, “việc ghi chép là quan trọng”. Nó cho thấy nguyên nhân và kết quả của chuỗi hành động của bạn. Ghi chép kiểm thử của bạn cung cấp bằng chứng về các khuyết điểm đã phát hiện và giúp tái tạo lỗi dựa trên chuỗi các bước bạn đã thực hiện, liên kết với kết quả. Tài liệu cũng giúp bạn xác định xem có nên tập trung vào các phiên chạy lại khác hay không, do đó đảm bảo độ phủ kiểm thử đầy đủ.

Phạm vi kiểm thử

Phạm vi của kiểm thử Ad-Hoc là không giới hạn. Mặc dù bạn có thể áp dụng kinh nghiệm của mình và tập trung vào một phần cụ thể thường gặp lỗi, không có tài liệu chính thức nào để thu hẹp phạm vi kiểm thử của bạn. Bạn hoàn toàn tự do kiểm thử bất kỳ phần nào của ứng dụng mà bạn muốn. Cách tiếp cận này có thể rất tốt để phát hiện lỗi rõ ràng ở những nơi bất ngờ mà có thể đã bị bỏ qua trong một kế hoạch kiểm thử chính thức.

Ngược lại, kiểm thử Exploratory là có phạm vi. Bạn được hướng dẫn bởi một nhiệm vụ cụ thể, điều này cho phép một cuộc điều tra sâu hơn, chi tiết hơn, giúp dễ dàng phát hiện các vấn đề ẩn hoặc phức tạp mà có thể bị bỏ qua bởi một bài kiểm thử nhanh, ngẫu nhiên.

Thời gian & Tần suất

Kiểm thử Ad-Hoc là một hoạt động một lần. Nó không nằm trong một lịch trình thường xuyên, mà là một phản ứng nhanh chóng, thường được thực hiện để kiểm tra xem phần mềm tổng thể vẫn ổn định sau các bản cập nhật hoặc thay đổi. Một phiên Ad-Hoc nên rất ngắn, thường không kéo dài quá 15 đến 30 phút. Mục tiêu là nhanh chóng tìm ra bất kỳ lỗi rõ ràng nào trước khi một quy trình kiểm thử chính thức bắt đầu. Một phiên kéo dài hơn sẽ khiến bạn bị lạc trong các chi tiết không cần thiết.

Kiểm thử Exploratory là một phần thường xuyên và liên tục của chu trình phát triển. Đây là một hoạt động có kế hoạch giúp liên tục phát hiện lỗi và tìm hiểu về hệ thống theo thời gian. Các phiên kiểm thử Exploratory thường được thực hiện trong khoảng thời gian tập trung, có thời gian cố định từ 60 đến 120 phút. Mục tiêu của một phiên có thời gian cố định là duy trì sự tập trung và cho phép đủ thời gian cho một cuộc điều tra sâu mà không dẫn đến các phiên kéo dài. Bạn không cần thực hiện tất cả các kịch bản có thể trong lần đầu tiên, chỉ cần tập trung vào phạm vi ban đầu và để lại phần còn lại cho các phiên sau.

Yêu cầu về kiến thức

Kiểm thử Ad-Hoc yêu cầu kiến thức tối thiểu về hệ thống. Bạn có thể nhảy vào và tìm ra các lỗi rõ ràng, dễ phát hiện chỉ bằng cách nhấp quanh, làm cho nó trở thành một lựa chọn tuyệt vời cho người mới với phần mềm.

Ngược lại, kiểm thử Exploratory yêu cầu hiểu biết sâu hơn về hệ thống và ngữ cảnh kinh doanh của nó. Bạn phải áp dụng kiến thức và kinh nghiệm của mình để hình thành một nhiệm vụ, dự đoán các vấn đề tiềm ẩn và điều chỉnh kiểm thử của bạn dựa trên những gì bạn đã học được. Điều này cho phép bạn phát hiện ra những khuyết điểm phức tạp hoặc ẩn mà một người mới hoặc ít kinh nghiệm có thể bỏ qua.

4. Khi nào nên sử dụng?

Khi lựa chọn phương pháp kiểm thử phù hợp, quyết định đến từ một sự trao đổi giữa tốc độ và tính toàn diện. Sự lựa chọn giữa kiểm thử Ad-Hoc và kiểm thử Exploratory không phải là cái nào tốt hơn, mà là cái nào là công cụ thông minh hơn cho công việc.

Kiểm thử Ad-Hoc là một giải pháp phản ứng, ngắn hạn để tìm lỗi hiệu quả khi thời gian hoặc nguồn lực hạn chế. Nó tốt nhất khi được sử dụng như một kiểm tra nhanh và không chính thức, chẳng hạn như một thay đổi hoặc cập nhật nhỏ. Mục tiêu chính là tìm ra những lỗi rõ ràng, bề mặt có thể gây ra ảnh hưởng lớn. Về cơ bản, kiểm thử Ad-Hoc ưu tiên tốc độ hơn là độ phủ toàn diện, làm cho nó trở thành lựa chọn lý tưởng trong một bối cảnh rủi ro thấp. Trong vòng đời kiểm thử phần mềm, kiểm thử Ad-Hoc thường được thực hiện muộn trong chu trình phát triển để kiểm tra nhanh và đảm bảo rằng không có lỗi nghiêm trọng nào ảnh hưởng đến các giai đoạn kiểm thử chính thức.

Trong khi đó, kiểm thử Exploratory nên được sử dụng khi bạn cần điều tra các tính năng phức tạp hoặc mới. Nó đặc biệt hữu ích khi các yêu cầu không được định nghĩa đầy đủ để thực hiện kiểm thử chính thức*,* hoặc trong một bối cảnh rủi ro cao nơi bạn muốn thu thập thông tin cho các bài kiểm thử cấu trúc sau này. Về cơ bản, kiểm thử Exploratory có thể được sử dụng trong suốt quá trình kiểm thử bất cứ khi nào bạn cần một cái nhìn sâu hơn, linh hoạt về hệ thống để phát hiện các vấn đề mà các bài kiểm thử chuẩn hoặc đã được viết có thể bỏ qua.

Kết luận

Cả kiểm thử Ad-Hoc và Exploratory đều có những giá trị riêng biệt; chúng chỉ là những công cụ khác nhau cho các công việc khác nhau. Kiểm thử Ad-Hoc giống như một cuộc tìm kiếm nhanh chóng, ngẫu nhiên, sử dụng tốc độ và trực giác để tìm ra những lỗi dễ phát hiện. Trong khi đó, kiểm thử Exploratory giống như công việc của một thám tử, nơi kiến thức của người kiểm thử được sử dụng để phát hiện những vấn đề sâu hơn, ẩn giấu hơn. Bằng cách hiểu rõ những điểm mạnh độc đáo của mỗi phương pháp, bạn có thể cải thiện quy trình kiểm thử và đảm bảo sản phẩm của mình không có lỗi càng nhiều càng tốt.