Nhóm kiểm thử độc lập
Phát triển phần mềm bao giờ cũng có lỗi và kiểm thử được dùng để tìm và sửa lỗi. Cách tiếp cận này KHÔNG hiệu quả trong cải tiến chất lượng phần mềm nhưng nhiều trường vẫn dạy cách tiếp cận này. Sinh viên được dạy rằng phát triển phần mềm tuân theo bốn pha: Yêu cầu, Thiết kế, Viết mã và Kiểm thử. Phần mềm không nên được thiết kế chừng nào yêu cầu còn chưa được phân tích đầy đủ. Phần mềm không nên được viết mã chừng nào thiết kế còn chưa làm xong. Phần mềm không thể được kiểm thử chừng nào viết mã còn chưa được đầy đủ. Lỗi phần mềm được loại bỏ trong kiểm thử trước khi đưa ra cho người dùng.
Trong thực hành, phần lớn lỗi thường được tạo ra trong pha yêu cầu hay thiết kế, nhưng kiểm thử không thể phát hiện được chúng chừng nào viết mã còn chưa được thực hiện do đó lỗi bao giờ cũng được tìm thấy muộn trong dự án. Trong thời gian này, phần lớn các dự án đã chạy hết thời gian cho nên người phát triển vội vàng đưa ra phần mềm và người dùng chấm dứt với sản phẩm có lỗi. Giải pháp cho vấn đề này là ở chỗ người kiểm thử phải lập kế hoạch kiểm thử trong pha yêu cầu và các trường hợp kiểm thử thiết kế đồng thời lúc người phát triển thiết kế phần mềm, và viết mọi trường hợp kiểm thử đồng thời lúc người phát triển thực hiện viết mã. Vậy, phát triển kiểm thử xảy song hành với phát triển phần mềm.
Điều quan trọng là có nhóm kiểm thử độc lập để làm việc về phát triển kiểm thử đồng thời với phát triển phần mềm. Điều này có thể giúp phát hiện sớm lỗi và cải tiến chất lượng phần mềm. Không may là nhiều công ti dùng những người phát triển để làm kiểm thử cho phần mềm riêng của họ để tiết kiệm chi phí thuê người kiểm thử phụ. Thực hành này có thể làm phát sinh việc người phát triển tạo ra kiểm thử mà chỉ kiểm thử những phần của phần mềm đã làm việc, dựa trên thiên kiến riêng của họ. Chung cuộc, phần mềm sẽ qua kiểm thử nhưng vẫn chứa lỗi. Khi người dùng tìm thấy lỗi trong phần mềm, phần lớn người phát triển khăng khăng rằng các kiểm thử của họ không để lộ ra lỗi nào. Điều này tạo ra thái độ đối đầu giữa người dùng và người phát triển.
Có người kiểm thử độc lập phân tích các yêu cầu một cách tách rời với người phát triển thì có thể nhận diện một số lỗi yêu cầu hay thiếu thông tin. Về căn bản, phần lớn người dùng chỉ cho người phát triển các yêu cầu mức cao và phần lớn những người phát triển muốn dẫn ra yêu cầu riêng của họ (thường không được làm tài liệu) dựa trên hiểu biết riêng của họ về nhu cầu của người dùng. Có người kiểm thử độc lập kiểm điểm lại các yêu cầu sẽ tránh được vấn đề này bởi vì người kiểm thử phải hiểu yêu cầu một cách chi tiết. Nếu họ không biết các yêu cầu, họ không thể tạo ra được các kiểm thử hay ngược lại, nếu họ không thể kiểm thử được chúng, họ không biết yêu cầu. Theo kinh nghiệm của tôi, đây là lúc dự án có thể nhận diện mọi yêu cầu không nhất quán, không đầy đủ, mơ hồ và sửa chúng trước khi chuyển sang pha tiếp.
Với hiểu rõ về yêu cầu, những người kiểm thử độc lập có thể thiết kế các trường hợp kiểm thử mà kiểm thử cái gì đó có thể đã không được người phát triển xét tới trong thiết kế của họ. Bằng việc có kiểm điểm kiểm thử thiết kế, người kiểm thử và người phát triển có thể so sánh các ghi chú ở mức chi tiết. Hoạt động này có thể nhận diện các lỗi thiết kế hoặc bởi người phát triển hoặc bởi người kiểm thử. Bằng việc có hành động sửa chúng trước pha thực hiện, dự án có thể khử bỏ được nhiều lỗi. Đây là lúc phần lớn các cấu phần trùng lặp nhất, các hoạt động thiết kế dư thừa có thể được nhận diện. Bằng việc có góc nhìn tách rời, tổ dự án có thể kiểm thiết kế giao diện, cách dùng đúng các thực thể và quan hệ, luồng dữ liệu và điều khiển, việc chuyển trạng, để chứng tỏ rằng thiết kế thoả mãn yêu cầu.
Nếu dự án đã có yêu cầu tốt và kiểm điểm thiết kế nhận diện và sửa hầu hết các lỗi thì việc thực hiện thường là dễ dàng. Việc đưa lỗi vào trong pha viết mã là dễ sửa bởi kiểm thử đơn vị. Tôi bao giờ cũng tin rằng nguồn của hầu hết lỗi phần mềm là do thiếu kỉ luật trong cách tổ chức xây dựng phần mềm. Bằng việc áp dụng kỉ luật kĩ nghệ phần mềm như có nhóm kiểm thử độc lập, có nhiều cuộc kiểm điểm, dự án phần mềm có thể loại bỏ được hầu hết các lỗi thoe cách có trật tự.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
