Các nội dung sẽ có trong bài thi ISTQB Foundation (CTFL)
- Nhớ lại lý do viết test case dựa trên trực giác, kinh nghiệm và kiến thức về các lỗi phổ biến. (K1)
- So sánh kỹ thuật dựa trên kinh nghiệm với kỹ thuật kiểm tra dựa trên đặc điểm kỹ thuật. (K2)
Trong phần này, chúng ta sẽ xem xét hai kỹ thuật dựa trên kinh nghiệm, tại sao và khi nào chúng hữu ích cũng như cách chúng phù hợp với các kỹ thuật dựa trên đặc tả kỹ thuật.
Mặc dù đúng là kiểm thử phải nghiêm ngặt, kỹ lưỡng và có hệ thống, nhưng đây không phải là tất cả những gì cần kiểm thử. Có một vai trò nhất định đối với các kỹ thuật phi hệ thống, tức là các bài kiểm thử dựa trên kiến thức, kinh nghiệm, trí tưởng tượng và trực giác của con người. Lý do là một số lỗi khó tìm ra bằng cách sử dụng các phương pháp tiếp cận có hệ thống hơn, vì vậy một “thợ săn lỗi” (bug hunter) giỏi có thể rất sáng tạo trong việc tìm ra những lỗi khó nắm bắt đó.
Trong phần này, hãy tìm định nghĩa của các thuật ngữ: đoán lỗi (error guessing) và kiểm thử thăm dò (exploratory testing).
ĐOÁN LỖI (ERROR GUESSING)
Đoán lỗi là một kỹ thuật nên được sử dụng để bổ sung cho các kỹ thuật chính thức khác. Sự thành công của việc đoán lỗi phụ thuộc rất nhiều vào kỹ năng của người kiểm thử, vì những người kiểm thử giỏi biết nơi có nhiều khả năng xảy ra lỗi nhất. Một số người dường như giỏi kiểm thử bẩm sinh, cũng có những người kiểm thử giỏi vì họ có nhiều kinh nghiệm với tư cách là người kiểm thử hoặc họ đã làm việc với các hệ thống cụ thể và do đó có thể xác định được các điểm yếu của nó.
Đây là lý do tại sao một phương pháp (như phương pháp đoán lỗi) lại được sử dụng rất hiệu quả sau khi các kỹ thuật chính thức hơn đã được áp dụng ở một mức độ nào đó. Khi sử dụng các kỹ thuật chính thức hơn, người kiểm thử có khả năng hiểu rõ hơn về hệ thống, những gì nó làm và cách thức hoạt động của nó. Với sự hiểu biết tốt hơn này, người kiểm thử có thể sẽ giỏi hơn trong việc đoán những cách mà hệ thống có thể không hoạt động một cách bình thường.
Không có quy tắc đoán lỗi. Người kiểm thử được khuyến khích nghĩ đến những tình huống mà phần mềm có thể không đối phó được. Các điều kiện điển hình cần thử bao gồm phép chia cho số 0, đầu vào trống , tệp trống và loại dữ liệu sai (ví dụ: nhập ký tự chữ cái trong đó yêu cầu bắt buộc phải có ký tự số). Nếu bất kỳ ai nói về một hệ thống hoặc môi trường mà hệ thống đó vận hành rằng “Điều đó không bao giờ có thể xảy ra”, thì có thể nên kiểm thử điều kiện đó, vì những giả định như vậy về những gì sẽ xảy ra và sẽ không xảy ra trong môi trường sống thường rất phổ biến. Cách tiếp cận có cấu trúc đối với kỹ thuật đoán lỗi là liệt kê các lỗi hoặc lỗi có thể xảy ra và thiết kế các thử nghiệm cố gắng tạo ra chúng. Các danh sách lỗi (defect) và thất bại (failure) này có thể được xây dựng dựa trên kinh nghiệm của chính người kiểm thử hoặc của người khác, dữ liệu lỗi và thất bại có sẵn và từ kiến thức chung về lý do tại sao phần mềm bị lỗi.
Kiểm thử thăm dò
Kiểm thử thăm dò (Exploratory testing) là một cách tiếp cận thực hành (hands-on) trong đó người kiểm thử tham gia vào việc lập kế hoạch tối thiểu và thực hiện kiểm thử tối đa. Việc lập kế hoạch bao gồm việc tạo ra một điều lệ kiểm thử, một tuyên bố ngắn gọn về phạm vi của một nỗ lực kiểm thử trong khung thời gian ngắn (1 đến 2 giờ), cách tiếp cận mục tiêu có thể được sử dụng.
Các hoạt động thiết kế kiểm thử và thực hiện kiểm thử được thực hiện song song mà không cần ghi lại một cách chính thức các điều kiện kiểm thử, trường hợp kiểm thử hoặc tập lệnh kiểm thử (test scripts). Điều này không có nghĩa là các kỹ thuật kiểm thử chính thức khác sẽ không được sử dụng.
Ví dụ: người kiểm thử có thể quyết định sử dụng phân tích giá trị biên nhưng sẽ suy nghĩ kỹ và kiểm thử các giá trị biên quan trọng nhất mà không nhất thiết phải viết chúng ra. Một số ghi chú sẽ được viết trong phiên kiểm thử thăm dò để có thể tạo báo cáo sau đó.
Ghi nhật ký kiểm thử được thực hiện khi thực hiện kiểm thử, ghi lại các khía cạnh chính của những gì được kiểm thử, bất kỳ lỗi nào được tìm thấy và bất kỳ suy nghĩ nào về khả năng kiểm thử thêm. Một khía cạnh quan trọng của kiểm thử thăm dò là học tập: học hỏi của người kiểm thử về phần mềm, cách sử dụng, điểm mạnh và điểm yếu của nó. Như tên gọi của nó, kiểm thử thăm dò là thăm dò, tìm hiểu về phần mềm, nó làm gì, nó không làm gì, cái gì hoạt động và cái gì không hoạt động. Người kiểm thử liên tục đưa ra quyết định về những gì sẽ kiểm thử tiếp theo và dành thời gian (có giới hạn) như thế nào.
Đây là cách tiếp cận hữu ích nhất khi không có thông số kỹ thuật hoặc có ít thông số kỹ thuật và khi thời gian bị hạn chế nghiêm trọng. Nó cũng có thể dùng để bổ sung cho các kiểm thử khác, chính thức hơn, giúp thiết lập độ tin cậy cao hơn đối với phần mềm. Theo cách này, kiểm thử thăm dò có thể được sử dụng để kiểm tra quy trình kiểm thử chính thức, giúp đảm bảo rằng những khiếm khuyết nghiêm trọng nhất đã được tìm thấy.
Kiểm thử thăm dò được mô tả trong [Kaner, 2002] và [Copeland, 2003]. Các cách kiểm thử khác theo cách thăm dò (“các cuộc tấn công”) được mô tả trong [Whittaker, 2002].
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây
