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.
“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.
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á:
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”.
Ý 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ọ.
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.
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:
Về cơ bản có 3 loại ad-hoc testing. Chúng là:
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:
| Ad-hoc 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.
Nguồn: https://anhtester.com/blog/su-khac-nhau-giua-exploratory-testing-va-ad-hoc-testing-b422.html
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
