Categories

Subscribe Now

* You will receive the latest news and updates on your favorite celebrities!

Automation Series

Ad-hoc Testing
Methods

Ad-hoc Testing 

Thuật ngữ Adhoc testing là phương pháp kiểm thử dạng Black box test mà không theo cách thông thường. Với quy trình test thông thường là phải có tài liệu yêu cầu, kế hoạch test ( test plan), testcase. Kiểu test này không theo bất cứ loại kỹ thuật test nào để tạo testcase.

Các tester thực hiện test ngẫu hứng ứng dụng mà không có bất kỳ testcase nào được viết ra cũng như bất kỳ một tài liệu mô tả bussiness nào dựa vào kiến thức sâu rộng về hệ thống và ứng dụng đang test. Mục đích chính là cố gắng tìm lỗi và những thiếu sót mà không được phát hiện ra theo cách test truyền thống, lỗi phát hiện sẽ không phải nằm trong testcase hay cũng không có trong document.

Đôi khi Adhoc testing có thể mix up giữa các kỹ thuật test thăm dò, phủ định, monkey testing, đoán lỗi. Trong đó kỹ thuật đoán lỗi có thể được thực hiện bởi người có đủ kinh nghiệm trong hệ thống và có thể đoán được hầu hết các nguồn của lỗi.

Khi nào thì nên thực hiện kiểm thử ad-hoc?

Thông thường Ad-hoc testing được thực hiện sau khi đã hoàn thành việc thực thi kiểm thử theo đúng quy trình. Nếu như có thời gian, thì có thể hoàn thành thực hiện Ad-hoc testing cho hệ thống. Nhưng cũng có thể thực hiện Ad-hoc testing khi cần thực hiện các kiểm thử phức tạp hoặc quá nhiều tính năng trong một khoảng thời gian giới hạn nào đó. Ad-hoc testing sẽ hiệu quả hơn nếu người thực thi kiểm thử có kiến thức tốt về hệ thống đó, một vòng kiểm thử ad-hoc có thể làm nên điều kỳ diệu với chất lượng sản phẩm và nâng cao nhiều câu hỏi thiết kế.

Vì ad-hoc testing là một kỹ thuật kiểm thử còn hoang dã không cần phải được cấu trúc, nên khuyến cáo chung là nên thực hiện sau khi thực hiện xong việc kiểm thử theo đúng quy trình hiện tại hoặc trong trường hợp khi không thể thực hiện kiểm tra chi tiết được do giới hạn thời gian.

Thử nghiệm ad-hoc có thể được thực hiện gần như bất cứ lúc nào – ngay từ đầu, về phía giữa hoặc cuối cùng. Tuy nhiên, khi kiểm thử ad-hoc phải được thực hiện để đưa ra giá trị tối đa được đánh giá tốt nhất bởi một tester có kinh nghiệm, những người có kiến thức chuyên sâu về hệ thống đang được thử nghiệm.

Các loại kiểm thử Ad-hoc

Kiểm thử Ad-hoc có thể được phân thành ba loại dưới đây:

1. Buddy testing:

Trong hình thức kiểm tra này, sẽ có một thành viên bên đội kiểm thử (QA) và một thành viên bên đội phát triển (dev) sẽ được chọn để làm việc trên cùng một mô-đun. Ngay sau khi dev hoàn thành Unit Test, tester và dev cùng ngồi làm việc để xác định các khuyết tật trong mô-đun đó. Loại thử nghiệm này cho phép xem xét tính năng trong phạm vi rộng hơn cho cả hai bên. Người phát triển (dev) sẽ hiểu được quan điểm test của Tester, nắm bắt tất cả các thử nghiệm khác nhau được chạy để có thể thay đổi thiết kế sớm trong trường hợp cần thiết; đồng thời Tester sẽ hiểu được thiết kế của modul, giúp họ tránh được việc thiết kế các kịch bản không hợp lệ, và phát triển các trường hợp thử nghiệm tốt hơn.

2. Pair testing:

