Tôi nhận được một email từ một sinh viên phần mềm năm thứ nhất, cô ấy hỏi: “Có bao nhiêu kiểm thử phần mềm trong dự án phần mềm? Cái gì cần được đưa vào trong kế hoạch kiểm thử? Các kiểm thử này được tiến hành theo trật tự nào? Xin thầy giúp đỡ.”
Đáp: Mục đích của kiểm thử phần mềm là đánh giá chất lượng của công việc được thực hiện ở từng bước của qui trình phát triển phần mềm. Người quản lí kiểm thử phải lập kế hoạch kiểm thử lúc bắt đầu của dự án đồng thời với lúc người quản lí dự án lập kế hoạch cho các hoạt động dự án. Bản kế hoạch kiểm thử nên bao gồm các thủ tục kiểm thử, trường hợp kiểm thử, thông tin lỗi, lịch biểu kiểm thử, và dữ liệu hiệu năng được dùng cho kiểm thử phần mềm. Người kiểm thử KHÔNG nên chờ đợi kiểm thử mọi thứ ở lúc cuối của nỗ lực phát triển, sau khi viết mã đã được thực hiện. Họ phải làm việc với người phát triển qua qui trình phát triển để đảm bảo rằng phần mềm được phát triển như dự định, và để cải tiến chất lượng, tính tin cậy và tính bảo trì phần mềm.
Việc kiểm thử phần mềm thường bắt đầu ở mức cấu phần (kiểm thử đơn vị, kiểm thử chức năng) rồi đi lên tới sản phẩm phần mềm (kiểm thử tích hợp, kiểm thử rà lại, kiểm thử hệ thống, kiểm thử chấp nhận v.v). Trong dự án nhỏ, những người phát triển thường làm cả việc viết mã và kiểm thử. Trong dự án lớn hơn, nên có nhóm kiểm thử độc lập làm kiểm thử để tránh thiên lệch của người phát triển khi làm kiểm thử công việc riêng của họ. Điều này không có nghĩa là người phát triển không kiểm thử và người kiểm thử phải làm mọi kiểm thử. Về căn bản, cả người phát triển và người kiểm thử đều phải làm việc cùng nhau trong toàn dự án để đảm bảo rằng mọi kiểm thử được tiến hành đúng. Người phát triển phải kiểm thử mã riêng của họ để loại bỏ các lỗi, đảm bảo thực hiện đúng, và luồng thông tin cũng như kiểm tra dữ liệu để đảm bảo rằng tính toàn vẹn được bảo trì. (như kiểm thử mô đun, kiểm thử đơn vị) trước khi người kiểm thử bắt đầu các hoạt động kiểm thử của họ.
Người kiểm thử thường bắt đầu bằng “kiểm thử chức năng” để làm lộ ra các lỗi chức năng trong phần mềm rồi tiến hành “kiểm thử tích hợp” để đảm bảo mọi chức năng làm việc đúng và luồng thực hiện đang xảy ra như dự định. Người kiểm thử phải tiến hành “kiểm thử nội dung thông tin” để kiểm lỗi trong cấu trúc dữ liệu cục bộ hay toàn cục. Họ phải kiểm thử “tính toàn vẹn giao diện” để chắc cả giao diện trong và ngoài làm việc đúng, đặc biệt khi mô đun mới được thêm vào cho phần mềm. Khi thay đổi xảy ra, họ phải tiến hành “kiểm thử rà lại” để kiểm các lỗi có thể lan truyền từ mô đun nọ sang mô đun kia và đảm bảo toàn bộ sản phẩm phần mềm làm việc được.
Sau khi thẩm tra rằng sản phẩm phần mềm làm việc đúng, người kiểm thử có thể tiến hành “kiểm thử hệ thống” để chắc cả phần cứng và phần mềm đều làm việc như đã lập kế hoạch. Trong kiểm thử này, người kiểm thử sẽ cho chạy “kiểm thử an ninh” để thẩm tra bảo vệ hệ thống chạy đúng để ngăn cản việc thâm nhập không đúng hay thay đổi dữ liệu. Họ tiến hành “kiểm thử chịu căng thẳng” để kiểm tra xem nó giải quyết tốt đến đâu với nhưng yêu cầu tài nguyên bất thường (như, chất lượng, tần xuất, hay khối lượng) và “kiểm thử hiệu năng” để kiểm tra hiệu năng khi chạy của phần mềm, đặc biệt phần mềm thời gian thực. Họ có thể tiến hành “kiểm thử phục hồi” để kiểm tra khả năng của hệ thống phục hồi từ hỏng hóc.
Nếu mọi kiểm thử trong “kiểm thử hệ thống” đều qua được, người kiểm thử có thể làm việc cùng khách hàng để chuẩn bị cho “kiểm thử chấp nhận” nơi họ đảm bảo phần mềm làm việc đúng với người dùng được dự định trong môi trường làm việc của họ. Hai kiểm thử chính trong thời gian này: “kiểm thử Alpha” là thời kì kiểm thử mà sản phẩm phần mềm sẵn sàng được dùng trong “môi trường kiểm thử” của khách hàng nhưng có thể có một số lỗi nhỏ. Nó là cơ hội cuối cùng để được trắc nghiệm từ khách hàng rằng phần mềm làm việc như được dự định. “Kiểm thử Beta” là thời kì kiểm thử trong đó sản phẩm phần mềm là đầy đủ không có lỗi và dùng được trong môi trường “sản xuất”. Mục đích của kiểm thử Beta là kiểm thử khả năng của công ti hỗ trợ cho sản phẩm. Kiểm thử Beta phục vụ như bằng chứng rằng sản phẩm phần mềm là sẵn sàng cho việc gửi đi cho mọi khách hàng.
—-English version—-
Software testing process
I received an email from a first-year software student where she asked: “How many software tests are there in a software project? What should be included in a test plan? In which order these tests are conducted? Please help.”
Answer: The purpose of software testing is to evaluate the quality of work performed at each step of the software development process. Test manager must plan testing at the beginning of the project at the same time when project manager plans project activities. The test plan should include test procedures, test cases, defect information, test schedule, and performance data used to test software. Testers should NOT wait to test everything at the end of a development effort, after coding is done. They must work with developers throughout the development process to ensure that the software is developed as intended, and to improve software quality, reliability and maintainability.
Software testing usually begins at the component levels (Unit test, Function test) then move up to the software product (Integration test, Regression test, System test, Acceptance test etc.). In small project, developers usually do both coding and testing. In larger project, there should be an independent test group to do testing to avoid the bias of developers testing their own works. This does not mean developers do not test and testers must do all tests. Basically, both developers and testers must work together throughout the project to ensure that all tests are conducted properly. Developers must test their own code to remove defects, ensure proper execution, and information flow as well as examine data to ensure that integrity is maintained. (i.e., Module Test, Unit test) before testers start their testing activities.
Testers often start with “Functional Test” to uncover functional defect in the software then proceed to “Integration Test” to ensure all functions are working properly and the flow of execution is happening as intended. Tester should conduct “Information Content Test” to check for errors in local or global data structures. They must test for “Interface Integrity” to make sure both internal and external module interfaces are properly working, especially when new module is added to the software. When changes happen, they must conduct “Regression Test” to check for defects that may propagate from one to other modules and ensure the entire software product is working.
After verify that software product is working properly, testers can conduct “System Test” to make sure both hardware and software is working as planned. In this test, testers will run “Security test” to verify that the system protection is running properly to prevent improper penetration or data alteration. They conduct “Stress Test” to check to see how well it deals with abnormal resource demands (i.e., quantity, frequency, or volume) and “Performance Test” to check the run-time performance of software, especially real-time software. They may conduct “Recovery test” to check the system’s ability to recover from failures.
If all tests within “System Test” pass, testers can work with customers to prepare for “Acceptance test” where they make sure the software works correctly for intended users in their work environment. There are two major tests during this time: “Alpha test” is the test period during which the software product is ready to be used in a customer’s “test environment” but may have some minor defects. It is the final chance to get verification from customers that the software is working as intended. “Beta test” is the test period during which the software product is complete without defect and usable in a “production” environment. The purpose of the Beta test is to test the company’s ability to support the product. Beta test serves as a proof that the software product is ready for shipment to all customers.
