Kiểm thử chất lượng
Trong quá khứ khi phần mềm còn nhỏ, chỉ vài trăm dòng mã, thì kiểm thử là tương đối dễ dàng. Là người phát triển phần mềm, điều tôi đã làm là phải chắc rằng thuật toán đúng và phân tích kết cấu chương trình để chắc chắn nó được biên dịch đúng. Nếu tôi có lỗi, tôi sửa chúng rồi biên dịch lại cho nên kiểm thử không thành vấn đề. Tuy nhiên, khi kích cỡ phần mềm trở nên lớn hơn, tôi bắt đầu thấy rằng tôi bị nhiều lỗi sau khi đưa ra cho khách hàng (một lỗi là chồng bị tràn) cho nên tôi bắt đầu cẩn thận hơn về kiểm thử. Tôi bắt đầu viết các trường hợp kiểm thử để chắc chắn rằng chương trình chạy đúng và đáp ứng nhu cầu với dữ liệu vào và dữ liệu ra (kiểm thử hộp đen). Cuối cùng, nhiều chương trình tôi đã viết đã được tích hợp với các chương trình khác cho nên là một tổ chúng tôi đã phân chia công việc của mình thành các chức năng và tính năng tách bạch dựa trên phương pháp phân tích cấu trúc nhưng chúng tôi vẫn làm việc một cách độc lập, chỉ thảo luận với nhau khi cần. Từng người vẫn làm kiểm thử riêng và chúng tôi tin tưởng rằng mọi thứ phải làm việc theo cách chúng tôi nghĩ, nhưng đến cuối cùng nó lại không làm việc tốt. Có quá nhiều lỗi trong sản phẩm cuối cùng của chúng tôi cho nên người quản lí của tôi quyết định thành lập nhóm kiểm thử bao gồm nhiều người lập trình mới tuyển, người được trao cho việc kiểm tra lại phần mềm để chắc chắn chúng làm việc được trước khi chúng được đưa ra. Là người phát triển phần mềm, chúng tôi chỉ phải tập trung hầu hết vào thiết kế và viết mã. Chúng tôi đã kiểm thử mã riêng của mình và không lo nghĩ nhiều về phần còn lại của phần mềm cuối cùng. Cho nên tổ của chúng tôi bao gồm hai nhóm, nhóm người phát triển và nhóm kiểm thử và quan niệm này đã được chấp nhận trong nhiều công ti phần mềm và nó vẫn là cách thức nhiều công ti vận hành ngày nay.
Bây giờ nhìn lại sao nhiều năm, ngạc nhiên lớn nhất của tôi là làm sao nhiều người vẫn tin rằng bạn có thể “kiểm thử chất lượng” trong sản phẩm phần mềm. Ngày nay phần lớn các phần mềm đều rất lớn và phức tạp, nhiều dự án của tôi có khoảng 5 tới 20 triệu dòng lệnh và không thể nào kiểm thử hết mọi thứ cho nên thay vì hội tụ vào kiểm thử, chúng tôi hội tụ vào cách tiếp cận có kỉ luật để “xây dựng trong chất lượng” khi chúng tôi làm việc. Điều này cũng là khác biệt chính giữa đào tạo kĩ nghệ phần mềm và khoa học máy tính. Với kĩ nghệ phần mềm, bạn phải hội tụ vào qui trình tạo ra sản phẩm và “xây dựng chất lượng trong qui trình” cho nên sản phẩm cuối sẽ có chất lượng. Tất nhiên, không ai hoàn hảo cho nên bạn phải dựa vào người khác để hỗ trợ cho bạn và nhận diện sai lầm của bạn để cho bạn có thể sửa nó. Do đó, kiểm điểm phần mềm, giám định mã, lập trình cặp, suy nghĩ theo pha, và rút ra bài học được áp dụng để đảm bảo rằng chúng ta sẽ có sản phẩm chất lượng.
Khi sinh viên tới lớp của tôi tại CMU, nhiều người có thái độ “Sao lại chú ý tới lỗi khi đằng nào chúng ta cũng có thể sửa được nó” hay “Viết mã trước, sửa lỗi sau” cho nên tôi kể cho họ một kịch bản: “Giả sử rằng bạn đang bay trong máy bay và bạn nghe phi công nói rằng anh ta gặp lỗi phần mềm trong hệ thống điều khiển và phải “khởi động lại” hệ thống. Khởi động lại hệ thống sẽ mất bao nhiêu thời gian? Chỉ mười hay hai mươi phút và điều đó có nghĩa là máy bay sẽ không có nguồn trong thời gian đó và tất nhiên sẽ rơi” và tôi hỏi: “Bạn có thực sự quan tâm tới lỗi phần mềm hay không?” Khi cả lớp cười to, tôi nói thêm: “Tôi chắc chắn điều đó tuỳ thuộc vào quan điểm của bạn, bạn có lẽ quan tâm nếu bạn đang ở trên máy bay và không quan tâm nếu bạn đang ở trên mặt đất. Cho nên vấn đề thực là liệu lỗi có vấn đề theo nghĩa lí thuyết không nhưng liệu nó có là vấn đề cho bạn không. Để tôi cho bạn ví dụ khác, bạn là người chủ của một công ti phần mềm và bạn có hàng trăm người lập trình làm việc cho bạn. Nếu khách hàng thấy lỗi phần mềm trong sản phẩm của bạn thì bạn phải sửa nó. Chi phí để phát hiện, phục hồi, báo cáo, sửa chữa, phân phối lại và chi phí cài đặt lại cho mọi lỗi trung bình sẽ là quãng $ 4000 cho từng lỗi và có hàng trăm hay hàng nghìn lỗi cho sản phẩm bạn bán. Bạn có thực sự quan tâm không? Bạn bán phần mềm đó được bao nhiêu và bạn phải chi bao nhiêu tiền để sửa lỗi? Bất kể nguyên nhân của chúng, chi phí lỗi đều rất đắt, nếu bạn phải trả chi phí này, bạn sẽ thực sự quan tâm về lỗi. Câu hỏi của tôi là, là người chủ công ti phần mềm, bạn vẫn thuê những người không quan tâm về lỗi sao?
Theo nghiên cứu của giáo sư Watt Humphrey tại Carnegie Mellon, người phát triển phần mềm có kinh nghiệm đưa vào một lỗi cứ trong mỗi 10 dòng mã. Trong khi các con số này thay đổi lớn từ người phát triển phần mềm này sang người phát triển khác, và họ đưa vào mọi thứ lỗi, thậm chí cả những lỗi được tìm thấy trong kiểm điểm hay bởi trình biên dịch, vẫn có nhiều lỗi. Tuy nhiên, nhiều người phát triển phần mềm tin rằng trình biên dịch sẽ tìm ra mọi lỗi. Không may có nhiều lỗi gõ vào mà trình biên dịch lại không tìm ra. Chẳng hạn, trong C, gõ “=“ thay cho “= =“ có thể tạo ra phép gán thay vì phép so sánh. Mặc dầu trình biên dịch có thể tìm ra 90% lỗi nhưng còn 10% kia thì sao? Nhiều người tin rằng 10% kia có thể được thực hiện bằng kiểm thử. Tuy nhiên, nhiều chương trình sẽ chạy ngay cả khi chúng có lỗi. Thực tế, chúng có thể có nhiều lỗi và vẫn qua được nhiều kiểm thử. Ngay cả để tìm ra số phần trăm lỗi lớn trong một chương trình, chúng ta vẫn phải kiểm thử gần như tất cả các con đường và điều kiện logic. Và để tìm ra tất cả các lỗi trong ngay cả chương trình nhỏ, chúng ta sẽ phải cho chạy kiểm thử vét cạn mà có thể tốn kém và yêu cầu nhiều nỗ lực.
Ngày nay hầu hết những người phát triển phần mềm dành nhiều thời gian cố gắng làm cho phần mềm của họ làm việc rồi dành nhiều thời gian hơn để chữa lỗi và các vấn đề được báo cáo. Đây là vấn đề chính cho doanh nghiệp nhưng nhiều người quản lí phần mềm không được huấn luyện để giải quyết điều này. Họ chỉ hội tụ vào lịch biểu, cách chuyển giao bên trong ngày tháng nào đó nhưng không biết nhiều về kinh doanh tài chính. Tất nhiên người quản lí cấp cao biết nhưng họ quá bận quản lí công ti và không chú ý tới dự án cho nên những người cuối cùng thực sự quan tâm là khách hàng. Tất nhiên khách hàng có chọn lựa và khi họ không thoả mãn với chất lượng, họ làm kinh doanh với ai đó khác.
Tôi cũng thấy rằng hầu hết những người phát triển phần mềm không được đào tạo trong việc nhận diện và sửa lỗi an ninh. Lỗi an ninh là bất kì lỗi thiết kế nào cho phép các hắc khách, kẻ phạm tội, hay kẻ khủng bố thu được quyền truy nhập hay dùng hệ thống phần mềm. Vì nhiều trong số các lỗi này không gây ra vấn đề chức năng, hay lỗi khi chạy, chúng sẽ qua mọi kiểm thử chức năng nhưng phần mềm vẫn có những mong manh an ninh tiềm năng mà có thể tạo ra vấn đề trong tương lai.
Quan điểm của tôi là để đảm bảo chất lượng, chúng ta phải xây dựng chất lượng trong cách chúng ta làm việc và rằng lỗi là vấn đề nghiêm chỉnh yêu cầu sự chú ý lớn từ mọi người. Cách tốt nhất để ngăn cản lỗi là đào tạo tốt hơn và đào tạo nên bắt đầu sớm nhất có thể được trong mọi đại học và nên được nhấn mạnh trong mọi lớp tính toán.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Kĩ nghệ phần mềm
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
