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 contract between the testers and the project team describing the role of testing in the project. The purpose of 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 test plan is made by taking inputs from the product development team, keeping in consideration the project deadlines and risks involved while testing the product or components of the product.
The steps in creating 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 following things:
i. Type of test to be implemented and its 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 above things which is 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 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 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 leave. If this module for apply leave is not ready, we need to create a driver (which will apply for leave) in order to test the approve leave functionality.
Top down Integration Testing:
Modules are tested by moving downwards in control hierarchy, beginning with 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 component.
Eg: In Leave Management System, once leave is approved, the leave status can be seen in leave report. So we need to create a dummy implementation of a leave report (stub).