Người phát triển phần mềm thường coi kiểm thử là bước cuối cùng trong qui trình phát triển để nhận diện và loại bỏ lỗi. Theo một báo cáo công nghiệp phần mềm, kiểm thử là pha tốn kém nhất của phát triển phần mềm và thường chiếm tới nửa lịch biểu và ngân sách của dự án, tuỳ theo tính găng của hệ thống. Bởi vì có nhiều lỗi cần được nhận diện và sửa, nhiều dự án thường chạy sau lịch biểu và tốn nhiều hơn là lập kế hoạch. Ngay cả với những kĩ thuật kiểm thử tốt nhất, một số lỗi vẫn thoát được và đi vào trong sản phẩm cuối cùng và rất tốn kém để sửa chúng.
Thực hành thông thường là để người phát triển hội tụ vào nỗ lực của họ trong thiết kế và viết mã. Người kiểm thử không tham gia vào cho tới khi người phát triển đã kết thúc việc viết mã. Điều đó là quá chậm và đó là lí do tại sao phần mềm có nhiều lỗi bởi vì không có đủ thời gian để kiểm thử kĩ lưỡng. Có niềm tin sai là người kiểm thử chỉ kiểm thử mã và họ không bắt đầu chừng nào mã chưa được làm xong. Đó là “kiểm thử về chất lượng” nhưng KHÔNG phải là “xây dựng theo chất lượng.”
Khái niệm “chất lượng dựng sẵn” yêu cầu người kiểm thử tham gia sớm khi dự án bắt đầu. Người kiểm thử nên tham gia vào trong mọi pha phát triển để đảm bảo rằng chất lượng là được “dựng sẵn” khi tổ phát triển phần mềm. Người kiểm thử phải tham gia vào trong pha yêu cầu để hiểu yêu cầu của khách hàng và chắc rằng chúng là đầy đủ và kiểm thử được. Với tri thức về yêu cầu, người kiểm thử có thể lập kế hoạch chiến lược kiểm thử và phát triển kế hoạch kiểm thử tương ứng. Người kiểm thử phải tham gia vào trong pha kiến trúc để xác định thuộc tính chất lượng của hệ thống (Hiệu năng, tính đổi qui mô, tính dùng lại được, và tính bảo trì được v.v.) và phải chắc rằng sản phẩm phần mềm đáp ứng cho các yêu cầu và mục đích doanh nghiệp. Người kiểm thử cũng phải tham gia vào trong pha thiết kế để hiểu cấu trúc của thiết kế phần mềm như các cấu phần của phần mềm, các tính chất của những cấu phần này cũng như mối quan hệ giữa chúng. Từ tri thức này, những người kiểm thử có thể thiết kế các trường hợp kiểm thử, kịch đoạn kiểm thử cũng như chắc chắn thiết kế đáp ứng các tiêu chí chất lượng. Khái niệm “chất lượng dựng sẵn” coi người kiểm thử là phần bản chất của tổ phát triển và làm việc song song với người phát triển để chắc chất lượng là “được dựng sẵn” trong mọi bước của phát triển. Chỉ bằng việc làm điều đó, những người kiểm thử có thể giúp giảm số lỗi trong sản phẩm cuối cùng và đảm bảo sản phẩm có chất lượng.
Trong khái niệm “chất lượng dựng sẵn” này, người kiểm thử được coi là những thành viên tổ có kinh nghiệm và chuyên nghiệp, người làm việc song song với người phát triển để chắc rằng phẩm chất là một phần mấu chốt của việc phát triển. Trong các công ti xây dựng các hệ thống mấu chốt chất lượng cao, người kiểm thử được xếp hạng cao hơn người phát triển nhiều và thường được chọn lựa từ những người phát triển giỏi nhất trong công ti. Báo cáo công nghiệp thấy rằng bằng việc có những người kiểm thử có kinh nghiệm làm việc bên cạnh người phát triển, những công ti này có thể giảm số lỗi tới 80% và đảm bảo sản phẩm chất lượng cao.
Khái niệm về có người kiểm thử tham gia muộn trong quá trình phát triển và chỉ kiểm thử mã về lỗi là chọn lựa kém mà thường dẫn tới sản phẩm chất lượng kém với chi phí cao hơn. Khái niệm chất lượng “được xây dựng sẵn” bằng việc để người kiểm thử tham gia sớm vào trong qui trình phát triển và làm việc bên cạnh người phát triển để nhận diện và loại bỏ lỗi là một chọn lựa tốt và có ý nghĩa doanh nghiệp tốt hơn. Tuy nhiên vấn đề còn lại là bao nhiêu công ti sẽ đầu tư vào khái niệm “chất lượng được dựng sẵn” và coi người kiểm thử như nhân tố then chốt trong phát triển phần mềm?
—-English version—-
The “built-in quality” concept
Software developers often consider testing as the last step in the development process to identify and remove defects. According to a software industry report, testing is the most expensive phase of software development and often account for half of a project’s schedule and budget, depending on the criticality of the system. Because there are so many defects to be identified and fixed, many projects often run behind schedules and cost more than planned. Even with the best testing techniques, some defects still escape and get into the final products and it is very expensive to fix them.
The common practice is for developers to focus their efforts on designing and coding. Testers do not get involved until developers have finished coding. That is too late and that is why software has many defects because there is not enough time to test thoroughly. There is a false belief that testers only test the code and they do not start until the code is done. That is “testing for quality” but NOT “build in quality.”
The “Build-in quality” concept requires testers to involve early when the project begins. Testers should involve in all development phases to ensure that quality is “built in” as the team develops software. Testers must participate during the requirements phase to understand customer’s requirements and make sure that they are complete and testable. With the knowledge of the requirements, testers can plan testing strategy and develop test plans accordingly. Testers must involve in the architecture phase to determine the quality attributes of the system (Performance, scalability, usability, and maintainability etc.) and make sure that the software products meet the requirements and business goals. Testers must also involve in the design phase to understand the structure of the software design such as the components of the software, the properties of those components as well as the relationships among them. From this knowledge, testers can design test cases, test scripts as well as make sure the design meet the quality criteria. The “Build in quality” concept considers testers as an essential part of the development team and works in parallel with developers to make sure quality is “built-in” every step of the development. Only by doing that, testers can help to reduce numbers of defect in the final product and ensure a quality product.
In this “Built in quality” concept, testers are considered experienced and professional team members who work in parallel with developers to make sure that quality is a critical part of the development. In companies that build high quality critical systems, testers are ranked much higher than developers and usually selected from the best developers in the company. The industry report found that by having experienced testers work side by side with developers, these companies can reduce the numbers of defects by 80% and ensure high quality products.
The concept of having testers participate late in the development process and only test the code for defects is a bad choice that often leads to poor quality products that higher cost. The “Build in” quality concept of having tester participate early in the development process and work side by side with developers to identify and remove defects early is a good choice and better business sense. However the question remains as how many companies would invest in the “build in quality” concept and consider testers as the key factor in software development?
