Ad-hoc Testing: làm thế nào để phát hiện ra bug mà không có quy trình kiểm thử chính thức

1. Khái niệm

Thuật ngữ ad-hoc ngụ ý sự thiếu vắng cấu trúc hoặc cái gì đó không có phương pháp. Khi bạn nói về thử nghiệm ad hoc , nó có nghĩa là nó là một phương thức kiểm thử hộp đen hoặc thực hiện kiểm thử mà không theo bất kỳ quy trình chính thức nào.

Quy trình chính thức ở đây có nghĩa là có các tài liệu như các tài liệu yêu cầu, kế hoạch kiểm thử, các trường hợp thử nghiệm(TCs) được thực hiện. Ngoài ra, bất kỳ hành động nào được thực hiện trong quá trình kiểm thử thường không được ghi lại.

Thử nghiệm được thực hiện với sự hiểu biết của người kiểm tra về ứng dụng và kiểm tra thử nghiệm ngẫu nhiên mà không tuân theo các yêu cầu / yêu cầu. Do đó thành công của thử nghiệm Adhoc phụ thuộc vào khả năng của người kiểm tra, người thực hiện kiểm tra. Người kiểm tra phải tìm ra các khiếm khuyết mà không có kế hoạch và tài liệu phù hợp, chỉ dựa trên trực giác của người kiểm tra.

2. Khi nào để Thực hiện kiểm tra Adhoc?

Thử nghiệm Adhoc có thể được thực hiện khi có giới hạn thời gian để thự hiện kiểm thử đầy đủ và thường được thực hiện sau khi thực hiện kiểm tra chính thức. Thử nghiệm Adhoc sẽ chỉ có hiệu quả nếu người kiểm tra có sự hiểu biết sâu về hệ thống cần kiểm thử.

Các loại thử nghiệm Ad-hoc:

2.1 Buddy Testing:

Hai thành viên, một người từ nhóm phát triển và một nhóm kiểm tra cùng nhau làm việc để xác định các khuyết tật trong cùng một mô-đun. Kiểm tra Buddy giúp người kiểm tra phát triển các trường hợp thử nghiệm tốt hơn trong khi đội phát triển cũng có thể thay đổi thiết kế sớm. Loại thử nghiệm này thường xảy ra sau khi hoàn thành kiểm tra đơn vị (unit test).

2.2 Pair Testing

Hai người kiểm tra được gán các mô-đun tương tự và họ chia sẻ ý tưởng và làm việc trên cùng một hệ thống để tìm các khuyết tật. Một người kiểm tra thực hiện các bài kiểm tra trong khi một người kiểm tra khác ghi lại các ghi chú về những phát hiện của họ.

2.3 Monkey Testing

Thử nghiệm này chủ yếu được thực hiện ở mức độ kiểm tra đơn vị. Người kiểm tra phân tích dữ liệu hoặc kiểm tra một cách hoàn toàn ngẫu nhiên để đảm bảo rằng hệ thống có thể chịu được bất kỳ tai nạn.

3. Các cách khác nhau để thử nghiệm Adhoc hiệu quả hơn

1. Xác định các khu vực dễ bị xuất hiện lỗi:

Khi tiến hành thực hiện kiểm tra một phần cụ thể của phần mềm, bạn sẽ nhận thấy có một số tính năng có nhiều dễ bị lỗi hơn những tính năng khác. Số lượng khiếm khuyết nhiều hơn trong một tính năng cụ thể sẽ cho bạn thấy rằng nó nhạy cảm và bạn nên chọn chính xác khu vực đó để thực hiện thử nghiệm ad hoc. Điều này chứng tỏ là một cách sử dụng rất hiệu quả thời gian để tìm kiếm một số mỗi nghiêm trọng trong phần mềm.

2. Xây dựng chuyên môn:

Chắc chắn, một người thử nghiệm có nhiều kinh nghiệm trực quan hơn và có thể đoán nơi lỗi có thể xảy ra, khi so sánh với người không có nhiều kinh nghiệm. Tôi có thể nói, có kinh nghiệm hay không, nó phụ thuộc vào cá nhân để có sự tích lũy và xây dựng chuyên môn về hệ thống đang được thử nghiệm. Những người thử nghiệm có kinh nghiệm có nhiều ưu thế hơn vì kỹ năng của họ được xây dựng trong những năm qua rất tiện dụng, nhưng những người thử nghiệm mới nên sử dụng nó làm nền tảng để có được kiến thức càng nhiều càng tốt để thiết kế các kịch bản kiểm thử tốt hơn.

3. Tạo các danh mục thử nghiệm:

Một khi bạn đã nhận thức được danh sách các tính năng sẽ được kiểm tra, dành một vài phút để quyết định cách bạn phân loại các tính năng đó và thử nghiệm. Ví dụ: bạn nên quyết định thử nghiệm các tính năng được nhìn thấy rõ nhất và thường được sử dụng bởi người dùng trước bất cứ điều gì khác, 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 đó, bạn có thể phân loại họ chức năng / ưu tiên khôn ngoan và thử nghiệm chúng phân khúc theo phân đoạn.

