Exploratory testing và Ad-hoc testing

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

Bài viết được tham khảo từ nguồn:

http://www.softwaretestingclass.com/difference-between-adhoc-testing-and-exploratory-testing/

http://www.softwaretestingclass.com/what-is-exploratory-testing/

http://istqbexamcertification.com/what-is-ad-hoc-testing/

Nói về mảng Software testing, hôm nay, tôi sẽ giới thiệu với các bạn về một phần rất thú vị đó là “Exploratory Testing” và "Ad-hoc testing". Trong bài này, tôi đang có một trải nghiệm quan trọng về đột phá trong kiểm thử, ưu điểm, nhược điểm và làm thế nào để ứng dụng nó vào kiểm thử thực thế. Những mẹo này sẽ giúp bạn làm thế nào để hiểu và tiếp cận phương pháp này vào các bài tập cơ bản trong ngành kiểm thử thực tế.

1. Exploratory testing

Một câu hỏi trong ý nghĩ của nhân viên kiểm thử (QA) là “Software testing Exploratory testing là gì?” Như cái tên của nó đã chỉ ra rằng Exploratory testing là quá trình test phần mềm mà không có kế hoạch và lịch trình đặc biệt. Đây là quá trình kiểm thử thông thường mà không sử dụng bất kỳ bộ testcase nào cả hoặc là những tài liệu cho kế hoạch test ứng dụng của bạn. Xác định chức năng của ứng dụng bằng việc khám phá và học làm test design, testcase và sử dụng thiết bị giả lập để thực hiện test chúng một cách tốt nhất.

Định nghĩa “Exploratory testing”

“Exploratory Testing là cách tiếp cận quá trình test cho phép bạn áp dụng năng lực, kỹ năng và kỹ xảo của người kiểm thử (QA) một cách hữu hiệu nhất”. Đầu tiên những nhân viên kiểm thử phần mềm (QA) phải hiểu về ứng dụng đó bằng việc khám phá nó dựa trên sự hiểu biết về việc chúng xảy ra với các kịch bản kiểm thử nào. Sau đó bắt đầu quá trình kiểm tra thực tế của ứng dụng.

Những lời khuyên quan trọng cần nhớ về công nghệ test khám phá:

Chuẩn bị các kịch bản kiểm thử để xác định tính ổn định của phần mềm.
Kiểm tra toàn diện các trường hợp của ứng dụng dựa trên việc xác định yêu cầu.
Tìm ra các yêu cầu cũng như các chức năng của ứng dụng.
Tìm ra giời hạn của ứng dụng.
Xác định phạm vi của dự án.

Trong quá trình kiểm tra của phương thức này tester (QA) phải làm nỗ lực tối thiểu để lập kế hoạch nhưng trong khi thực thi tối đa tester (QA) phải kiểm tra được các chức năng của ứng dụng một cách chính xác. Điều này rất hữu ích cho tester (QA) để đưa ra quyết định những gì có thể được làm bên cạnh việc kiểm tra. Trong suốt quá trình kiểm tra tester (QA) cần tìm hiểu về hành vi của các ứng dụng phần mềm, bắt đầu tạo kế hoạch thử nghiệm hoặc kịch bản kiểm thử. Có những công cụ thử nghiệm thăm dò khác nhau trên thị trường. Một trong những công cụ kiểm tra đó là "Session Tester" có thể được sử dụng như để quản lý và thu âm “Session-Based Testing”. Việc tạo ra các kịch bản kiểm thử là hoàn toàn dựa trên những kinh nghiệm và việc học hỏi ứng dụng ngoài việc test.

Loại test này là việc test ngẫu nhiên của nhân viên kiểm thử. Việc tìm ra lỗi không chỉ phụ thuộc trên kinh nghiệm của nhân viên kiểm thử (QA) mà còn dựa trên kỹ năng.

Nhiều nhân viên kiểm thử đang nghĩ rằng loại test này cần đi kèm trong các hình ảnh, vì vậy đây là điểm chúng ta cần sử dụng trong kỹ thuật test khám phá:

