Exploratory testing và Ad-hoc testing

Bài viết được tìm hiểu thêm từ nguồn :

Nói về mảng Software testing, ngày hôm nay, tôi sẽ trình làng với những bạn về một phần rất mê hoặc đó là “ Exploratory Testing ” và “ Ad-hoc testing ”. Trong bài này, tôi đang có một thưởng thức quan trọng về cải tiến vượt bậc trong kiểm thử, ưu điểm, điểm yếu ké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 giải pháp này vào những bài tập cơ bản trong ngành kiểm thử trong thực tiễn .

Bạn đang xem : exploratory testing la gi

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 quy trình kiểm tra của phương pháp 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 những công dụng của ứng dụng một cách đúng chuẩn. Điều này rất hữu dụng cho tester ( QA ) để đưa ra quyết định hành động những gì hoàn toàn có thể được làm bên cạnh việc kiểm tra. Trong suốt quy trình kiểm tra tester ( QA ) cần tìm hiểu và khám phá về hành vi của những ứng dụng ứng dụng, khởi đầu tạo kế hoạch thử nghiệm hoặc ngữ cảnh 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 ” hoàn toàn có thể được sử dụng như để quản trị và thu âm “ Session-Based Testing ”. Việc tạo ra những ngữ cảnh kiểm thử là trọn vẹn dựa trên những kinh nghiệm tay nghề 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 cấp dưới kiểm thử. Việc tìm ra lỗi không riêng gì phụ thuộc vào trên kinh nghiệm tay nghề của nhân viên cấp dưới kiểm thử ( QA ) mà còn dựa trên kiến thức và kỹ năng .

Nhiều nhân viên cấp dưới kiểm thử đang nghĩ rằng loại test này cần đi kèm trong những hình ảnh, thế cho nên đây là điểm tất cả chúng ta cần sử dụng trong kỹ thuật test tò mò :

• 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ổng thể những điểm chính trong phương pháp kiểm tra thăm dò. Các bạn hãy giành thời hạn đọc kỹ nó nhé. Sau đây, tôi sẽ ra mắt về một phương pháp kiểm thử cũng không kém phần mê hoặc đó 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 triển khai hay không có cấu trúc nào cả. Trong một chú ý quan tâm tựa như 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 triển khai mà không theo bất kể một quá trình chính thức nào giống như tài liệu đặc tả nhu yếu, kế hoạch test, test case, … Tương tự như vậy trong khi triển khai ad-hoc testing không có quá trình kiểm thử chính thức cái mà hoàn toàn có thể được ghi nhận. Ad-hoc testing thường kết thúc để tò mò những yếu tố ( issues ) hoặc lỗi ( defects ) mà không hề được tìm thấy bằng quy trình test chính thức. Những nhân viên cấp dưới kiểm thử ( QA ) người triển khai quy trình kiểm thử này cần phải có kiến thức và kỹ năng rất tốt và có chiều sâu về mẫu sản phẩm hoặc ứng dụng. Khi nhân viên cấp dưới kiểm thử triển khai ad-hoc testing họ chỉ có dự tính phá vỡ mạng lưới hệ thống mà không theo bất kể tiến trình nào hoặc không có bất kể trường hợp đơn cử nào trong tâm lý họ .

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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à giờ đây, trong tâm lý của bạn sẽ có câu hỏi là khi nào tất cả chúng ta nên dùng giải pháp ad-hoc testing ? Để vấn đáp thắc mắc này bạn hoàn toàn có thể nói rằng ad-hoc testing hoàn toàn có thể triển khai tại bất kể thời gian nào mặc dầu đó là khởi đầu, giữa hay cuối của dự án Bất Động Sản. Hoạt động này chỉ được thực thi khi nhân viên cấp dưới kiểm thử ( QA ) đều có kỹ năng và kiến thức khá đầy đủ về loại sản phẩm. Hoạt động test này cũng hoàn toàn có thể được triển khai khi thời hạn là rất hạn chế và kiểm tra chi tiết cụ thể là thiết yếu .

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

Tham khảo thêm : GeForce Experience là gì ? Có tính năng gì và cách thiết lập thế nào ? – GEARVN.COM

Việc đưa ra quyết định hành động khi nào không thực thi ad-hoc testing là bởi kinh nghiệm tay nghề và kỹ năng và kiến thức của tester ( QA ). Mặc dù có một chút ít trường hợp không nên triển khai 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 triển khai 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ử những người chịu nghĩa vụ và trách nhiệm cho việc giao nhận từng module đơn cử. Trong loại test này nhân viên cấp dưới lập trình và nhân viên cấp dưới kiểm thử sẽ ngồi cũng nhau và thao tác trên một module đơn cử để tránh từ việc thiết kế xây dựng những ngữ cảnh không hợp lệ mà còn ở những mặt khác giúp những tester báo cáo giải trình những lỗi ( defects ) không hợp lệ .
• Pair testing : Loại test này được thực thi bởi 2 tester ngồi thao tác cùng với nhau trên cùng một module. Về cơ bản họ chia những ngữ cảnh testing giữa những module. Mục đích của những loại testing là đến với những ngữ cảnh kiểm thử tối đa để module của những thực thể triển khai xong mức độ bao trùm. Cũng hoàn toàn có thể tạo ngữ cảnh kiểm thử của tester ( QA ) và quan sát trong quy trình kiểm tra thực thể những module cùng với nhau .
• Monkey testing : Loại test này là quy trình triển khai kiểm tra ngẫu nhiên một vài tính năng trong quy trình test cho 1 số ít tài liệu ngẫu nhiên với mục tiêu phá vỡ mạng lưới 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ố ít 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à quyền lợi tương quan đến Ad-hoc testing :

