Kiểm thử phần mềm - Huyền thoại

Dưới đây là một số lầm tưởng phổ biến nhất về kiểm thử phần mềm.

Lầm tưởng 1: Thử nghiệm quá đắt

Reality- Có một câu nói rằng, trả ít hơn cho việc kiểm thử trong quá trình phát triển phần mềm hoặc trả nhiều hơn cho việc bảo trì hoặc sửa chữa sau này. Thử nghiệm sớm giúp tiết kiệm cả thời gian và chi phí về nhiều mặt, tuy nhiên, việc giảm chi phí mà không thử nghiệm có thể dẫn đến việc thiết kế ứng dụng phần mềm không phù hợp khiến sản phẩm trở nên vô dụng.

Lầm tưởng 2: Thử nghiệm tiêu tốn thời gian

Reality- Trong các giai đoạn SDLC, kiểm tra không bao giờ là một quá trình tốn thời gian. Tuy nhiên, chẩn đoán và sửa chữa các lỗi được xác định trong quá trình kiểm tra thích hợp là một hoạt động tốn nhiều thời gian nhưng hiệu quả.

Lầm tưởng 3: Chỉ những sản phẩm được phát triển đầy đủ mới được kiểm tra

Reality- Không nghi ngờ gì nữa, việc kiểm thử phụ thuộc vào mã nguồn nhưng việc xem xét các yêu cầu và phát triển các trường hợp kiểm thử là độc lập với mã đã phát triển. Tuy nhiên, cách tiếp cận lặp đi lặp lại hoặc tăng dần như một mô hình vòng đời phát triển có thể làm giảm sự phụ thuộc của việc kiểm thử vào phần mềm được phát triển đầy đủ.

Lầm tưởng 4: Có thể hoàn thành thử nghiệm

Reality- Nó trở thành một vấn đề khi khách hàng hoặc người kiểm tra nghĩ rằng việc kiểm tra hoàn chỉnh là có thể. Có thể nhóm đã kiểm tra tất cả các đường dẫn nhưng không bao giờ có thể xảy ra thử nghiệm hoàn chỉnh. Có thể có một số kịch bản không bao giờ được thực thi bởi nhóm kiểm thử hoặc khách hàng trong vòng đời phát triển phần mềm và có thể được thực hiện khi dự án đã được triển khai.

Lầm tưởng 5: Phần mềm được kiểm tra không có lỗi

Reality - Đây là một lầm tưởng rất phổ biến mà khách hàng, người quản lý dự án và nhóm quản lý tin tưởng. Không ai có thể khẳng định chắc chắn rằng một ứng dụng phần mềm là 100% không có lỗi ngay cả khi một người kiểm thử với kỹ năng kiểm thử tuyệt vời đã kiểm tra ứng dụng đó .

Lầm tưởng 6: Sai sót bị bỏ sót là do Người kiểm tra

Reality- Việc đổ lỗi cho người thử nghiệm đối với các lỗi vẫn còn trong ứng dụng không phải là một cách tiếp cận đúng đắn ngay cả khi đã thực hiện thử nghiệm. Huyền thoại này liên quan đến các Ràng buộc thay đổi về Thời gian, Chi phí và Yêu cầu. Tuy nhiên, chiến lược kiểm tra cũng có thể dẫn đến việc nhóm kiểm thử bỏ sót lỗi.

Quan niệm 7: Người kiểm tra chịu trách nhiệm về chất lượng sản phẩm

Reality- Một cách hiểu sai rất phổ biến rằng chỉ những người kiểm tra hoặc nhóm kiểm tra mới phải chịu trách nhiệm về chất lượng sản phẩm. Trách nhiệm của người kiểm thử bao gồm việc xác định lỗi cho các bên liên quan và sau đó họ sẽ quyết định xem họ sẽ sửa lỗi hay phát hành phần mềm. Việc phát hành phần mềm vào thời điểm đó gây áp lực nhiều hơn cho người kiểm tra, vì họ sẽ bị đổ lỗi cho bất kỳ lỗi nào.

Quan niệm 8: Tự động hóa kiểm tra nên được sử dụng bất cứ khi nào có thể để giảm thời gian

Reality- Đúng, đúng là Tự động hóa kiểm thử giảm thời gian kiểm thử, nhưng không thể bắt đầu tự động hóa kiểm thử bất cứ lúc nào trong quá trình phát triển phần mềm. Tự động kiểm tra nên được bắt đầu khi phần mềm đã được kiểm tra thủ công và ổn định ở một mức độ nào đó. Hơn nữa, tự động hóa thử nghiệm không bao giờ có thể được sử dụng nếu các yêu cầu liên tục thay đổi.

Lầm tưởng 9: Bất kỳ ai cũng có thể kiểm tra một ứng dụng phần mềm

Reality- Những người ngoài ngành CNTT nghĩ và thậm chí tin rằng ai cũng có thể kiểm thử một phần mềm và kiểm thử không phải là một công việc sáng tạo. Tuy nhiên những người thử nghiệm biết rất rõ rằng đây là một huyền thoại. Suy nghĩ về các tình huống thay thế, cố gắng phá hủy một phần mềm với mục đích khám phá các lỗi tiềm ẩn là điều không thể đối với người phát triển nó.

Lầm tưởng 10: Nhiệm vụ duy nhất của Tester là tìm ra lỗi

Reality- Tìm lỗi trong một phần mềm là nhiệm vụ của người kiểm thử, nhưng đồng thời họ cũng là chuyên gia miền của phần mềm cụ thể. Các nhà phát triển chỉ chịu trách nhiệm về thành phần hoặc khu vực cụ thể được giao cho họ nhưng người kiểm thử hiểu được hoạt động tổng thể của phần mềm, các yếu tố phụ thuộc là gì và tác động của một mô-đun này lên mô-đun khác.