83: Kiểm thử là một quá trình nghiêm ngặt trong phát triển phần mềm

Các nhà phát triển thích sử dụng các ẩn ý bắt buộc khi cố gắng giải thích những gì họ làm với thành viên gia đình, vợ hoặc chồng và những người không có chuyên môn. Chúng tôi thường xuyên sử dụng để xây dựng các cầu nối và các khuôn khổ kỹ thuật cứng nhắc khác. Tuy nhiên, tất cả những ẩn ý này sẽ bị sai lệch nhanh chóng, khi bạn bắt đầu cố gắng sử dụng nó quá nhiều. Nó chỉ ra rằng, phát triển phần mềm không giống như những ngành kỹ thuật “cứng nhắc” theo nhiều khía cạnh quan trọng.

So với các ngành kỹ thuật “cứng”, việc phát triển phần mềm được so sánh với những người xây dựng một cây cầu khi mục tiêu đặt ra là hoàn thiện cây cầu và có thể chịu được sức nặng. Nếu nó giữ nguyên, đó sẽ là một cây cầu tốt. Nếu không, thời gian sẽ đưa tất cả trở về bản vẽ. Trong vài nghìn năm qua, các kỹ sư đã nghiên cứu và tìm ra các nguyên lý toán học và vật lý mà họ có thể sử dụng cho giải pháp về cấu trúc mà không cần phải thử xem điều gì sẽ xảy ra.

Chúng ta không có bất kỳ thứ gì như vậy trong việc phát triển phần mềm và có lẽ sẽ không bao gì vì phần mềm trong thực tế là rất khác nhau. Đối với một nghiên cứu sâu về sự khác biệt giữa kỹ thuật phần mềm là các ngành kỹ thuật thông thường, bài viết “Thiết kế phần mềm là gì?”, được viết bởi Jack Reeves trong tạp chí C++ năm 1992, một tác phẩm kinh điển. Mặc dù nó đã được viết cách đây hơn hai thập kỷ, nhưng nó vẫn rất chính xác. Ông đã “vẽ” một bức tranh ảm đạm trong so sánh này, nhưng điều còn thiếu năm 1992 là một thử nghiệm đầy đủ.

Thử nghiệm những thứ “cứng nhắc” là khó khăn vì bạn phải xây dựng và thử nghiệm, điều này không khuyến khích xây dựng các quá trình trên lý thuyết chỉ để xem điều gì sẽ xảy ra. Nhưng xây dựng quá trình này trong phần mềm rất rẻ. Chúng tôi đã phát triển toàn bộ hệ sinh thái của các công cụ giúp dễ dàng thực hiện điều đó: đơn vị thử nghiệm, đối tượng giả lập, việc khai thác thử nghiệm và nhiều công cụ khác. Các kỹ sư rất thích xây dựng một các gì đó rồi chạy thử trong điều kiện thực tế. Là một nhà phát triển phần mềm, chúng ta nên chấp nhận thử nghiệm như là cơ chế xác minh chính (nhưng không phải là duy nhất) cho phần mềm. Thay vì chờ đợi một số tính toán phần mềm, chúng tôi đã có sẵn các công cụ để đảm bảo thực hiện các kỹ thuật tốt. Nhìn dưới góc độ này, chúng ta hiện có đủ “đạn dược” chống lại các nhà quản lý cho rằng: “Chúng tôi không có thời gian để kiểm tra”. Một người xây dựng cây cầu sẽ không bao giờ nghe thấy từ ông chủ của họ: “Đừng bận tâm phân tích cấu trúc căn nhà đó — chúng tôi có thời hạn cố định.” Sự thừa nhận rằng thử nghiệm thực sự là con đường dẫn đến tái tạo và củng cố chất lượng trong phần mềm cho phép chúng tôi — nhà phát triển đẩy lùi các lập luận chống lại nó là sự thiếu chuyên nghiệp.

Kiểm tra sẽ mất một thời gian, giống như phân tích cấu trúc. Cả hai hoạt động đều sẽ đảm bảo cho chất lượng của sản phẩm cuối cùng. Đã đến lúc các nhà phát triển phần mềm phải chịu trách nhiệm về những gì họ làm ra. Từng cá nhân kiểm tra là không đủ nhưng nó cần thiết. Kiểm tra là kỹ thuật nghiêm ngặt trong phát triển phần mềm.