Khi ứng dụng của bạn không có tài liệu đặc tả yêu cầu hoặc không có tài liệu cho việc test (test plan, checklist, test case…) hoặc tài liệu là nhỏ.
Khi bạn muốn hoàn thành công việc test của bạn trong một khoảng thời gian ngắn ngủi.
Khi bạn phải test ứng dụng sớm trong một chu kỳ phát triển của phần mềm.

Ưu điểm:

Phương pháp này không yêu cầu chuẩn bị cho quá trình test như là việc chúng ta không có tài liệu cho hoạt động kiểm thử.
Thời gian trong quá trình test được tiết kiệm do tất cả các nhiệm vụ test được làm cùng một lúc như là quá trình test, thiết kế kịch bản kiểm thử và thực hiện các kịch bản kiểm thử.
Nhân viên kiểm thử (QA) có thể báo cáo nhiều vấn đề do yêu cầu không đầy đủ hoặc tài liệu yêu cầu còn thiếu.

Nhược điểm:

Vài vấn đề không thể được khai thác trong kiểu test này.
Có xem xét lại các kế hoạch kiểm tra và thiết kế testcase/kịch bản test trong khi quá trình test có xảy ra vấn đề.
Những nhân viên kiểm thử (QA) cần phải nhớ kịch bản test - những gì mà anh ta đang thực hiện test bởi vì nếu có lỗi được tìm thấy, tester (QA) sẽ “report a bug” với các bước thích hợp để tái hiện lại nó, với các lỗi khó tái hiện cần phải mô tả các bước một cách thích hợp để thực hiện một cách chính xác lỗi mà anh ta đã báo cáo đặc biệt là với các lỗi mới được tìm thấy.

Tôi nghĩ rằng những điều mà tôi nói bên trên là tất cả các điểm chính trong phương thức kiểm tra thăm dò. Các bạn hãy giành thời gian đọc kỹ nó nhé. Sau đây, tôi sẽ giới thiệu về một phương thức kiểm thử cũng không kém phần thú vị đó là: “ad-hoc testing”.

2. Ad-hoc testing

Ý nghĩa của từ Ad-hoc là một cái gì đó mà không theo thứ tự hoặc không có tổ chức hay không có cấu trúc nào cả. Trong một lưu ý tương tự về thử nghiệm Ad-hoc không là gì nhưng nó là một loại kiểm thử hộp đen (Black box testing) hoặc kiểm tra hành vi đó (Behavioural testing) được thực hiện mà không theo bất cứ một quy trình chính thức nào giống như tài liệu đặc tả yêu cầu, kế hoạch test, test case, … Tương tự như vậy trong khi thực hiện ad-hoc testing không có quy trình kiểm thử chính thức cái mà có thể được ghi nhận. Ad-hoc testing thường kết thúc để khám phá những vấn đề (issues ) hoặc lỗi (defects) mà không thể được tìm thấy bằng quá trình test chính thức. Những nhân viên kiểm thử (QA) người thực hiện quá trình kiểm thử này cần phải có kiến thức rất tốt và có chiều sâu về sản phẩm hoặc ứng dụng. Khi nhân viên kiểm thử thực hiện ad-hoc testing họ chỉ có ý định phá vỡ hệ thống mà không theo bất kỳ quy trình nào hoặc không có bất kỳ trường hợp cụ thể nào trong tâm trí họ.

Đặc điểm của Ad-hoc testing

Ad-hoc testing được thực hiện sau khi quá trình test thông thường kết thúc trên ứng dụng hoặc sản phẩm.
Quá trình kiểm tra này là để thực hiện với mục đích phá vỡ ứng dụng mà không theo bất cứ quy trình nào.
Testers (QA) thực hiện quá trình kiểm tra ad-hoc cần có kiến thức toàn diện về sản phẩm.
Lỗi được tìm thấy trong suốt quá trình ad-hoc cho thấy có nhiều sơ hở trong quá trình thử nghiệm tiếp theo.
Ad-hoc testing được thực hiện chỉ một lần cho đến tận khi và trừ khi một lỗi được tìm thấy trong đó yêu cầu cần kiểm tra lại.

Ad-hoc testing có thể được thực hiện khi nào?

