Exploratory testing là gì
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ẽ ra mắt với chúng ta về 1 phần rất thú vị đó là “Exploratory Testing” và "Ad-hoc testing". Trong bài xích này, tôi đang có một trải nghiệm quan trọng đặc biệt về đột phá trong kiểm thử, ưu điểm, nhược điểm và làm nỗ lực nào để áp dụng nó vào kiểm thử thực thế. đông đảo mẹo này để giúp đỡ bạn làm cố kỉnh nào để hiểu với tiếp cận cách thức này vào các bài tập cơ phiên bản trong ngành kiểm demo thực tế.
Bạn đang xem: Exploratory testing là gì
1. Exploratory testing
Một câu hỏi trong ý nghĩ của nhân viên cấp dưới kiểm demo (QA) là “Software testing Exploratory testing là gì?”Như cái tên của nó đã cho là Exploratory testing là quy trình test ứng dụng mà không tồn tại kế hoạch và lịch trình sệt biệt. Đây là quá trình kiểm thử thông thường mà ko sử dụng bất kỳ bộ testcase nào cả hoặc là hầu hết tài liệu cho chiến lược test áp dụng của bạn. Xác định tính năng của áp dụng bằng việc tìm hiểu và học tập làm kiểm tra design, testcase và sử dụng thiết bị giả lập để triển khai test bọn chúng một cách xuất sắc nhất.
Định nghĩa “Exploratory testing”“Exploratory Testing là bí quyết tiếp cận quá trình test có thể chấp nhận được bạn vận dụng năng lực, khả năng và kỹ xảo của tín đồ kiểm demo (QA) một giải pháp hữu hiệu nhất”. Đầu tiên những nhân viên cấp dưới kiểm thử phần mềm (QA) yêu cầu hiểu về ứng dụng đó bằng việc tìm hiểu nó dựa vào sự gọi biết về việc chúng xẩy ra với các kịch bạn dạng kiểm demo nào. Sau đó bắt đầu quá trình kiểm tra thực tiễn của ứng dụng.
Trong quy trình kiểm tra của cách làm này tester (QA) bắt buộc làm nỗ lực tối thiểu để lập kế hoạch nhưng trong những khi thực thi buổi tối đa tester (QA) nên kiểm tra được các tác dụng của ứng dụng một cách thiết yếu xác. Điều này rất có ích cho tester (QA) để mang ra quyết định những gì hoàn toàn có thể được làm sát bên việc kiểm tra. Vào suốt quá trình kiểm tra tester (QA) cần mày mò về hành vi của các ứng dụng phần mềm, ban đầu tạo chiến lược thử nghiệm hoặc kịch bạn dạng kiểm thử. Bao hàm công nuốm thử nghiệm thăm dò không giống nhau trên thị trường. Trong những công cụ soát sổ đó là "Session Tester" rất có thể được áp dụng như để thống trị và thu âm “Session-Based Testing”. Việc tạo nên các kịch phiên bản kiểm test là hoàn toàn dựa bên trên những tay nghề và việc giao lưu và học hỏi ứng dụng ngoài bài toán test.
Loại kiểm tra này là bài toán test thốt nhiên của nhân viên kiểm thử. Việc đào bới tìm kiếm ra lỗi không chỉ nhờ vào trên kinh nghiệm của nhân viên cấp dưới kiểm demo (QA) nhưng mà còn dựa trên kỹ năng.
Nhiều nhân viên cấp dưới kiểm thử sẽ nghĩ rằng nhiều loại test này cần đi kèm theo trong các hình ảnh, bởi vậy đó là điểm chúng ta cần sử dụng trong kỹ thuật kiểm tra khám phá:
Khi ứng dụng của chúng ta không tài năng liệu sệt tả yêu cầu hoặc không có tài liệu cho vấn đề test (test plan, checklist, test case…) hoặc tài liệu là nhỏ.Khi bạn có nhu cầu hoàn thành các bước test của doanh nghiệp trong một khoảng thời hạn ngắn ngủi.Khi chúng ta 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 sẵn sàng cho quy trình test như thể việc bọn họ không tài năng liệu cho vận động kiểm thử.Thời gian trong quy trình test được tiết kiệm do toàn bộ các trọng trách test được thiết kế cùng một cơ hội như là quá trình test, kiến tạo kịch phiên bản kiểm test và triển khai các kịch phiên bản kiểm thử.Nhân viên kiểm demo (QA) bao gồm thể báo cáo nhiều sự việc do yêu cầu không vừa đủ hoặc tư liệu yêu ước còn thiếu.Nhược điểm:Vài vấn đề không thể được khai quật trong kiểu demo này.Có xem xét lại những kế hoạch kiểm soát và xây đắp testcase/kịch bạn dạng test trong khi quy trình test có xảy ra vấn đề.Những nhân viên kiểm demo (QA) cần được nhớ kịch bạn dạng test - phần đông gì mà lại anh ta đang thực hiện test bởi vì nếu bao gồm lỗi được tìm kiếm thấy, tester (QA) đang “report a bug” với các bước thích hợp để tái hiện lại nó, với những lỗi nặng nề tái hiện cần phải mô tả quá trình một cách tương thích để triển khai một cách đúng đắn lỗi mà lại anh ta đã report đặc biệt là với những lỗi new được search thấy.Tôi suy nghĩ rằng đông đảo điều nhưng tôi nói bên trên là toàn bộ các điểm chủ yếu trong phương thức khám nghiệm thăm dò. Chúng ta hãy giành thời hạn đọc kỹ nó nhé. Sau đây, tôi sẽ reviews về một cách thức kiểm thử cũng không hề kém phần thú vị đó là: “ad-hoc testing”.
2. Ad-hoc testing
Ý nghĩa của tự Ad-hoc là một chiếc gì này mà không theo vật dụng tự hoặc không có tổ chức hay là không có kết cấu nào cả. Vào một xem xét tương từ về thí nghiệm Ad-hoc không là gì nhưng nó là 1 trong loại kiểm thử hộp đen (Black box testing) hoặc soát sổ hành vi kia (Behavioural testing) được thực hiện mà không theo bất kể một tiến trình chính thức nào y như tài liệu sệt tả yêu thương cầu, chiến lược test, test case, … tương tự như như vậy vào khi tiến hành ad-hoc testing không tồn tại quy trình kiểm thử xác định cái mà rất có thể được ghi nhận.Ad-hoc testing thường xong để tò mò những vụ việc (issues ) hoặc lỗi (defects) mà cấp thiết được tra cứu thấy bằng quá trình test chính thức. Những nhân viên cấp dưới kiểm demo (QA) tín đồ thực hiện quá trình kiểm test này cần phải có con kiến thức tốt nhất và bao gồm chiều sâu về sản phẩm hoặc ứng dụng. Khi nhân viên cấp dưới kiểm thử tiến hành ad-hoc testing họ chỉ bao gồm ý định phá vỡ khối hệ thống mà không theo bất kỳ quy trình nào hoặc ko có bất kỳ trường hợp ví dụ nào trong tâm địa trí họ.
Và bây giờ, trong trái tim trí của các bạn sẽ có câu hỏi là lúc nào chúng ta đề xuất dùng cách thức ad-hoc testing?Để trả lời thắc mắc này bạn cũng có thể nói rằng ad-hoc testing rất có thể thực hiện tại tại ngẫu nhiên thời điểm nào mặc dù đó là bắt đầu, giữa tốt cuối của dự án. Vận động này chỉ được triển khai khi nhân viên cấp dưới kiểm test (QA) đều phải sở hữu kiến thức không thiếu thốn về sản phẩm. Chuyển động test này cũng hoàn toàn có thể được triển khai khi thời gian là rất giảm bớt và kiểm tra cụ thể là đề xuất thiết.
Ad-hoc testing tránh việc được triển khai khi nào?Việc đưa ra quyết định lúc nào không tiến hành ad-hoc testing là bởi tay nghề và tài năng của tester (QA). Tuy vậy có một không nhiều trường hợp không nên thực hiện ad-hoc testing:
Ad-hoc testing ko yêu ước khi nó sẽ tồn tại một lỗi trong demo case. Vào trường thích hợp đó, lỗi bắt buộc đượ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 ko nên thực hiện trong khi triển khai Beta testing của ứng dụng của khách hàng.Các các loại dùng trong ad-hoc testing là gì?Về cơ bản có 3 nhiều loại ad-hoc testing. Bọn chúng là:
Buddy testing: các loại test này được tiến hành bởi nhân viên cấp dưới lập trình và nhân viên cấp dưới kiểm thử phần nhiều người phụ trách cho bài toán giao thừa nhận từng module cụ thể. Trong một số 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à thao tác trên một module rõ ràng để tránh từ các việc xây dựng các kịch bạn dạng không đúng theo lệ nhiều hơn ở các mặt không giống giúp các tester report những lỗi (defects) không phù hợp lệ.
Pair testing: nhiều loại test này được triển khai bởi 2 tester ngồi thao tác làm việc cùng với nhau trên cùng một module. Về cơ bạn dạng họ chia các kịch bản testing giữa những module. Mục đích của những loại testing là mang lại với các kịch bạn dạng kiểm thử buổi tối đa để module của những thực thể ngừng mức độ bao phủ. Cũng hoàn toàn có thể tạo kịch bạn dạng kiểm test của tester (QA) với quan giáp trong quy trình kiểm tra thực thể các module với nhau.
Monkey testing: loại test này là quy trình thực hiện kiểm tra ngẫu nhiên một vài tính năng trong quy trình test cho một trong những dữ liệu tình cờ với mục tiêu phá vỡ vạc hệ thống. Quy trình kiểm tra này giúp công ty chúng tôi phát hiện nay ra một trong những lỗi (bug) mới, phần đông lỗi nhưng mà trước kia không bắt được.
Ưu điểm và công dụng của Ad-hoc testingDưới đó là một vài ưu điểm và công dụng liên quan mang đến Ad-hoc testing:
Ad-hoc testing là vấn đề test tự do để tester áp dụng những cách thức mới của riêng chúng ta trong bài toán test ứng dụng giúp chúng ta tìm ra các lỗi (defects) nhất có thể so với quy trình thử nghiệm bao gồm 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ỳ luân hồi phát triển phần mềm (Software Development Life Cycle (SDLC)) mà lại không theo ngẫu nhiên qui trình xác nhận nào.
Loại test này không chỉ là bị giới hạn quy trình test của một team mà lại nó còn hoàn toàn có thể được triển khai 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 này giúp họ trong bài toán code bằng những phương thức tốt nhất.
Ad-hoc testing vẫn được chứng minh là phương thức mang lại nhiều tiện ích khi mà fan tester (QA) bao gồm ít thời hạn và chiều sâu cho vận động kiểm test của một đặc tính được yêu thương cầu. Điều này có ích trong việc cung cấp các tính năng bảo đảm chất lượng với đúng thời hạn.
Ad-hoc testing rất có thể thực hiện đồng thời với các loại kiểm thử khác góp cho việc tìm nhiều lỗi (bug) hơn một trong những khoảng thời gian ít hơn.
Đối với một số loại test này tư liệu là không cần thiết mà tester (QA) đề xuất tập trung quá trình kiểm thử vào công năng của vận 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 testingKể từ lúc ad-hoc testing được tiến hành mà ko có bất kỳ kế hoạch và không theo bất kể cấu trúc nào bởi vì vậy bài toán tái chế tạo ra lại lỗi (bug) đang trở thành một rắc rối lớn.
Kịch bản kiểm test được tiến hành trong suốt quy trình ad-hoc testing không tài giỏi liệu nhằm tester (QA) hoàn toàn có thể giữ tất cả các kịch bạn dạng trong trung ương trí mà anh ấy/cô ấy rất có thể không nhớ lại vào tương lai.
Ad-hoc testing nhờ vào rất các vào kĩ năng của tester (QA) người dân có hiểu biết toàn vẹn về sản phẩm mà nó bắt buộc được thực hiện bởi một người mới thâm nhập vào dự án công trình của team.
Thực hành tốt nhất có thể trong khi thực hiện ad-hoc testingNếu ad-hoc testing ko được thực hiện theo phương thức thích vừa lòng nó rất có thể dẫn đến mất tổng thể thời gian với công sức. Dưới đây là một vài nhắc nhở cho tester (QA) để khẳng định phạm vi và cách thức như thế nào để vận dụng vào ad-hoc testing:
Kiến thức tốt về sản phẩm:Tester (QA) - hầu như người triển khai 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 xuất sắc với toàn bộ các công năng của sản phẩm. Điều này giúp tester (QA) trong vấn đề phản đoán lỗi (error) và tìm ra những lỗi nhất có thể từ những quanh vùng dễ mắc lỗi (defect) nhất.
Độ ưu tiên các đặc tínhKhi ad-hoc testing tiến hành cho nhiều đặc tính thì trước tiên những trường đúng theo kiểm thử rất cần được phân một số loại và ưu tiên. Rất nhiều đặc tính được áp dụng nhiều bởi quý khách cần được bình chọn đầu tiên cho đến khi gồm một vài ba lỗi (bug) tất cả độ ưu tiên lâu dài trong khối hệ thống thì buộc phải được báo cáo và sửa càng cấp tốc càng tốt.
Lập chiến lược sơ bộ:Mặc mặc dù không có nhu cầu về bất kể tài liệu nào trong quá trình sử dụng cách tiến hành ad-hoc testing như đã nói ở trên nhưng có chú ý một vài điểm trong suốt quy trình kiểm tra này là góp tester (QA) nhớ toàn bộ các trường vừa lòng thử nghiệm hoàn toàn có thể xảy ra trong quá trình test. Điều này giúp cho việc tăng buổi tối đa độ che phủ trong thời hạn ít hơn.
Cách sử dụng công cụĐôi khi trong những lúc kiểm tra bao gồm lỗi (bug) hoặc hầu như ngoại lệ được tra cứu 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 các loại lỗi (bug) đó yêu cầu để mức độ nghiêm trọng cao. Để bắt được hầu như lỗi (bug) hoặc hầu hết ngoại lệ đó chúng ta cần phải thực hiện công thay như dò lỗi (debuggers), công cụ đánh giá hoặc screen nhiệm vụ.
Quan tiếp giáp tài liệuMặc dù quá trình kiểm tra áp dụng phương thức ad-hoc testing không hỗ trợ tài liệu nhưng lại nó luôn luôn luôn tốt hơn nhằm viết một ghi chú gọn nhẹ về việc kiểm tra, phát hiện với độ xê dịch của bạn. Nếu lỗi (defect) được tìm kiếm thấy sau đó họ cần tạo các testcase liên quan, vấn đề này giúp ích mang đến tester (QA) trong việc kiểm tra lại những 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 cùng Exploratory testing nhé
| Ad-hoc testing ban đầu với câu hỏi học vận dụng và sau đó làm câu hỏi với quy 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 quy trình kiểm tra nhưng mà không đề nghị tài liệu sệt tả yêu thương cầu. | Trong Exploratory Testing tư liệu là bắt buộc. Để bảo đảm an toàn về unique của dự án, tài liệu chi tiết của quá trình kiểm tra là cần thiết. Xem thêm: Lịch Sử 7 Bài 14 Phần 2 |
| Ad-hoc nhắc đến sự tuyệt vời và hoàn hảo nhất của hoạt động kiểm tra. | Exploratory Testing nhắc đến điều tra 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 vận dụng trong Ad-hoc testing. | Mở rộng trường hợp của Exploratory Testing sẽ giúp bạn có kỹ năng và kiến thức sâu rộng về công dụng của quy trình kiểm tra. |
| Ad-hoc là công nghệ test của ứng dụng, nó cung cấp vai trò đặc trưng trong vấn đề sản xuất phần mềm. | Tester (QA) cần được học một chức năng phần mềm đầu tiên. Exploratory Testing giúp bạn làm bài toán đó. Trước khi thực hiện kiểm tra những ứng dụng hoặc ứng dụng các kỹ sư phải phải khám phá nó trải qua Exploratory Testing. |
| Thử nghiệm này triển khai một lần duy nhất. Các kỹ sư kiểm thử nó một đợt tại 1 thời điểm, tuy vậy nếu có ngẫu nhiên vấn đề gì tra cứu thấy trong quá trình test thì nên phải thực hiện lặp lại thao tác. | Đây là phương thức thử nghiệm phối kết hợp các hiệu quả kiểm tra trong quá trình phân tích và việc tạo ra một giải pháp mới. |
| Nó chủ yếu hoạt động trên những mối ân cần về nhiệm vụ và làm gia tăng sự phát âm biết về những ứng dụng. | Nó phân loại các vấn đề và đối chiếu chúng từ những vấn đề được tra cứu thấy trong quá khứ. Điều này giúp làm cho 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 chế từ các nghiên cứu. | Nó giúp cải tiến và phát triển các ứng dụng. |
| Ad-hoc Testing không đặc biệt là buộc phải phải chuyên viên về ứng dụng thực thi nó. | Nó luôn luôn luôn triển khai bởi Tester (QA) bao gồm kinh nghiệm. |
| Ad-hoc không cần xem xét các trường đúng theo khó, mục đích của nó là nhằm chạy các kết quả. | Luôn luôn có những trường hợp khó khăn trong trường đúng theo kiểm tra. Exploratory Testing hỗ trợ cho việc thu xếp nó. |
| Nó cần phải có sự sẵn sàng để bước đầu và tiếp tục. | Exploratory Testing ko cần thời gian bắt đầu. |
| Đây là cách thức thử nghiệm không chủ yếu thức. | Đây là nền tảng thử nghiệm bao gồm thức. |
| Nó thao tác làm việc trên quá trình test tủ định là chủ yếu. | Quá trình kiểm soát này làm việc trên quy trình khẳng định. |
| Phương thức khám nghiệm này đa phần là kết nối các khối hệ thống con với các ứng dụng cùng giúp cho việc tìm và đào bới lỗ hổng khi hệ thống đang hoạt động. | Nó mày mò những nguyên tố trong vận dụng và thực hiện kiểm tra chúng bằng phương pháp cung cấp cho một phiên bản phác thảo. |
| Nó không thao tác theo luồng của hệ thống. | Exploratory testing thao tác làm việc theo luồng của hệ thống từ khi chuyển động kiểm tra được bắt đầu. Nó bước đầ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 quy trình và kiểm tra ứng dụng nhiều lần. | Tập trung giới hạn trong nghành nhập dữ liệu, khám nghiệm với giao diện. |
| Kết quả cuối cùng của Ad-hoc dựa vào vào sệt tả yêu mong và cung cấp cho tester (QA) sự rung cảm lớn cho vụ việc ở hiện tại để khám nghiệm một cách bao gồm 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 tệp tin excel để thực hiện tiếp. Xem thêm: Visual Brand Identity Là Gì ? Bộ Nhận Diện Thương Hiệu Bao Gồm Những Gì |
Có không hề ít điểm tương đương giữa Exploratory Testing với Ad-hoc testing. Điều kia gây mang đến con người cảm thấy lo âu về chúng. Tuy nhiên cũng có không ít những điểm không giống nhau giữa chúng chính là mối thân thiện của các chuyên gia kiểm thử giống như những gì tôi đã trình diễn ở trên.