Trong pha lập kế hoạch dự án, người quản lí dự án phải quyết định những cái gì được kiểm thử dựa trên bản Đặc tả yêu cầu phần mềm Software Requirements Specification (SRS). Đây là lúc người lãnh đạo kiểm thử và người quản lí dự án làm việc cùng nhau để tạo ra bản kế hoạch kiểm thử phần mềm Software Test Plan (STP) mô tả cho phạm vi, khuôn khổ kiểm thử, phương pháp kiểm thử, lịch biểu kiểm thử, chức năng được kiểm thử hay không kiểm thử, kiểu kiểm thử nào cần được thực hiện ở các pha khác nhau của vòng đời, môi trường cho kiểm thử, và phân công cho từng người kiểm thử.
Trong pha yêu cầu, thành viên tổ kiểm thử phải kiểm thử bản đặc tả yêu cầu kiểm thử (SRS) và bản kế hoạch kiểm thử phần mềm (STP) để chắc chắn rằng họ hiểu các yêu cầu và điều gì cần được kiểm thử. Họ sẽ thêm nhiều chi tiết vào bản kế hoạch kiểm thử phần mềm để chắc chắn rằng họ đã bao quát mọi chức năng phải được kiểm thử. Sau khi được hoàn thành, bản kế hoạch kiểm thử được sửa đổi sẽ được gửi cho tổ phát triển kiểm điểm để đảm bảo tính đúng đắn, tính đầy đủ của bản kế hoạch này. Cả hai tổ sẽ thảo luận thông tin liên quan tới lịch biểu dự án và phối hợp các hoạt động phát triển với hoạt động kiểm thử. Điều này là quan trọng vì cả người phát triển và người kiểm thử phải làm việc cùng nhau trên các trường hợp kiểm thử, dữ liệu kiểm thử, kịch đoạn kiểm thử cũng như kiểm thử phụ để đảm bảo rằng sản phẩm cuối cùng sẽ đáp ứng yêu cầu của khách hàng. Bản kế hoạch kiểm thử phần mềm được sửa đổi cũng sẽ được gửi tới khách hàng để kiểm điểm và chấp thuận. Một khi được chấp thuận, nó có nghĩa là nếu mọi kiểm thử đều qua được, sản phẩm phần mềm đáp ứng yêu cầu của khách hàng.
Trong pha thiết kế phần mềm, khi người phát triển đưa nhiều chi tiết vào trong thiết kế, người kiểm thử phải làm việc cùng người phát triển để bổ sung thêm chi tiết cho bản kế hoạch kiểm thử và trường hợp kiểm thử. Họ phải xác định kiểm thử nào có thể được tự động hoá và kiểm thử nào phải được thực hiện thủ công. Đây cũng là lúc để nhận diện mọi vấn đề rủi ro và lập kế hoạch giảm nhẹ chúng. Tổ kiểm thử phải xác định dữ liệu kiểm thử cho từng trường hợp kiểm thử, dựng kịch đoạn kiểm thử cho mọi kiểm thử tự động và sửa lại lịch biểu kiểm thử, nếu cần.
Trong pha viết mã, khi người phát triển làm việc trên mã của họ và chuẩn bị kiểm thử của họ (kiểm thử đơn vị và kiểm thử chức năng), người kiểm thử cũng phải hoàn thành mọi trường hợp kiểm thử của họ, các kịch đoạn kiểm thử, bộ dẫn lái kiểm thử và các kiểm thử phụ khác được yêu cầu trong bản đặc tả yêu cầu phần mềm (SRS) chẳng hạn, kiểm thử an ninh, kiểm thử găng, kiểm thử khói và kiểm thử hiệu năng v.v..
Trong pha kiểm thử, sau khi người phát triển hoàn thành kiểm thử đơn vị và kiểm thử chức năng của họ, tổ kiểm thử phải thực hiện mọi kiểm thử còn lại kể cả trường hợp kiểm thử găng và kiểm thử hiệu năng, mọi kết quả đều phải được làm tài liệu như số lỗi, số các kiểm thử qua được hay không qua được, tình trạng của lỗi, nếu cần người kiểm thử cũng phải sửa đổi lại các trường hợp kiểm thử hay thêm các trường hợp kiểm thử mới (Nếu có thay đổi yêu cầu hay thay đổi mã) và kiểm thử lại các trường hợp kiểm thử và thực hiện kiểm thử rà lại. Tổ kiểm thử cũng phải chuẩn bị cho kiểm thử chấp phận được tiến hành trong môi trường của khách hàng cũng như bất kì cái gì phải được trắc nghiệm.
Sau khi dự án được hoàn thành, tổ kiểm thử phải đánh giá mọi hoạt động kiểm thử, qui trình và kế hoạch kiểm thử cho cải tiến tương lai. Trong pha này, tổ kiểm thử sẽ phân tích qui trình kiểm thử của mình và làm tài liệu những điều tốt và những điều xấu. Họ phải chắc chắn rằng nếu họ phạm bất kì sai lầm nào, nó sẽ không lặp lại trong dự án tương lai. Không dự án nào là hoàn hảo, không kiểm thử nào là hoàn hảo cho nên bao giờ cũng có cơ hội cho cải tiến và họ càng có thể cải tiến nhiều, họ sẽ càng làm tốt hơn lần sau. Kiểm thử là chức năng quan trọng của bất kì tổ chức phần mềm tốt nào và có tổ kiểm thử tốt hơn, người ta có thể mong đợi sản phẩm chất lượng tốt hơn.
Several of you have asked me about testing and its relationship to the software development life cycle. Basically testing follows a life cycle that corresponds to every phase of the development life cycle.
During the project planning phase, the project manager must decide what things to be tested based on the Software Requirements Specification (SRS). This is the time where the test leader and the project manager work together to create the Software Test Plan (STP) that describe the scope, the testing framework, test method, test schedule, function to be tested or not tested, what types of test to be done at different phases of the life cycle, the environment for testing, and the assignment for each tester.
During the requirement phase, test team members must review the Software Requirements Specification (SRS) and the Software Test Plan (STP) to make sure that they understand the requirements and what should be tested. They will add more details to the Software Test Plan to make sure that they have covered all functions that must be tested. After completed, the revised Software Test Plan will be sent to the development team for review to ensure the correctness, completeness of the plan. Both teams will discuss information regarding project schedule and coordinate development activities with the test activities. This is important since both developers and testers must work together on test cases, test data, test scripts as well as any additional tests to make sure that the final product will meet customer’s requirement. The revised Software Test Plan will also be sent to customer for review and approval. Once approved, it means that if all tests pass, the software product meets the customer’s requirements.
During the software design phase, as developers put more details into the design, testers must work with developers to add more details to the test plan and test cases. They have to determine which tests can be automated and which one must be done manually. This is also the time to identify any risk issues and plan to mitigate them. Test team must define test data for each test case, build the test scripts for all automated tests and revise testing schedule, if needed.
In the coding phase, as developers working on their codes and prepare their tests (Unit tests and Functional tests), testers must also complete all their test cases, test scripts, test drivers and other additional tests as required in the Software requirement specification (SRS) for example, Security test, Stress test, Smoke test, and Performance test etc.
In the testing phase, after the developers complete their unit tests and functional tests. Test team must execute all remaining tests including stress and performance test cases, all results must be documented such as number of defects, number of tests passes or failed, status of defects, if needed testers must also revise test cases or add new tests cases (If there are requirements changes or code changes) and retesting test cases and perform regressing tests. Test team must also prepare for acceptance tests conducted in customer’s environment as well as anything that must be verified.
After the project is completed, the test team must evaluate all testing activities, testing process and plan for future improvement. In this phase, the test team will analyze its testing process and document good things and bad things. They must make sure that if they made any mistake, it will not be repeat in future projects. No project is perfect, no test is perfect so there always be opportunity for improvement and the more they can improve, the better they would do next time. Testing is an important function of any good software organization and having better testing team, the better quality product can be expected.