Và bây giờ, trong tâm trí của bạn sẽ có câu hỏi là khi nào chúng ta nên dùng phương pháp ad-hoc testing? Để trả lời câu hỏi này bạn có thể nói rằng ad-hoc testing có thể thực hiện tại bất kỳ thời điểm nào cho dù đó là bắt đầu, giữa hay cuối của dự án. Hoạt động này chỉ được thực hiện khi nhân viên kiểm thử (QA) đều có kiến thức đầy đủ về sản phẩm. Hoạt động test này cũng có thể được thực hiện khi thời gian là rất hạn chế và kiểm tra chi tiết là cần thiết.

Ad-hoc testing không nên được thực hiện khi nào?

Việc đưa ra quyết định khi nào không thực hiện ad-hoc testing là bởi kinh nghiệm và kỹ năng của tester (QA). Mặc dù có một ít trường hợp không nên thực hiện ad-hoc testing:

Ad-hoc testing không yêu cầu khi nó đã tồn tại một lỗi trong test case. Trong trường hợp đó, lỗi phải được báo cáo và nó cần được thực hiện lại một lần khi nó đã được sửa.
Ad-hoc testing không nên thực hiện trong khi thực hiện Beta testing của phần mềm của khách hàng.

Các loại dùng trong ad-hoc testing là gì?

Về cơ bản có 3 loại ad-hoc testing. Chúng là:

Buddy testing: Loại test này được thực hiện bởi nhân viên lập trình và nhân viên kiểm thử những người chịu trách nhiệm cho việc giao nhận từng module cụ thể. Trong loại test này nhân viên lập trình và nhân viên kiểm thử sẽ ngồi cũng nhau và làm việc trên một module cụ thể để tránh từ việc xây dựng các kịch bản không hợp lệ mà còn ở các mặt khác giúp các tester báo cáo những lỗi (defects) không hợp lệ.
Pair testing: Loại test này được thực hiện bởi 2 tester ngồi làm việc cùng với nhau trên cùng một module. Về cơ bản họ chia các kịch bản testing giữa các module. Mục đích của các loại testing là đến với các kịch bản kiểm thử tối đa để module của các thực thể hoàn thành mức độ bao phủ. Cũng có thể tạo kịch bản kiểm thử của tester (QA) và quan sát trong quá trình kiểm tra thực thể các module cùng với nhau.
Monkey testing: Loại test này là quá trình thực hiện kiểm tra ngẫu nhiên một vài chức năng trong quá trình test cho một số dữ liệu ngẫu nhiên với mục đích phá vỡ hệ thống. Quá trình kiểm tra này giúp chúng tôi phát hiện ra một số lỗi (bug) mới, những lỗi mà trước đó không bắt được.

Ưu điểm và lợi ích của Ad-hoc testing

Dưới đây là một vài ưu điểm và lợi ích liên quan đến Ad-hoc testing:

Ad-hoc testing là việc test tự do để tester áp dụng những cách thức mới của riêng họ trong việc test ứng dụng giúp họ tìm ra nhiều lỗi (defects) nhất có thể so với quá trình thử nghiệm chính thức.
Các loại test có thể được thực hiện bất cứ lúc nào nơi nào trong chu kỳ phát triển phần mềm (Software Development Life Cycle (SDLC)) mà không theo bất kỳ qui trình chính thức nào.
Loại test này không chỉ bị giới hạn quá trình test của một team mà nó còn có thể được thực hiện bởi nhân viên lập trình trong khi những module của họ đang được phát triển điều đó giúp họ trong việc code bằng những phương pháp tốt nhất.
Ad-hoc testing đã được chứng minh là phương pháp mang lại nhiều lợi ích khi mà người tester (QA) có ít thời gian và chiều sâu cho hoạt động kiểm thử của một đặc tính được yêu cầu. Điều này có lợi trong việc cung cấp các tính năng đảm bảo chất lượng và đúng thời hạn.
Ad-hoc testing có thể thực hiện đồng thời với các loại kiểm thử khác giúp cho việc tìm nhiều lỗi (bug) hơn trong những khoảng thời gian ít hơn.
Đối với loại test này tài liệu là không cần thiết mà tester (QA) cần tập trung quá trình kiểm thử vào đặc tính của ứng dụng mà không phải lo lắng về các tài liệu chính thức.

Nhược điểm của Ad-hoc testing

