Những lầm tưởng về nghề kiểm thử phần mềm

Lầm tưởng 1:Việc kiểm thử tốn nhiều chi phí

Thực tế : Chi phí cho kiểm thử, trong thực tế khi phát triển phần mêm đôi khi chúng ta phải cân nhắc giữa việc chi phí ít cho kiểm trong quá trình phát triển hoặc là phải trả nhiều cho việc bảo trì và sửa chữa sau đó. Việc kiểm thử sớm sẽ giúp tiết kiệm thời gian cũng như tiền bạc trong nhiều khía cạnh, tuy nhiên giảm chi phí mà ko bao gồm kiểm thử có thể sẽ là nguyên nhân dẫn đến thiết kế ra sản phẩm phần mềm sai và không hữu dụng.

Lầm tưởng 2: Kiểm thử tốn thời gian

Thực tế:Trong suốt vòng đời phát triển của 1 sản phảm, kiểm thử không bao giờ là phí phạm. Tuy nhiên phân tích và sửa lỗi được xác định trong quá trình kiểm thử sẽ gây tốn thời gian nhưng rất hiệu quả

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

Thực tế: Không nghi ngờ, kiểm thử phụ thuộc vào mã nguồn nhưng việc xem xét tài liệu và phát triển test case độc lập không phụ thuộc vào công việc lập trình.Tuy nhiên phương pháp lặp đi lặp lại hoặc gia tăng như là một mô hình vòng đời phát triển có thể làm giảm sự phụ thuộc của thử nghiệm trên phần mềm phát triển đầy đủ.Hiện phương pháp lặp đi lặp lại hoặc gia tăng như là một mô hình vòng đời phát triển có thể làm giảm sự phụ thuộc của thử nghiệm trên phần mềm phát triển đầy đủ.

Lầm tưởng 4: sản phẩm đã được kiểm thử hoàn hảo

Thực tế: Việc kiểm thử là một vấn đề khi khách hàng hoặc người kiểm thử phần mềm nghĩ rằng chương trình được kiểm thử hoàn hảo. Chúng ta có thể test tất cả những thành phần bằng nhiều cách thức nhưng việc kiểm thử sẽ không bao giờ đạt đến sự hoàn hảo tuyệt đối.Có thể có một số tình huống mà không bao giờ được thực hiện bởi đội ngũ kiểm thử phần mềm hoặc khách hàng trong suốt vòng đời phần mềm phát triển và có thể được thực hiện khi dự án đã được triển khai.

Lầm tưởng 5: Một phần mềm đã được test là không có bug.

Thực tế: Đây là lầm tưởng rất phổ biến của khách hàng, quản lý dự án. Không ai có thể khẳng định một cách chắc chắn tuyệt đối rằng một ứng dụng phần mềm là không có lỗi ngay cả khi một người kiểm thử với rất nhiều kinh nghiệm và kĩ năng đã kiểm thử phần mềm đó.

Lầm tưởng 6: Bỏ lỗi khiếm khuyết là do lỗi của người kiểm thử

Thực tế: Việc đổi lỗi cho đội ngũ kiểm thử cho các lỗi vẫn còn sót sau khi quá trình kiểm thử được thực hiện là không đúng. Lầm tưởng này liên quan tới thời gian chi phí và tấn suất thay đổi yêu cầu. Tuy nhiên chiến lược kiểm thử cũng có thể dẫn đến lỗi bị bỏ qua bởi đội kiểm thử

Lầm tưởng 7: Người kiểm thử phải chịu trách nhiệm cho chất lượng sản phẩm

Thực tế: Đó là sai lầm phổ biến mà mọi người chỉ nghĩ rằng đội kiêm thử chịu trách nhiệm cho chất lượng sản phẩm. Trách nhiệm của người kiểm thử bao gồm xác định lỗi của các bên liên quan và sau đó sau đó là quyết định của họ cho dù họ sẽ sửa chữa các lỗi hoặc phát hành phần mềm. Tại thời điểm phát hành phầm mềm có rất nhiều áp lực lên đội ngũ kiểm thử, họ sẽ bị phàn nàn cho bất kì sai sót nào.

Lầm tưởng 8:Kiểm tra tự động nên được sử dụng bất cứ nơi nào có thể giúp giảm thời gian

Thực tế: Điều này đúng nhưng việc tự động test ở bất kì thời điểm phát triển phần mềm là không thể. Test tự động nên được bắt đầu khi mà phần mềm đã được kiểm thử thủ công và đã đạt đến trạng thái ổn định. Hơn nữa. Test tự động có thể không được tái sử dụng nếu yêu cầu luôn thay đổi.

Lầm tưởng 9: Bất cứ ai cũng có thể thử nghiệm một ứng dụng phần mềm

Thực tế: Những người không thuộc lĩnh vực IT nghĩ rằng mọi người đều có thể kiểm thử và kiểm thử không phải là một công việc sáng tạo. Tuy nhiên người kiểm thử hiểu rẳng đó là một sai lầm. Người phát triển phần mềm không bao giờ suy nghĩ về kịch bản thay thế, hay làm cố gắng sụp đổ một phần mềm với mục đích để khám phá ra các lỗi tiềm năng.

Lầm tưởng 10:Nhiệm vụ duy nhất của người kiểm thử là tìm bug

Thực tế: Việc tìm lỗi trong phần mềm là nhiệm vụ của người kiểm thử.Ngoài ra họ còn là chuyên gia để đưa ra những yêu cầu góp phần làm hoàn thiện sản phẩm. Người lập trình chỉ chịu trách nhiệm cho thành phần hoặc chức năng mà họ được giao nhưng người kiểm thử có thể hiểu được tổng thể dự án , những sự ràng buộ và những tác động qua lại của các chức năng trong hệ thống

Nguồn:http://www.tutorialspoint.com/software_testing/software_testing_overview.htm