Trong thử nghiệm này, hai Tester làm việc cùng nhau trên một mô-đun với cùng một thiết lập thử nghiệm được chia sẻ giữa họ. Ý tưởng đằng sau hình thức thử nghiệm này là để cả hai người cùng suy nghĩ đưa ra ý tưởng và phương pháp để tìm ra lỗi. Cả hai đều có thể chia sẻ công việc kiểm thử và tạo các tài liệu cần thiết cho tất cả các thứ quan sát được.

3. Monkey testing:

Kiểm tra ngẫu nhiên sản phẩm hoặc ứng dụng mà không có test cases với mục tiêu phá vỡ hệ thống. Thử nghiệm này chủ yếu được thực hiện ở cấp độ kiểm thử đơn vị. Tester phân tích dữ liệu hoặc kiểm tra theo cách hoàn toàn ngẫu nhiên để đảm bảo rằng hệ thống có thể chịu được mọi sự cố.

ƯU ĐIỂM

Giúp cho Tester tự do sáng tạo khi cần thiết. Điều này làm tăng chất lượng thử nghiệm và có các hiệu quả như:

  • Ưu điểm lớn nhất nổi bật là Tester có thể tìm thấy nhiều lỗi hơn so với chỉ kiểm thử truyền thống vì có thể áp dụng các phương pháp sáng tạo khác nhau để kiểm tra phần mềm.
  • Hình thức kiểm tra này có thể được áp dụng ở bất cứ đâu trong SDLC (vòng đời phát triển phần mềm); và không chỉ giới hạn trong đội kiểm thử. Đội phát triển cũng có thể tiến hành thử nghiệm này, điều này sẽ giúp họ viết mã tốt hơn và cũng dự đoán được vấn đề nào có thể xảy ra.
  • Có thể kết hợp với các loại kiểm thử khác để có được kết quả tốt nhất, đôi khi có thể giảm bớt thời gian cần thiết cho việc kiểm tra thường xuyên. Điều này có thể sẽ giúp nâng cao, cải thiện test cases, giúp tạo ra các trường hợp thử nghiệm tốt hơn và giúp chất lượng sản phẩm tốt hơn.
  • Không yêu cầu tạo bất kỳ tài liệu nào nên giúp giảm gánh nặng thêm cho Tester. Tester có thể tập trung vào việc thực sự hiểu được kiến trúc cơ bản.
  • Trong trường hợp không có nhiều thời gian để kiểm tra, phương pháp này rất có giá trị bao phủ phạm vi kiểm tra và chất lượng.

KHUYẾT ĐIỂM

Vì Ad-hoc không được tổ chức và không có tài liệu bắt buộc, nên người kiểm thử phải nhớ và hồi tưởng tất cả các chi tiết của các kịch bản Ad-hoc trong đầu. Điều này có thể còn khó khăn hơn, đặc biệt là trong các kịch bản có nhiều tương tác giữa các thành phần khác nhau.

  • Điều này sẽ có thể dẫn đến việc khó hoặc không thể tái hiện bug trong các lần thử tiếp theo nếu được yêu cầu cung cấp thông tin.
  • Một vấn đề quan trọng khác là trách nhiệm giải trình. Vì không được lên kế hoạch / cấu trúc, nên không có cách nào để tính toán thời gian và effort để đầu tư vào loại thử nghiệm này.
  • Kiểm thử Ad-hoc chỉ hiệu quả khi được thực hiện bởi một Tester rất am hiểu hệ thống và có tay nghề cao vì nó đòi hỏi sự chủ động và trực giác nhạy bén trong điều kiện tiên đoán các khu vực có khả năng có lỗi.

Các phương pháp

1. Xác định các khu vực dễ bị lỗi

