Làm quen với Adhoc testing
Bài đăng này đã không được cập nhật trong 3 năm
Khái niệm
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.
Cách tiếp cận Adhoc testing
Không có một định nghĩa hay tiếp cận chính xác nào cho Adhoc testing. Vì đây là việc thực hiện kiểm thử ngẫu hứng. Nó phụ thuộc vào quan điểm, kinh nghiệm và cách suy nghĩ của người thực hiện kiểm thử trước một hệ thống, một ứng dụng hay một trò chơi. Các tester có kinh nghiệm có thể tìm ra nhiều lỗi nhất có thể dựa vào một số lưu ý sau:
- Tìm kiếm vùng có lỗi dựa vào khả năng phán đoán chức năng dễ xảy ra lỗi nhiều nhất hoặc dựa vào lịch sử lỗi.
- Sự liên kết giữa các module với nhau.
- Nhìn hệ thống và suy nghĩ xem mình có thể làm gì và làm như thế nào khi phát triển chức năng này từ đó sẽ biết được liệu có yêu cầu hay chức năng nào đó bị thiếu sót.
Làm quen với ví dụ Adhoc testing
Dưới đây là một ví dụ về cách chúng ta có thể thực hiện kiểm tra này khi nói đến giao diện người dùng Wizard. Hãy nói rằng bạn cần phải tạo ra một kế hoạch hay một khuôn mẫu cho một số loại công việc được thực hiện sử dụng giao diện người dùng Wizard. Wizard là một loạt các bảng trong đó có đầu vào của người dùng như tên, mô tả, vv. Với tiến trình Wizard: nói về một trong những tấm, dữ liệu người dùng là để được nhập vào trong đó bao gồm các hướng dẫn giao diện người dùng để đưa ra một hộp pop-up đó cho biết thêm các thông tin liên quan để hoàn tất wizard và triển khai / kích hoạt wizard.
Để test ứng dụng này tester đưa ra các trường hợp bất thường như
- Hoàn thành thành công wizard với các dữ liệu hợp lệ và tạo kế hoạch.
- Cancel Wizard giữa chừng.
- Chỉnh sửa một bản plan đã tạo thông qua Wizard.
- Xóa các bản kế hoạch đã tạo và xem rằng bản kế hoạch đó có thực sự xóa.
- Nhập giá trị negative vào wizard và xem error messagaes có được hiển thị.
Với ví dụ trên là một vài testcase cho kiểu test Adhoc testing có thể được thực hiện để phát hiện ra nhiều lỗi có thể:
-
Trong khi thêm dữ liệu negative, ký tự đặc biệt mà không được giới hạn để biết chúng có được xử lý đúng không. Ví dụ đôi khi Wizards không hạn chế dấu ngoặc nhọn { hoặc dấu ngoặc vuông [ nhưng trong những tình huống nhất định này có thể xung đột với mã dựa trên ngôn ngữ đó được viết, và gây ra hành vi rất không đáng tin cậy.
-
Cách test khác là đặc biệt đối với các cửa sổ pop up với. Một người sử dụng có thể khiến các cửa sổ pop up để khởi động và sau đó cố gắng bấm nút backspace trên bàn phím. Nhiều lần tôi đã quan sát thấy rằng làm như vậy, làm cho background của wizard hoàn toàn biến mất và toàn bộ dữ liệu người dùng đã được nhập vào cho đến thời điểm các cửa sổ pop-up đã được đưa ra, chúng đã bị mất hết.
Khi nào thì thực hiện Adhoc testing?
Kỹ thuật Adhoc testing được thực hiện kiểm thử khi thời gian test bị hạn chế mà vẫn phải đảm bảo việc test tỉ mỉ. Thông thường kỹ thuật Adhoc testing được thực hiện sau khi thực hiện test thông thường. Nếu thời gian cho phép, thì kỹ thuật adhoc testing sẽ được hoàn thành trong hệ thống. Việc thực hiện kỹ thuật Adhoc testing sẽ hiệu quả chỉ khi tester có thể hiểu biết hệ thống dưới việc kiểm thử.
Khi nào không nên thực hiện Adhoc testing?
Không khuyến khích thực hiện Adhoc testing khi:
- Khi việc test bị lỗi.
- Khi tài liệu là cần thiết.
- Khi có nhu cầu thực hiện việc re-test
- khi mà sửa chữa hoặc biện pháp khắc phục khác trong hệ thống.
Các dạng test của Adhoc testing
Có nhiều dạng khác nhau của kỹ thuật Adhoc testing được liệt kê ở dưới đây:
-
Buddy testing: Hai người cùng thực hiện công việc là tìm lỗi trên cùng một module. Thông thường thì 1 buddy sẽ là người thuộc team dev và người còn lại là của team test. Kỹ thuật buddy testing sẽ giúp cho tester khai thác phát triển testcase tốt hơn và team develop có thể cũng đưa ra các thay đổi design sớm. Kỹ thuật test này thông thường được thực hiện sau giai đoạn UT.
-
Pair testing: Hai tester được giao nhiệm vụ test các module, chia sẻ ý tưởng và công việc tren cùng thiết bị để tìm lỗi. Một người có thể thực hiện test và người còn lại có thể ghi lại các tìm kiếm. Vai trò của 2 người có thể là tester và một người đống vai trò thư ký trong khi thử nghiệm. Kỹ thuật buddy testing được kết hợp giai đoạn UT và ST lại với nhau cùng với bên phát triển và bên kiểm thử, tuy nhiên kỹ thuật Pair testing được thực hiện khi các tester có các level kiến thức khác nhau ( một người có kinh nghiệm test và một người không có kinh nghiệm test chia sẻ ý tưởng và quan điểm cho nhau)
-
Monkey testing: Random test một sản phẩm hoặc chương trình mà không có testcase với mục đích phá vỡ hệ thống.
Ưu điểm của Adhoc testing:
- Thích hợp cho tiến hành kiểm tra ngẫu nhiên và tiết kiệm chi phí trong giai đoạn đầu phát triển phần mềm.
- Tester có thể sở hữu nhiều thời gian hơn.
- Tester được cho phép nâng cao quy trình test.
- Giúp cải tiến hơn phương pháp test có kịch bản.
- Yêu cầu ít thời gian chuẩn bị.
- Đưa ra kết quả nhanh chóng.
Nhược điểm của Adhoc testing:
- Thiếu tài liệu
- Thiếu tính khả dụng của thông tin nhạy cảm của dự án.
- Tester không được báo trước những lỗi đã có trước.
- Không có tài liệu tham khảo để hướng dẫn cho tester.
- Không cung cấp thông tin về cách mà team test đã sử dụng thời gian đối với hoạt động test như nào.
- Yêu cầu kiểm tra trình độ và kỹ năng tester để thực hiện thêm thử nghiệm kiểm soát chất lượng dẫn đến tăng chi phí hoạt động.
- Vấn đề tiềm tàng có thể không bị phát hiện.
- Không thích hợp để thử nghiệm giai đoạn cuối cùng.
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.
Nguồn: https://intensetesting.wordpress.com/2014/03/13/ad-hoc-testing-and-its-best-practices/
All rights reserved
