How do you develop a test plan and schedule?
How do you develop a test plan and schedule? Describe bottom-up and top-down approaches.
A test plan is a contract between the testers and the project team describing the role of testing in the project. The purpose of the test plan is to prescribe the scope, approach, resources, and schedule of the testing activities. To identify items being tested, the feature to be tested, the testing task to be performed, the personnel responsible for each task, and the risks associated with the plan. From this, it is imperative that the test plan is made by taking inputs from the product development team, keeping into consideration the project deadlines and risks involved while testing the product or components of the product.
The steps in creating a test plan are:
1. Identifying requirements for Test: This includes tests for Functionality, Performance, and Reliability, etc.
2. Assess Risk and Establish Test Priorities: In this step, risks are identified and risk magnitude indicators (high, medium, low) are assigned.
3. Develop Test Strategy: This includes the following things:
i. Type of test to be implemented and it’s objective
ii. Stage in which test will be implemented
iii. Test Completion Criteria
When all these 3 steps are completed thoroughly, a formal document is published stating the above things which are known as “Test Plan”.
Bottom-up Integration Testing:
The program is combined and tested from the bottom of the tree to the top. Each component at the lowest level of the system hierarchy is tested individually first, then the next component is to be tested. Since testing starts at the very low level of software, drivers are needed to test these lower layers. Drivers are simply programs designed specifically for testing that make calls to these lower layers. They are developed for temporary use and need to be replaced when the actual top-level module is ready.
Eg: Consider a Leave Management System. In order to approve leave, there has to be a module to apply for leave. If this module for apply leave is not ready, we need to create a driver (who will apply for leave) in order to test the approved leave functionality.
Top-down Integration Testing:
Modules are tested by moving downwards in the control hierarchy, beginning with the main control module. A module being tested may call another that is not yet tested. For substituting lower modules, stubs are used. Stubs are dummy modules developed to test the control hierarchy. Stubs are special-purpose programs that simulate the activity of missing components.
Eg: In Leave Management System, once leave is approved, the leave status can be seen in the leave report. So we need to create a dummy implementation of a leave report (stub).