Trường hợp kiểm thử tốt là trường hợp có xác suất cao phát hiện ra khiếm khuyết. Tuy nhiên, nghiên cứu công nghiệp thấy rằng ngay cả với trường hợp kiểm thử tốt nhất, người phát triển chỉ có thể bắt được quãng 70% khiếm khuyết và 30% kia vẫn còn sau khi phần mềm được đưa ra cho người dùng. Vì giới hạn của kiểm thử, người ta khuyến cáo rằng người phát triển loại bỏ càng nhiều khiếm khuyết nhất có thể được bằng các phương pháp khác như kiểm điểm và giám định phần mềm trước pha kiểm thử để cải tiến chất lượng của sản phẩm phần mềm.
Có nhiều lí do cho phần mềm có khiếm khuyết. Lí do thông thường nhất là yêu cầu phần mềm không được xác định tốt và thường xuyên thay đổi. Những thay đổi này làm cho người phát triển phải thay đổi điều họ đang làm và nó tạo ra khiếm khuyết. Đó là lí do tại sao Kĩ nghệ yêu cầu (RE) là kĩ năng quan trọng vì nó hội tụ vào nhận diện bất kì mơ hồ nào hay thiếu thông tin trong pha yêu cầu. Nó buộc người phát triển phải nhìn vào toàn bộ yêu cầu để xác định “Thuộc tính kiểm thử được”. Với mọi yêu cầu, người phát triển phải có khả năng viết ra trường hợp kiểm thử. Nếu họ không thể kiểm thử được nó thì hoặc yêu cầu là mơ hồ hoặc người phát triển KHÔNG hiểu yêu cầu. Trong cả hai trường hợp, thảo luận với người dùng để làm sáng tỏ yêu cầu là cần thiết. Đó là lí do tại sao kiểm thử phải được lập kế hoạch ngay sau pha yêu cầu. Tuy nhiên, thiếu kĩ năng kĩ nghệ yêu cầu, nhiều người phát triển KHÔNG lập kế hoạch kiểm thử chừng nào họ còn chưa hoàn thành viết mã. Điều này là quá trễ và đó là sai lầm lớn. Đó là lí do tại sao phần lớn phần mềm có quá nhiều khiếm khuyết và quá tốn kém.
Một sai lầm khác là chiến lược kiểm thử KHÔNG được xác định rõ. Phần lớn những người kiểm thử đều hội tụ vào chức năng kiểm thử chứ KHÔNG vào tích hợp hay bản dựng. Họ tin chừng nào họ kiểm thử xong mọi yêu cầu thì mọi thứ sẽ tốt. Họ KHÔNG được đào tạo về “tư duy hệ thống” để hiểu sự vững chãi của phần mềm bằng việc tập trung vào các phần cốt yếu của hệ thống như năng lực và hiệu năng. Nhiều lần, mọi chức năng làm việc độc lập tốt (qua kiểm thử chức năng) nhưng khi bạn gắn chúng lại với nhau, hệ thống KHÔNG làm việc chút nào hay thực hiện rất chậm (Thất bại kiểm thử tích hợp hay kiểm thử hiệu năng). Những kiểu khiếm khuyết này là khó và yêu cầu nhiều thời gian và nỗ lực để sửa chữa.
Sai lầm thông thường khác là tài nguyên kiểm thử KHÔNG thích hợp. Hoặc người quản lí dự án phân công quá ít thời gian cho kiểm thử hoặc người kiểm thử được đưa tới cho dự án lúc quá muộn. Nếu nhóm kiểm thử KHÔNG hiểu hệ thống rõ thì họ không thể làm tốt việc tìm khiếm khuyết. Nhiều người quản lí dự án KHÔNG phân biệt rõ ràng hoạt động kiểm thử và hoạt động phát triển. Vì kiểm thử thường bị coi như hoạt động cuối cùng, nếu dự án bị trễ, kiểm thử thường bị bỏ để đáp ứng hạn chót đã lập lịch. Tất nhiên, nhiều phần mềm có khiếm khuyết và người dùng rất bực.
Sai lầm thông thường khác là về tri thức và kĩ năng của người kiểm thử. Nhiều người kiểm thử KHÔNG phân biệt được giữa kế hoạch kiểm thử (mục tiêu, cách tiếp cận, tài nguyên được cần tới, v.v.) và thủ tục kiểm thử (cái vào đặc thù, cái ra dự kiến, chỉ đạo cho người kiểm thử v.v.). Nhiều người lập trình cho các trường hợp kiểm thử thay vì kiểm điểm kế hoạch kiểm thử về sự chính xác, thủ tục kiểm thử về tính đầy đủ, và phân tích hiệu quả sai phương thức để nhận diện cái vào gây ra lỗi làm dữ liệu kiểm thử. Ngay cả khi họ kiểm thử, họ KHÔNG thực hiện phân tích bao quát để nhận diện những đường điều khiển nào đã được đi qua bởi dữ liệu kiểm thử và đường nào chưa. Phần lớn mọi người KHÔNG thẩm định tính hiệu quả kiểm thử để xác định dữ liệu kiểm thử đã phơi ra khiếm khuyết trong phần mềm tốt đến đâu. Không có đào tạo thích hợp, nhiều người KHÔNG áp dụng một cách nhất quán kiểm thử rà lại để đảm bảo rằng những thay đổi chương quả trình không tác động vào việc vận hành đúng của hệ. Họ KHÔNG biết tỉ lệ phát hiện lỗi có thể được phân tích thế nào để hỗ trợ cho quyết định đưa ra sản phẩm.
Trong chuyến đi của tôi tới vài nước châu Á năm ngoái, tôi thấy rằng nhiều đại học đã KHÔNG có môn học về kiểm thử phần mềm. Kiểm thử được dạy như một phần của các lớp lập trình. Nhiều sinh viên KHÔNG hiểu kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ hống, kiểm thử alpha, kiểm thử beta, kiểm thử rà lại và kiểm thử chấp nhận. Với họ mọi thứ chỉ là “kiểm thử to” để cho chắc rằng phần mềm thực hiện và KHÔNG chết. Chừng nào quan điểm này còn chưa thay đổi và đào tạo thích hợp còn chưa có tại chỗ, chất lượng phần mềm sẽ KHÔNG được cải tiến.
Testing is the execution of a program to find defects. A good test case is one that has a high probability of detecting defect. However, industry studies found that even with the best test case, developers can only catch about 70% of the defects and the other 30% still remain after the software is released to users. Because the limit of testing, it is recommended that developers remove as many defects as possible by other methods such as software reviews and inspections before testing phase to improve the quality of the software products.
There are many reasons for software to have defects. The most common is software requirements are not well defined and often change. These changes cause developers to change what they are doing and it creates defects. That is why Requirements Engineering (RE) is an important skill because it focuses on identify any ambiguous or missing information during the requirements phase. It forces developers to look at the entire requirements to determine “Testability attributes”. For every requirement, developers must be able to write a test case. If they cannot test it then either the requirement is ambiguous or developers do NOT understand the requirement. In either case, a discussion with users to clarify the requirement is necessary. That is why testing must be planned immediately after the requirements phase. However, lacking of the requirements engineering skill, many developers do NOT plan testing until they complete coding. This is too late and it is a big mistake. That is why most software have too many defects and too costly.
Another common mistake is the Test strategy is NOT well defined. Most developers focus on testing functions but NOT on integration or build. They believe as long as they test all requirements than everything will be good. They are NOT trained in “System Thinking” to understand the robustness of software by concentrate on critical portions of the system such as capacity and performance. Many times, all functions independently work well (Passing functions test) but when you put them together, the system does NOT work anymore or perform very slow (Failing integration test or Performance test). These types of defect are difficult and require a lot of time and efforts to fix.
Another common mistake is the Test resources are NOT adequate. Either project manager assigns too little time for testing or test people are not brought onto project until late. If the test group does NOT understand the system well than they cannot do good job in finding defects. Many project managers do NOT clearly distinct testing activity and developing activity. Since testing is often regarded as the last activity, if a project is late, test is often eliminated to meet the scheduled deadline. Of course, many software have defects and users are very angry.
Another common mistake is on the knowledge and skill of testers. Many testers do NOT make distinction between test plan (objectives, approach, resources required, etc.) and test procedure (specific inputs, the expected outputs, directions to the tester, etc.). Many would program test cases rather than review test plan for adequacy, test procedures for completeness, and failure mode effects analysis to identify probable error-causing inputs as test data. Even when they test, they do NOT perform coverage analysis identify which control paths have been exercised by the test data and which have not. Most do NOT assess test effectiveness to determine how well the test data have exposed defects contained in the software. Without adequate training, many do NOT consistently apply regression testing to ensure that program changes have not impacted correct system functioning. They do NOT know how error discovery rate can be analyzed to support a rational product release decision.
During my trip to several Asian countries last year. I found that many universities did NOT have courses on software testing. Testing was taught as part of programming language classes. Many students did NOT understand Unit testing, Integration testing, System testing, alpha testing, beta testing, Regression testing, and Acceptance testing. To them everything was just a “big test” to make sure that software executed and did NOT crash. Unless this view is changing and appropriate training is in place, software quality will NOT be improved.