Một ví dụ khác mà điều này đặc biệt quan trọng 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 phân loại sẽ giúp liên lạc với các loại kiểm tra này ít nhất một lần hoặc hai lần.

4. Có kế hoạch sơ bộ:

Điểm này có thể gây nhầm lẫn cho bạn một chút vì chúng tôi đã miêu tả các thử nghiệm ad-hoc như là thử nghiệm nên không có kế hoạch hoặc tài liệu. Ý tưởng ở đây là gắn bó với bản chất của thử nghiệm ad hoc, nhưng vẫn có một số gợi ý về cách bạn dự định thử nghiệm.

Một ví dụ rất cơ bản là đôi khi bạn chỉ có thể không thể nhớ 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. Công cụ:

Khuyết tật cũng có thể được đưa đến ánh sáng vôi bằng cách sử dụng các trình hồ sơ, trình gỡ lỗi và thậm chí là các màn hình nhiệm vụ. Do đó, thông thạo trong việc sử dụng các công cụ này có thể phát hiện ra một số khuyết tật

6. Ghi lại các kết quả

Mặc dù việc kiểm tra được thực hiện ngẫu nhiên, tốt hơn là ghi lại các bài kiểm tra nếu thời gian cho phép và lưu ý độ lệch nếu có. Nếu các khuyết tật được tìm thấy, các trường hợp thử nghiệm tương ứng được tạo ra để giúp người kiểm tra thử lại kịch bản.

4. Lợi ích của việc sử dụng Ad-hoc testing

• Ưu điểm lớn nhất nổi bật là người kiểm tra có thể tìm thấy nhiều lỗi hơn so với thử nghiệm truyền thống vì có nhiều phương pháp sáng tạo mà họ có thể áp dụng để kiểm tra phần mềm.

• Mẫu thử nghiệm này có thể được áp dụng ở bất cứ nơi nào trong SDLC; nó không chỉ giới hạn trong đội thử nghiệm. Các nhà phát triển cũng có thể tiến hành kiểm tra này, giúp họ mã số tốt hơn và cũng có thể dự đoán những vấn đề có thể xảy ra.

• Có thể được kết hợp với các thử nghiệm khác để có được kết quả tốt nhất mà đôi khi có thể cắt ngắn thời gian cần thiết cho việc kiểm tra thường xuyên. Điều này sẽ cho phép tạo ra các vụ thử nghiệm chất lượng tốt hơn và chất lượng sản phẩm tốt hơn trên toàn bộ.

• Không ủy thác bất kỳ tài liệu nào được thực hiện để ngăn ngừa thêm gánh nặng cho người kiểm tra. Người kiểm tra có thể tập trung vào sự hiểu biết thực sự kiến trúc bên dưới.

• Trong những trường hợp không có nhiều thời gian để kiểm tra, điều này có thể chứng minh được rất có giá trị về độ phủ sóng và chất lượng thử nghiệm.

5. Hạn chế của Ad-hoc testing

Vì nó không được tổ chức và không có tài liệu hướng dẫn, vấn đề hiển nhiên nhất là người kiểm tra phải nhớ và nhớ lại tất cả các chi tiết của các kịch bản thử nghiệm trong bộ nhớ. Điều này có thể gặp nhiều thách thức hơn nữa trong các kịch bản khi có rất nhiều sự tương tác giữa các thành phần khác nhau

• Tiếp theo từ điểm đầu tiên, điều này cũng sẽ dẫn đến việc không thể tạo lại các khuyết tật trong các lần thử tiếp theo, nếu được yêu cầu cung cấp thông tin.

• Một câu hỏi rất quan trọng khác đưa ra ánh sáng là trách nhiệm giải trình. Vì đây không phải là kế hoạch / cấu trúc, không có cách nào để tính toán thời gian và nỗ lực đầu tư vào loại thử nghiệm này.

• Thử nghiệm Ad-hoc chỉ được thực hiện bởi một người kiểm tra rất có kinh nghiệm và có tay nghề cao trong nhóm vì nó đòi hỏi phải có tính chủ động và trực giác để dự đoán các khu vực có khả năng bị khiếm khuyết tiềm ẩn.

6. Kết luận

Ad-hoc testing là một kỹ thuật kiểm tra đảm bảo để phục vụ và đáp ứng sự sáng tạo của người thử nghiệm đến mức tối đa. Kết hợp phù hợp ad-hoc testing với các hình thức thử nghiệm khác có thể sẽ nâng cao chất lượng phầm mềm lên mức cao hơn.

nguồn tham khảo: https://www.guru99.com/adhoc-testing.html http://toolsqa.com/software-testing/adhoc-testing/