Kể từ khi ad-hoc testing được thực hiện mà không có bất kỳ kế hoạch và không theo bất cứ cấu trúc nào vì vậy việc tái tạo lại lỗi (bug) đã trở thành một rắc rối lớn.
Kịch bản kiểm thử được thực hiện trong suốt quá trình ad-hoc testing không có tài liệu để tester (QA) có thể giữ tất cả các kịch bản trong tâm trí mà anh ấy/cô ấy có thể không nhớ lại trong tương lai.
Ad-hoc testing phụ thuộc rất nhiều vào kỹ năng của tester (QA) người có hiểu biết toàn diện về sản phẩm mà nó không thể được thực hiện bởi một người mới tham gia vào dự án của team.

Thực hành tốt nhất trong khi thực hiện ad-hoc testing

Nếu ad-hoc testing không được thực hiện theo cách thức thích hợp nó có thể dẫn đến mất toàn bộ thời gian và công sức. Dưới đây là một vài gợi ý cho tester (QA) để xác định phạm vi và cách thức như thế nào để ứng dụng vào ad-hoc testing:

Kiến thức tốt về sản phẩm: Tester (QA) - những người thực hiện ad-hoc testing cần có kiến thức tốt về sản phẩm. Anh ta cần có hiểu biết tốt với tất cả các đặc tính của sản phẩm. Điều này giúp tester (QA) trong việc phản đoán lỗi (error) và tìm ra nhiều lỗi nhất có thể từ những khu vực dễ mắc lỗi (defect) nhất.
Độ ưu tiên các đặc tính Khi ad-hoc testing thực hiện cho nhiều đặc tính thì trước tiên các trường hợp kiểm thử cần được phân loại và ưu tiên. Những đặc tính được sử dụng nhiều bởi khách hàng cần được kiểm tra đầu tiên cho đến khi có một vài lỗi (bug) có độ ưu tiên tồn tại trong hệ thống thì cần được báo cáo và sửa càng sớm càng tốt.
Lập kế hoạch sơ bộ: Mặc dù không có nhu cầu về bất cứ tài liệu nào trong quá trình sử dụng phương thức ad-hoc testing như đã nói ở trên nhưng có lưu ý một vài điểm trong suốt quá trình kiểm tra này là giúp tester (QA) nhớ tất cả các trường hợp thử nghiệm có thể xảy ra trong quá trình test. Điều này giúp cho việc tăng tối đa độ bao phủ trong thời gian ít hơn.
Cách sử dụng công cụ Đôi khi trong lúc kiểm tra có lỗi (bug) hoặc những ngoại lệ được tìm thấy trong các bản log mà không được nhìn thấy trong giao diện người dùng hay cản trở quá trình kiểm tra trong bất kỳ cách nào. Những loại lỗi (bug) đó cần để mức độ nghiêm trọng cao. Để bắt được những lỗi (bug) hoặc những ngoại lệ đó chúng ta cần phải sử dụng công cụ như dò lỗi (debuggers), công cụ định hình hoặc màn hình nhiệm vụ.
Quan sát tài liệu Mặc dù quá trình kiểm tra sử dụng phương thức ad-hoc testing không hỗ trợ tài liệu nhưng nó luôn luôn tốt hơn để viết một ghi chú ngắn gọn về việc kiểm tra, phát hiện và độ xê dịch của bạn. Nếu lỗi (defect) được tìm thấy sau đó chúng ta cần tạo các testcase liên quan, điều này giúp ích cho tester (QA) trong việc kiểm tra lại các kịch bản trong tương lai.

=> Và bây giờ chúng ta hãy cùng so sánh Ad-hoc testing và Exploratory testing nhé

