Khiếm khuyết và thất bại trong kiểm thử phần mềm phát sinh từ đâu và khi nào?
1. Lỗi trong đặc tả, thiết kế và thực hiện của phần mềm và hệ thống Lỗi khi sử dụng hệ thống Điều kiện môi trường Hư hỏng cố ý Hậu quả tiềm ẩn của các lỗi trước đó a. Lỗi trong đặc tả và thiết kế của phần mềm: Đặc điểm kỹ thuật cơ bản là một tài liệu bằng văn bản mô tả các khía cạnh ...
1. Lỗi trong đặc tả, thiết kế và thực hiện của phần mềm và hệ thống
- Lỗi khi sử dụng hệ thống
- Điều kiện môi trường
- Hư hỏng cố ý
- Hậu quả tiềm ẩn của các lỗi trước đó
a. Lỗi trong đặc tả và thiết kế của phần mềm:
Đặc điểm kỹ thuật cơ bản là một tài liệu bằng văn bản mô tả các khía cạnh chức năng và phi chức năng của phần mềm bằng cách sử dụng văn xuôi và hình ảnh. Để kiểm tra đặc điểm kỹ thuật không cần phải có mã. Nếu không có mã chúng ta có thể kiểm tra các thông số kỹ thuật. Khoảng 55% số lỗi hiện có trong sản phẩm là do những sai sót có trong bản mô tả. Do đó kiểm tra các chi tiết kỹ thuật có thể mất rất nhiều thời gian và chi phí trong tương lai hoặc trong giai đoạn sau của sản phẩm.
b. Lỗi khi sử dụng hệ thống:
Lỗi khi sử dụng hệ thống hoặc sản phẩm hoặc ứng dụng có thể phát sinh do những lý do sau:
- Người kiểm tra có kiến thức không đầy đủ về sản phẩm hoặc phần mềm. Người kiểm tra có thể không nhận thức được chức năng của sản phẩm và do đó trong khi kiểm tra sản phẩm có thể có một số khuyết tật hoặc thất bại.
- Thiếu sự hiểu biết về các chức năng của nhà phát triển. Nó cũng có thể xảy ra do các nhà phát triển có thể không hiểu các chức năng của sản phẩm hoặc ứng dụng đúng cách. Dựa trên sự hiểu biết của họ, tính năng mà ho sẽ phát triển có thể không phù hợp với thông số kỹ thuật. Do đó điều này có thể dẫn đến khuyết tật hoặc thất bại.
c. Điều kiện môi trường:
Bởi vì thiết lập sai của môi trường thử nghiệm người kiểm tra có thể báo cáo các khuyết tật hoặc thất bại. Theo các khảo sát gần đây, người ta đã quan sát thấy rằng khoảng 40% thời gian của người thử nghiệm được dùng vì các vấn đề môi trường và điều này có ảnh hưởng lớn đến chất lượng và năng suất. Do đó các môi trường kiểm tra thích hợp là cần thiết cho chất lượng và thời gian giao hàng của sản phẩm cho khách hàng.
d. Hư hỏng cố ý:
Các khuyết tật và thất bại do người kiểm tra báo cáo trong khi kiểm tra sản phẩm hoặc ứng dụng có thể phát sinh do các hư hỏng có chủ ý.
e. Các hậu quả tiềm ẩn của các lỗi trước đó:
Lỗi phát hiện trong giai đoạn đầu của sự phát triển làm giảm chi phí sản xuất. Do đó tìm ra lỗi ở giai đoạn trước đó là rất quan trọng. Điều này có thể được thực hiện bằng cách xem xét các tài liệu đặc tả hoặc hướng dẫn. Khiếm khuyết phát hiện ở các giai đoạn sau sẽ làm tăng chi phí sản xuất.
Vì những lý do sau đây, lỗi phần mềm phát sinh:
- Người sử dụng ứng dụng phần mềm hoặc sản phẩm có thể không có đủ kiến thức về sản phẩm.
- Có thể phần mềm được sử dụng sai cách nên dẫn đến khuyết tật hoặc lỗi.
- Các nhà phát triển có thể đã mã hoá không chính xác và có thể có lỗi xảy ra trong thiết kế.
- Môi trường thử nghiệm thiết lập không chính xác
Để biết khi nào lỗi trong kiểm thử phần mềm phát sinh, chúng ta hãy lấy một ví dụ nhỏ với một sơ đồ như dưới đây.
Chúng ta có thể thấy yêu cầu 1 được thực hiện chính xác - chúng ta hiểu được yêu cầu của khách hàng, được thiết kế đúng để đáp ứng yêu cầu, được xây dựng đúng để đáp ứng được thiết kế và do đó bàn giao lại yêu cầu với các thuộc tính đúng: chức năng, nó làm những gì cần phải làm và đúng với cả những thuộc tính phi chức năng, do đó nó dễ hiểu...
Với các yêu cầu khác, lỗi sẽ phát sinh ở các giai đoạn khác nhau. Yêu cầu 2 là tốt cho đến khi phần mềm được mã hoá, khi chúng tôi đưa ra một số sai sót và giới thiệu các khuyết tật. Có lẽ, chúng dễ dàng được phát hiện và sửa chữa trong quá trình thử nghiệm, bởi vì chúng ta có thể thấy sản phẩm không đáp ứng được đặc điểm thiết kế của nó.
Các khuyết tật được giới thiệu trong Yêu cầu 3 khó giải quyết hơn; Chúng tôi xây dựng chính xác những gì chúng tôi đã nói, nhưng tiếc là các nhà thiết kế đã thực hiện một số sai lầm do đó đã có những khuyết tật trong thiết kế. Trừ khi chúng tôi kiểm tra lại so với các yêu cầu đã được định nghĩa, chúng tôi sẽ không phát hiện ra những khuyết tật trong quá trình thử nghiệm. Khi chúng tôi nhận thấy chúng, chúng sẽ khó sửa chữa bởi vì thay đổi thiết kế là bắt buộc.
Các khuyết tật trong Yêu cầu 4 đã được đưa ra trong quá trình định nghĩa các yêu cầu; Sản phẩm đã được thiết kế và xây dựng để đáp ứng các yêu cầu thiếu sót đó. Nếu chúng tôi kiểm tra sản phẩm đáp ứng các yêu cầu và thiết kế của nó, nó sẽ vượt qua các thử nghiệm nhưng có thể bị từ chối bởi người dùng hoặc khách hàng. Các khuyết tật do khách hàng báo cáo trong bài kiểm tra chấp nhận hoặc sử dụng trực tiếp có thể rất tốn kém. Thật không may, yêu cầu và khiếm khuyết thiết kế không phải là hiếm; Đánh giá của hàng ngàn dự án đã chỉ ra rằng các khuyết tật trong các yêu cầu và thiết kế chiếm gần một nửa tổng số khuyết tật.
Link tham khảo: http://istqbexamcertification.com/from-where-do-defects-and-failures-in-software-testing-arise/ http://istqbexamcertification.com/when-do-defects-in-software-testing-arise/