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ự.

—-English version—-

Independent test group

Software development always has defects and testing is used to find and fix defects. This approach is NOT effective in improving the quality of software but many schools are still teaching this approach. Students are taught that software development follows four phases: Requirements, Design, Code and Test. Software should not be designed until their requirements are fully analyzed. Software should not be coded until design is done. Software cannot be tested until coding is complete. Software defects are removed during testing before released to users.

In practice, most defects are often created during requirements or design phases, but testing cannot detect them until coding is done therefore defects always are found late in the project. During this time, most projects are already run out of time so developers are hurrying to release the software and users end up with defective products. The solution to this problem is that tester should plan the test during requirements phase and design test cases at the same time developer design software, and write all test cases at the same time as developer implementing code. Thus, test development happens concurrently with software development.

It is important to have an independent testing group to work on test development at the same time with software development. This may help in early defect detection and improve software quality. Unfortunately, many companies use developers to do testing of their own software to save costs of hiring additional testers. This practice may result in developers create tests that only test the parts of software that work, based on their own biases. Eventually, software will pass tests but still contains defects. When users find defects in the software, most developers insist that their tests reveal no defects. This create an adversarial attitude between users and developers.

To have independent testers analyze requirements separately from developers can identify some requirements defects or missing informations. Typically, most users only give high-level requirements to developers and most developers want to derived their own requirements (often-undocumented) based on their own understanding of users’ needs. To have an independent testers review requirements would avoid this problem because testers must understand the requirement in detail. If they do not know the requirements, they can not create the tests or vice versa, if they can not test them, they do not know the requirements. Based on my experiences, this is the time where project can identify any inconsistent, incomplete, ambiguous requirements and fix them before moves into the next phase.

By understand the requirements well, independent testers can design test cases that test something which may not been considered by the developers in their designs. By having design test review, testers and developers can compare notes in detailed level. This activity can identify design defects either by developers or testers. By taking corrective actions to fix them before the implementation phase, the project can eliminate a lot of defects. This is the time where most duplicate components, redundant design activities can be identified. By having separate views, project team can check on interface design, proper use of entities and relationships, data and control flow, state transitions, to demonstrate that a design satisfies its requirements.

If project already has good requirements and design reviews that identify and fix most defects then implementation is usually easy. Defect injection during the coding phase are easy to fix by unit tests. I always believe that the source of most software defects is the lack of discipline in the way organizations build software. By applying strong software engineering disciplines such as having independent testing group, having more reviews, software projects can remove most defects in an orderly manner.