Khi bạn nắm chắc việc thử nghiệm một phần mềm cụ thể, bạn sẽ đồng ý rằng sẽ có một số tính năng dễ bị lỗi hơn các tính năng khác. Nên tập trung vào các tính năng có logic/nghiệp vụ phức tạp, những tính năng chính quan trọng, những tính năng mà trước đó đã xảy ra nhiều lỗi … Áp dụng Ad-hoc Testing trong những trường hợp này có thể sẽ giúp tìm ra một số lỗi nghiêm trọng rất hiệu quả. Đặc biệt cần xác định các chức năng quan trọng chính của hệ thống, đây là đối tượng tập trung của Ad-hoc testing. Vì chức năng quan trọng chính là cái mà người dùng sẽ sử dụng và tương tác nhiều nhất, nếu mà để lọt bug trên đó thì sẽ là điều khó mà chấp nhận được.

2. Nắm chắc nghiệp vụ

Yếu tố then chốt quyết định phần lớn hiệu quả trong Ad-hoc Testing đó là việc người thực thi kiểm thử hiểu rõ nghiệp vụ của hệ thống đến đâu. Do đó, khi quyết định thực hiện Ad-hoc Testing thì cần phải chắc chắc được rằng bạn đã thông suốt về các ngõ ngách của hệ thống / ứng dụng. Điều này giúp bạn có thể dễ dàng thực hiện được những trường hợp thực tế nhất, trực quan hơn và có thể đoán được các vùng có khả năng xảy ra lỗi nhiều nhất.

3. Tạo danh mục test

Khi bạn đã biết danh sách các tính năng cần kiểm tra, hãy dành một vài phút để phân loại các tính năng đó và xác định cách kiểm tra. Ví dụ: bạn nên quyết định thử nghiệm các tính năng dễ thấy nhất và được sử dụng phổ biến nhất đầu tiên, vì điều này có vẻ quan trọng đối với sự thành công của phần mềm. Sau đó, phân loại chức năng / xác định thứ tự ưu tiên của chúng và thực hiện kiểm tra theo phân đoạn đã sắp xếp.

Chú ý quan trọng khác là nếu có sự tích hợp giữa các thành phần hoặc mô-đun. Trong những trường hợp này, có thể có rất nhiều bất thường có thể xảy ra. Sử dụng cách phân loại trên sẽ rất có ích cho việc kiểm tra.

4. Lập một bản kế hoạch thô

Điều này có thể gây chút nhầm lẫn hoặc khó hiểu vì như đã nói ở trên thì Ad-hoc Testing là thử nghiệm mà không cần lập kế hoạch hoặc tài liệu. Nhưng ý tưởng ở đây chỉ đơn giản là đôi khi bạn có thể không nhớ hết được tất cả các bài kiểm tra bạn dự định thực hiện. Vì vậy, ghi chúng lại sẽ đảm bảo bạn không bỏ lỡ bất cứ điều gì.

5. Lưu lại các defect

Tài liệu không cần phải chi tiết, chỉ là một lưu ý nhỏ để bạn tham khảo tất cả các kịch bản khác nhau được đề cập, độ lệch trong các bước liên quan và ghi lại các lỗi đó cho danh mục tính năng thử nghiệm cụ thể. Tất cả các lỗi tìm được từ Ad-hoc testing đều cần phải được lưu lại và gửi cho team dev để fix bug. Các lỗi hợp lệ cần được viết bổ sung và thêm vào trong bộ test case. Cái này thường là do viết test case thiếu, chưa bao phủ được các trường hợp. Các defect tìm được này chính là những bài học kinh nghiệm, cần phải được xem xét và đánh giá nghiêm túc, rút kinh nghiệm cho các vòng test sau hay những trường hợp, sản phẩm có tính năng tương tự.

Kết Luận

Mặc dù thực hiện Adhoc testing là hoàn toàn ngẫu hứng nhưng người thực hiện cần phải có đủ kiến thức cũng như kinh nghiệm để biết được các tình huống khác nhau có thể xảy ra với hệ thống hoặc ứng dụng hoặc game đang kiểm thử từ đó có thể phán đoán đâu là lỗi thật sự và đâu là hạn chế của hệ thống.

Related posts

Leave a Reply

Required fields are marked *

error: Content is protected !!