1. Ad-hoc testing là việc test tự do để tester vận dụng những phương pháp 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 hoàn toàn có thể so với quy trình thử nghiệm chính thức .
2. Các loại test hoàn toàn có thể được thực thi bất kỳ khi nào nơi nào trong chu kỳ luân hồi tăng trưởng ứng dụng ( Software Development Life Cycle ( SDLC ) ) mà không theo bất kể qui trình chính thức nào .
3. Loại test này không riêng gì bị số lượng giới hạn quy trình test của một team mà nó còn hoàn toàn có thể được triển khai bởi nhân viên cấp dưới lập trình trong khi những module của họ đang được tăng trưởng điều đó giúp họ trong việc code bằng những giải pháp tốt nhất .
4. Ad-hoc testing đã được chứng tỏ là giải pháp mang lại nhiều quyền lợi khi mà người tester ( QA ) có ít thời hạn và chiều sâu cho hoạt động giải trí kiểm thử của một đặc tính được nhu yếu. Điều này có lợi trong việc phân phối những tính năng bảo vệ chất lượng và đúng thời hạn .
5. Ad-hoc testing hoàn toàn có thể thực thi đồng thời với những 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 chừng thời hạn ít hơn .
6. Tham khảo thêm : Nhận xét ux design là gì | Sen Tây Hồ

   Đố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

1. Kể từ khi ad-hoc testing được triển khai mà không có bất kể kế hoạch và không theo bất kể cấu trúc nào thế cho nên việc tái tạo lại lỗi ( bug ) đã trở thành một rắc rối lớn .
2. Kịch bản kiểm thử được triển khai trong suốt quy trình ad-hoc testing không có tài liệu để tester ( QA ) hoàn toàn có thể giữ tổng thể những ngữ cảnh trong tâm lý mà anh ấy / cô ấy hoàn toàn có thể không nhớ lại trong tương lai .
3. Ad-hoc testing nhờ vào rất nhiều vào kỹ năng và kiến thức của tester ( QA ) người có hiểu biết tổng lực về mẫu sản phẩm mà nó không hề được thực thi bởi một người mới tham gia vào dự án Bất Động Sả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 thi theo phương pháp thích hợp nó hoàn toàn có thể dẫn đến mất hàng loạt thời hạn và sức lực lao động. Dưới đây là một vài gợi ý cho tester ( QA ) để xác lập khoanh vùng phạm vi và phương pháp như thế nào để ứng dụng vào ad-hoc testing :

1. Kiến thức tốt về loại sản phẩm : Tester ( QA ) – những người thực thi ad-hoc testing cần có kiến thức và kỹ năng tốt về mẫu sản phẩm. Anh ta cần có hiểu biết tốt với tổng thể những đặc tính của loại 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 hoàn toàn có thể từ những khu vực dễ mắc lỗi ( defect ) nhất .
2. Độ ưu tiên những đặc tính Khi ad-hoc testing triển khai cho nhiều đặc tính thì thứ nhất những 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 người mua cần được kiểm tra tiên phong cho đến khi có một vài lỗi ( bug ) có độ ưu tiên sống sót trong mạng lưới hệ thống thì cần được báo cáo giải trình và sửa càng sớm càng tốt .
3. Lập kế hoạch sơ bộ : Mặc dù không có nhu yếu về bất kỳ tài liệu nào trong quy trình sử dụng phương pháp ad-hoc testing như đã nói ở trên nhưng có quan tâm một vài điểm trong suốt quy trình kiểm tra này là giúp tester ( QA ) nhớ tổng thể những trường hợp thử nghiệm hoàn toàn có thể xảy ra trong quy trình test. Điều này giúp cho việc tăng tối đa độ bao trùm trong thời hạn ít hơn .
4. 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 những bản log mà không được nhìn thấy trong giao diện người dùng hay cản trở quy 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ệ đó tất cả 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 hiển thị trách nhiệm .
5. Quan sát tài liệu Mặc dù quy trình kiểm tra sử dụng phương pháp ad-hoc testing không tương hỗ 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 đó tất cả chúng ta cần tạo những testcase tương quan, điều này giúp ích cho tester ( QA ) trong việc kiểm tra lại những ngữ cảnh trong tương lai .

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

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

Xem thêm : Sự khác nhau giữa GPT và MBR khi phân vùng ổ đĩa

Bạn thấy bài viết thế nào ?