Adhoc Testing	Exploratory Testing
Ad-hoc testing bắt đầu với việc học ứng dụng và sau đó làm việc với quá trình kiểm tra thực tế.	Exploratory Testing bắt đầu với việc khám phá ứng dụng trong khi học.
Trong Ad-hoc testing tài liệu không phải là nhu cầu cần thiết. Đội QA tham gia vào quá trình kiểm tra mà không cần tài liệu đặc tả yêu cầu.	Trong Exploratory Testing tài liệu là bắt buộc. Để đảm bảo về chất lượng của dự án, tài liệu chi tiết của quá trình kiểm tra là cần thiết.
Ad-hoc nhắc đến sự hoàn hảo của hoạt động kiểm tra.	Exploratory Testing nhắc đến khảo sát hơn là về việc học tập của ứng dụng.
Việc thực thi quá trình kiểm tra được áp dụng trong Ad-hoc testing.	Mở rộng tình huống của Exploratory Testing sẽ giúp bạn có kiến thức sâu hơn về kết quả của quá trình kiểm tra.
Ad-hoc là công nghệ test của ứng dụng, nó cung cấp vai trò quan trọng trong việc sản xuất phần mềm.	Tester (QA) cần phải học một chức năng phần mềm đầu tiên. Exploratory Testing giúp bạn làm việc đó. Trước khi thực hiện kiểm tra các ứng dụng hoặc phần mềm các kỹ sư cần phải tìm hiểu nó thông qua Exploratory Testing.
Thử nghiệm này thực thi một lần duy nhất. Các kỹ sư kiểm thử nó một lần tại một thời điểm, tuy nhiên nếu có bất kỳ vấn đề gì tìm thấy trong quá trình test thì cần phải thực hiện lặp lại thao tác.	Đây là phương pháp thử nghiệm kết hợp các kết quả kiểm tra trong quá trình nghiên cứu và việc tạo ra một giải pháp mới.
Nó chủ yếu hoạt động trên các mối quan tâm về nghiệp vụ và làm gia tăng sự hiểu biết về các ứng dụng.	Nó phân loại các vấn đề và so sánh chúng từ các vấn đề được tìm thấy trong quá khứ. Điều này giúp làm giảm thời gian cho việc kiểm tra.
Ad-hoc testing giúp bạn tìm thấy ý tưởng sáng tạo từ các nghiên cứu.	Nó giúp phát triển các ứng dụng.
Ad-hoc Testing không quan trọng là cần phải chuyên gia về phần mềm thực thi nó.	Nó luôn luôn thực thi bởi Tester (QA) có kinh nghiệm.
Ad-hoc không cần quan tâm đến các trường hợp khó, mục đích của nó là để chạy các kết quả.	Luôn luôn có những tình huống khó khăn trong trường hợp kiểm tra. Exploratory Testing giúp cho việc sắp xếp nó.
Nó cần có sự chuẩn bị để bắt đầu và tiếp tục.	Exploratory Testing không cần thời gian bắt đầu.
Đây là phương thức thử nghiệm không chính thức.	Đây là nền tảng thử nghiệm chính thức.
Nó làm việc trên quá trình test phủ định là chủ yếu.	Quá trình kiểm tra này làm việc trên quá trình khẳng định.
Phương thức kiểm tra này chủ yếu là kết nối các hệ thống con với các ứng dụng và giúp cho việc tìm lỗ hổng khi hệ thống đang hoạt động.	Nó khám phá những yếu tố trong ứng dụng và tiến hành kiểm tra chúng bằng cách cung cấp một bản phác thảo.
Nó không làm việc theo luồng của hệ thống.	Exploratory testing làm việc theo luồng của hệ thống từ khi hoạt động kiểm tra được bắt đầu. Nó bắt đầu với đối tượng chính và thu thập đúng thông tin đúng về chúng.
Ad-hoc tập trung vào quá trình và kiểm tra ứng dụng nhiều lần.	Tập trung giới hạn trong lĩnh vực nhập dữ liệu, kiểm tra với giao diện.
Kết quả cuối cùng của Ad-hoc phụ thuộc vào đặc tả yêu cầu và cung cấp cho tester (QA) sự rung cảm lớn cho vấn đề ở hiện tại để kiểm tra một cách chính thức.	Sản phẩm cuối cùng được xác định dựa trên thuật toán và đặt nó trong file excel để sử dụng tiếp.

Có rất nhiều điểm tương đồng giữa Exploratory Testing và Ad-hoc testing. Điều đó gây cho con người cảm thấy lúng túng về chúng. Tuy nhiên cũng có rất nhiều những điểm khác nhau giữa chúng đó là mối quan tâm của các chuyên gia kiểm thử như những gì tôi đã trình bày ở trên.