KHI NÀO CÁC DEFECT PHÁT SINH?
Trong Hình 1.1, chúng ta có thể thấy các defect có thể phát sinh như thế nào trong bốn yêu cầu dưới đây.
Yêu cầu 1 được thực hiện chính xác – hiểu yêu cầu của khách hàng, thiết kế chính xác để đáp ứng yêu cầu đó, xây dựng chính xác để đáp ứng thiết kế và do đó, phân phối đúng sản phẩm về mặt chức năng.
Với các yêu cầu khác, lỗi đã phát sinh ở các giai đoạn khác nhau.
Yêu cầu 2 tốt cho đến khi phần mềm được xây dựng. Có thể, những điều này dễ dàng được phát hiện và sửa chữa trong quá trình thử nghiệm, vì chúng ta có thể thấy sản phẩm không đáp ứng đặc điểm thiết kế của nó.
Các defect trong yêu cầu 3 khó xử lý hơn; lấy yêu cầu đúng nhưng lại phạm sai lầm trong việc thiết kế. Những defect này sẽ không thể nào được phát hiện ra (trừ khi thực hiện kiểm tra yêu cầu). Khi phát hiện ra, chúng ta sẽ khó sửa chữa vì sẽ phải thay đổi thiết kế.
Các defect trong yêu cầu 4 đã được đưa ra trong quá trình xác định các yêu cầu (tức sai ngay từ bước đặc tả yêu cầu); sản phẩm đã được thiết kế và xây dựng để đáp ứng định nghĩa yêu cầu thiếu sót đó. Sản phẩm đáp ứng các yêu cầu và thiết kế của nó nhưng vẫn có thể bị người dùng hoặc khách hàng từ chối.
Các defect trong yêu cầu (requirement) và thiết kế không phải là hiếm; đánh giá của hàng nghìn dự án đã chỉ ra rằng các defect được đưa ra trong quá trình yêu cầu và thiết kế chiếm gần một nửa tổng số defect [Jones].
Chi phí của các defect như thế nào?
Cũng như việc xem xét ảnh hưởng của các failure phát sinh từ các defect mà chúng ta chưa tìm thấy, cần xem xét ảnh hưởng của thời điểm chúng ta tìm thấy các khuyết tật đó. Chi phí tìm kiếm và sửa chữa các defect tăng lên đáng kể trong suốt vòng đời phát triển sản phẩm.
Nếu liên hệ các tình huống được đề cập trước đó với Hình 1.2, ta thấy rằng, nếu một lỗi được tạo ra và lỗi do hậu quả được phát hiện trong các yêu cầu ở giai đoạn đặc tả, thì việc tìm và sửa chữa tương đối rẻ.
Đặc điểm kỹ thuật có thể được sửa chữa và phát hành lại. Tương tự như vậy, nếu một error được tạo ra và defect do hậu quả được phát hiện trong thiết kế ở giai đoạn thiết kế thì thiết kế có thể được sửa chữa với chi phí tương đối ít. Điều này cũng áp dụng cho việc xây dựng sản phẩm.
Tuy nhiên, nếu một defect được đưa ra trong đặc tả yêu cầu và nó không được phát hiện cho đến khi kiểm thử chấp nhận hoặc ngay cả khi hệ thống đã được triển khai thì việc sửa chữa sẽ tốn kém hơn nhiều. Điều này là do sẽ cần phải thiết kế lại, xây dựng lại; một defect trong các yêu cầu đặc tả cũng có thể ảnh hưởng một số vị trí trong thiết kế và coding.
Các defect được phát hiện ở giai đoạn rất muộn rất thường xuyên xảy ra, chi phí để sửa chữa thường là rất lớn.
Nhóm dự án có thể đã phân phối chính xác những gì họ được yêu cầu, nhưng đó không phải là những gì người dùng muốn. Điều này có thể dẫn đến việc người dùng không hài lòng với hệ thống được phân phối cuối cùng. Trong một số trường hợp, khi lỗi quá nghiêm trọng, hệ thống có thể phải được gỡ cài đặt hoàn toàn.
Vai trò của kiểm thử trong phát triển, bảo trì và vận hành phần mềm
Chúng ta đã thấy rằng sai lầm của con người có thể gây ra defect hoặc fault trong bất kỳ giai đoạn nào trong vòng đời phát triển phần mềm, tùy thuộc vào hậu quả của sai lầm mà kết quả có thể không đáng kể hoặc rất thảm khốc.
Kiểm thử nghiêm ngặt là cần thiết trong quá trình phát triển và bảo trì để xác định các defect , nhằm giảm thiểu các failure trong môi trường vận hành và tăng chất lượng của hệ thống. Điều này bao gồm việc tìm kiếm những vị trí trong giao diện người dùng mà người dùng có thể mắc lỗi khi nhập dữ liệu hay tìm kiếm các điểm yếu tiềm ẩn mà mục đích tấn công có chủ đích và độc hại.
Kiểm thử mang lại lợi ích gì?
Việc thực hiện kiểm thử giúp ta tiến tới nâng cao chất lượng sản phẩm và dịch vụ, nhưng lưu ý rằng đó chỉ là một trong những phương pháp xác minh (verification) và xác nhận (validation) được áp dụng cho sản phẩm. Quy trình cũng được kiểm tra, ví dụ bằng đánh giá. Nhiều phương pháp có thể được sử dụng để kiểm tra công việc, một số phương pháp được thực hiện bởi tác giả của tác phẩm và một số phương pháp khác được thực hiện bởi những người khác để có được một cái nhìn độc lập.
Chúng ta cũng có thể được yêu cầu thực hiện kiểm thử phần mềm để đáp ứng các yêu cầu theo hợp đồng hoặc pháp lý hoặc các tiêu chuẩn dành riêng cho ngành. Các tiêu chuẩn này có thể chỉ định loại kỹ thuật nào chúng ta phải sử dụng hoặc tỷ lệ phần trăm mã phần mềm phải được thực hiện.
Lúc nào cũng kiểm tra tất cả mã code?
Không phải lúc nào chúng ta cũng kiểm tra tất cả các mã code; so với rủi ro mà chúng ta đang đối phó, thì việc kiểm tra tất cả mã code gay ra một chi phí quá đắt. Tuy nhiên, rủi ro liên quan đến ngành sử dụng phần mềm càng cao, thì càng có nhiều khả năng tồn tại một tiêu chuẩn để kiểm tra. Các ngành công nghiệp điện tử hàng không, động cơ, y tế và dược phẩm đều có các tiêu chuẩn bao gồm việc kiểm tra phần mềm. Ví dụ, tiêu chuẩn DO-178B của Cục Hàng không Liên bang Hoa Kỳ [RTCA / DO-178B] có các yêu cầu về phạm vi kiểm thử.
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây.
