Tuy nhiên, những người phát triển không thích kiểm thử và nhiều người quản lí phần mềm coi nó là “không quan trọng”. Khi lịch biểu sít sao, họ không có vấn đề gì khi giảm hoạt động kiểm thử hay thỉnh thoảng còn bỏ qua nó. Có hiểu lầm nào đó về kiểm thử như “kiểm thử là dễ”, “bất kì ai cũng có thể làm kiểm thử”, “kiểm thử là nhanh chóng vì mọi mã đã được viết rồi”, “kiểm thử sẽ làm chậm dự án lại”, và “bỏ qua kiểm thử, tiết kiệm tiền và để người dùng tìm lỗi rồi chúng ta sửa chúng về sau.” Đây tất cả đều sai và với thái độ xấu đó, chất lượng phần mềm KHÔNG thể được cải thiện.
Không có kiểm thử đúng, thảm hoạ phần mềm tiềm năng có thể dễ dàng biến thành thực tại. Sau đây là vài trường hợp rất nổi tiếng:
Cảng hàng không Heathrow của Anh mua hệ thống xử lí hành lí do máy tính kiểm soát để cho việc checkin được dễ dàng và nhanh chóng. Vào ngày khai mạc, khi hàng nghìn người làm checkin, hệ thống đã không làm việc, buộc các hãng hàng không cắt bỏ 34 chuyến bay và dừng kiểm tra hành lí với hàng nghìn hành khách mắc kẹt ở sân bay. 10 ngày sau, không ai có thể nhận diện được vấn đề và các hãng hàng không phải cắt bỏ 500 chuyến bay với hàng trăm nghìn hành khách giận dữ. Phí tổn của vấn đề này là vài trăm triệu đô la. Cuối cùng, một kĩ sư phần mềm tìm ra lỗi trong mã đã KHÔNG được kiểm thử vì người quản lí ra lệnh bỏ qua nó để đáp ứng lịch biểu.
Một thất bại lớn khác là hệ thống hộ chiếu của chính phủ Anh nơi chính phủ đưa vào hệ thống máy tính mới để kiểm tra hộ chiếu hiệu quả hơn trong các kì nghỉ lễ. Trong hai tuần đầu, hệ thống không chạy và hơn nửa triệu công dân Anh không vui vẻ gì khi khám phá ra rằng hộ chiếu của họ là “không hợp lệ” và họ không thể du hành được. Về sau, người ta mới tìm ra nguyên nhân chính là “Tràn chồng” trong mã và lí do là một số chức năng đã KHÔNG được kiểm thử khi người quản lí quyết định để cho người dùng tìm lỗi rồi họ có thể sửa chúng để tiết kiệm thời gian và tiền bạc.
Airbus A380 cũng kinh nghiệm các vấn đề lớn và bị trễ hơn 2 năm và chịu phí tổn trên tỉ đô la. Vấn đề là phiên bản phần mềm sai đã được dùng trong kiểm thử bởi vì nhiều nhóm đã KHÔNG dùng cùng qui trình quản lí cấu hình. Nhóm Đức dùng phiên bản lạc hậu của phần mềm còn hệ thống Pháp dùng phiên bản mới nhất. Cho nên khi Airbus tích hợp tất cả các hệ thống lại, các phiên bản khác nhau không sánh đúng. Người kiểm thử phần mềm KHÔNG tìm thấy cái gì sai trong khi kiểm thử trong môi trường của họ. Không có kiểm thử tích hợp, không ai biết khác biệt trong các phiên bản phần mềm.
Có hàng nghìn trường hợp mà việc thiếu kiểm thử có thể đóng góp vào thất bại của các dự án chính. Ngày nay phần mềm đang ngày càng lớn hơn và phức tạp hơn, kiểm thử đang trở nên ngày càng quan trọng hơn bao giờ. Chẳng hạn, người ta đã ước lượng rằng điện thoại di động đơn giản có trên 10 triệu dòng mã (LOC) còn “điện thoại thông minh” có trung bình 20 triệu dòng mã. Xe hơi trung bình có trên 200 triệu dòng mã còn máy bay và qui trình chế tạo tự động của nó yêu cầu trên tỉ dòng mã.
Có nhiều lí do tại sao các dự án phần mềm có thể đi sai nhưng kiểm thử là chỗ bạn tìm ra vấn đề và sửa chúng trước khi đưa ra cho người dùng. Kiểm thử là một trong những nhân tố quan trọng và mấu chốt nhất trong mọi dự án phần mềm lớn nhỏ. Người phần mềm giỏi không bao giờ nên bỏ qua kiểm thử hay dành ít thời gian trong kiểm thử và chúng ta cần có thái độ “Chúng ta KHÔNG thể đảm đương được nếu KHÔNG kiểm thử.”
Testing is a necessity on every software projects. However, developers do not like to test and many software managers consider it “Not important”. When schedule is tight, they have no problem reduce testing activities or sometime skip it. There are some misconceptions about testing such as “testing is easy”, “anyone can do testing”, “testing is quick since all the code has been written”, “testing will slow the project down”, and “Skip the test, save money and let users find defects then we can fix them later”. These are all false and with that bad attitude, software quality can NOT be improved.
Without properly testing, potential software disasters can easily turn into reality. Following are some well known cases:
British’s Heathrow’s airport terminal 5 brought a computer control baggage handling system so check in would be easy and fast. On opening day, where thousands people checked in, the system did not work, forcing airlines to cancel 34 flights and suspended all baggage check in with thousand travelers stranded in the airport. The next 10 days, no one can identify the problems and airlines had to cancel 500 flights with hundred thousands angry travelers. The cost of the problem was several hundred million dollars. Finally, a software engineer found a defect in the code that has NOT been tested as manager ordered it skipped to meet the schedule.
Another major fiasco is the British government’s passport system where the government brought a new computer system to check passports more efficiently during holiday seasons. In the first two weeks, the systems failed and more than half a million British citizens were less than happy to discover that their passports were “invalid” and they could not travel. Later, it was found the main cause was a “Stack overflow” in the code and the reason was some functions were NOT tested as manager decided to let users find defects then they can fix them to save time and money.
The Airbus A380 also experienced significant problems and delays for more than 2 years and cost over a billion dollars. The problem was the wrong versions of software had been used during testing because several groups did NOT use the same configuration management process. The German group used an out-of-date version of software and the French system used the latest version. So when Airbus integrated all systems together, the different versions did not match. Software testers did NOT find anything wrong during testing as they tested them in their own environment. Without integration test, nobody knows the difference in the software version.
There are thousands of cases where a lack of testing can be attributed to the failure of major projects. Today software are growing larger and more complex, testing is becoming more and more important than ever. For example, it is estimated that simple mobile phones have over 10 million lines of code (LOC) and “Smart phone” have on the average 20 million lines of code. An average car has over 200 million lines of code and an airplane and its automated manufacturing process would require over billion lines of code. There are many reasons why software projects can go wrong but testing is where you find problems and fix them before release to users. Testing is one of the most important and critical factors in every large and small software projects. A good software people should never skip testing or spend less time during testing and as we need to have an attitude that “We can NOT afford Not to test”.
