Hôm nay mình xin chia sẻ với mọi người 7 nguyên tắc cơ bản trong Kiểm Thử Phần Mềm. Mỗi Tester và chuyên gia QA nên biết đến các nguyên tắc này để đạt được kết quả tốt nhất.
Dưới đây là 7 nguyên tắc:
Kiểm thử toàn bộ là điều không thể
Kiểm thử mọi thứ là không thực hiện được, trừ khi nó chỉ bao gồm một số trường hợp bình thường. Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên mức độ ưu tiên để tập trung nỗ lực kiểm thử vào một số điểm cần thiết.
Và câu hỏi đáng giá triệu đô la là, làm thế nào để bạn xác định rủi ro này?
Theo bạn, thao tác nào có khả năng khiến hệ điều hành của bạn bị lỗi?
Tôi chắc chắn rằng hầu hết các bạn sẽ đoán, mở tất cả 10 ứng dụng khác nhau cùng một lúc.
Vì vậy, nếu bạn đang thử nghiệm Hệ điều hành này, bạn sẽ nhận ra rằng các lỗi có thể được tìm thấy trong hoạt động đa tác vụ và cần phải được kiểm tra kỹ lưỡng. Điều này đưa chúng ta đến nguyên tắc tiếp theo Defect Clustering.
Defect Clustering
Defect Clustering trong đó tuyên bố rằng một số lượng nhỏ các mô-đun chứa hầu hết các lỗi được phát hiện. Đây là ứng dụng của nguyên tắc Pareto để kiểm tra phần mềm: khoảng 80% các vấn đề được tìm thấy trong 20% các mô-đun.
Bằng kinh nghiệm, bạn có thể xác định các mô-đun rủi ro như vậy. Nhưng phương pháp này có vấn đề riêng của nó.
Nếu các thử nghiệm tương tự được lặp đi lặp lại nhiều lần, cuối cùng các trường hợp thử nghiệm tương tự sẽ không còn tìm thấy các lỗi mới.
Nghịch lý thuốc trừ sâu
Việc sử dụng lặp đi lặp lại cùng một loại thuốc trừ sâu để diệt côn trùng trong quá trình trồng trọ theo thời gian dẫn đến việc côn trùng phát triển tính kháng thuốc trừ sâu. Do đó, thuốc trừ sâu trên côn trùng sẽ không còn hiệu quả. Điều tương tự cũng áp dụng cho kiểm thử phần mềm. Nếu cùng một bộ các thử nghiệm lặp đi lặp lại được thực hiện, phương pháp sẽ vô dụng để phát hiện ra các khiếm khuyết mới.
Để khắc phục điều này, các trường hợp thử nghiệm cần phải được xem xét & sửa đổi thường xuyên, thêm các trường hợp thử nghiệm mới & khác nhau để giúp tìm ra nhiều khiếm khuyết hơn.
Các Tester không thể đơn giản phụ thuộc vào các kỹ thuật kiểm tra hiện có. Họ phải nhìn ra liên tục để cải thiện các phương pháp hiện có để làm cho thử nghiệm hiệu quả hơn. Nhưng dù có cố gắng và vất vả đến mấy, bạn cũng không bao giờ có thể khẳng định sản phẩm của mình không có lỗi. Để làm rõ về quan điểm này, chúng ta hãy xem video trình làng Windows 98 của Microsoft.
Bạn nghĩ rằng một công ty như Microsoft sẽ không kiểm tra hệ điều hành của họ một cách kỹ lưỡng và sẽ mạo hiểm danh tiếng của họ chỉ để thấy hệ điều hành của họ bị sập trong khi ra mắt công khai!
Kiểm thử chứng minh sự hiện diện của lỗi
Do đó, nguyên tắc kiểm thử nói rằng — Kiểm thử nói về sự hiện diện của lỗi và không nói về sự thiếu vắng của lỗi trong phần mềm. Tức là Kiểm thử phần mềm làm giảm xác suất lỗi chưa được phát hiện trong phần mềm nhưng ngay cả khi không tìm thấy lỗi, đó không phải là bằng chứng về tính chính xác.
Nhưng nếu, bạn làm việc chăm chỉ hơn, thực hiện mọi biện pháp đề phòng và làm cho sản phẩm phần mềm của bạn không có lỗi 99%. Và phần mềm không đáp ứng nhu cầu & yêu cầu của khách hàng.
Điều này dẫn chúng ta đến nguyên tắc tiếp theo, trong đó nêu rõ rằng — Sự thiếu vắng của Error.
Quan niệm sai lầm về việc “hết lỗi”
Có thể phần mềm không có lỗi 99% vẫn không sử dụng được. Đây có thể là trường hợp nếu hệ thống được kiểm tra kỹ lưỡng cho các yêu cầu sai. Kiểm thử phần mềm không chỉ đơn thuần là tìm lỗi, mà còn để kiểm tra xem phần mềm có đáp ứng nhu cầu business không. Sự vắng mặt của Error là sai lầm, tức là việc tìm và sửa lỗi không giúp ích gì nếu việc xây dựng hệ thống không sử dụng được và không đáp ứng nhu cầu & yêu cầu của người dùng.
Để giải quyết vấn đề này, nguyên tắc kiểm thử tiếp theo đã được nêu rõ.
Kiểm thử càng sớm càng tốt
Kiểm thử sớm — Kiểm thử nên bắt đầu sớm nhất có thể trong vòng đời phát triển phần mềm. Vì vậy, bất kỳ khiếm khuyết trong các yêu cầu hoặc giai đoạn thiết kế được nắm bắt trong giai đoạn đầu. Nó ít tốn kém hơn nhiều để sửa một khiếm khuyết trong giai đoạn đầu của kiểm thử. Nhưng làm thế nào để sớm nên bắt đầu việc kiểm thử? Bạn nên bắt đầu tìm lỗi ngay khi yêu cầu được xác định.
Kiểm thử phụ thuộc vào ngữ cảnh
Kiểm thử phụ thuộc vào ngữ cảnh, về cơ bản có nghĩa là cách bạn kiểm thử trang web thương mại điện tử sẽ khác với cách bạn kiểm thử COTS. Tất cả các phần mềm được phát triển không giống nhau. Bạn có thể sử dụng một cách tiếp cận, phương pháp, kỹ thuật và loại thử nghiệm khác nhau tùy thuộc vào loại ứng dụng. Một ví dụ về kiểm thử, bất kỳ hệ thống POS nào tại cửa hàng bán lẻ sẽ khác với việc thử nghiệm máy ATM.
Quan niệm:
“Nguyên tắc chỉ mang tính tham khảo. Tôi sẽ không sử dụng chúng trong thực tế.”
Điều này là sai sự thật. Nguyên tắc kiểm thử sẽ giúp bạn tạo strategy kiểm tra hiệu quả và dự thảo các trường hợp kiểm tra lỗi.
Nhưng học các nguyên tắc kiểm tra cũng giống như học lái xe lần đầu tiên.
Ban đầu, trong khi bạn học lái xe, bạn chú ý đến từng thứ và mọi thứ như sang số, tốc độ, xử lý ly hợp, v.v. Nhưng với kinh nghiệm, bạn chỉ tập trung vào việc lái phần còn lại một cách tự nhiên. Như vậy, bạn thậm chí còn nói chuyện với các người khác trong lúc lái.
Điều tương tự cũng đúng cho các nguyên tắc testing. Những testers có kinh nghiệm đã nội tâm hóa những nguyên tắc này đến một mức độ mà họ áp dụng chúng ngay cả khi không cần suy nghĩ. Do đó, câu chuyện cho rằng các nguyên tắc không được sử dụng trong thực tế đơn giản là không đúng.
Xem thêm
- Hướng dẫn sửa lỗi không tắt hoặc khởi động lại được Ubuntu – Ubuntu can’t shutdown restart
- Hướng dẫn cài bộ gõ tiếng Việt ibus-unikey trên Ubuntu
- Lộ trình học PHP từ cơ bản đến nâng cao chuyên nghiệp
- Hướng dẫn viết một Extension cơ bản trên Chrome
- 8 điểm so sánh giữa MySQL và PostgreSQL để lựa chọn sử dụng phù hợp
- Bài 1: XML là gì? Tổng quan về XML
- Top 5 giải pháp làm việc hiệu quả tại nhà
- Vai trò Apache và PHP Hoạt Động Cùng Nhau Như Thế Nào