Test: time well invested

During a hackathon I attended some years ago, a mentor emphasized the significance of early integration and testing to ensure the prototype's functionality during the demo. Interestingly, even in 1975, the importance of integration testing and the time investment it requires had already been acknowledged:

For some years, I have been successfully using the following rule of thumb for scheduling a software task:

• 1/3 planning
• 1/6 coding
• 1/4 component test and early system test
• 1/4 system test, all components in hand.

This differs from conventional scheduling in several important ways:

1. The fraction devoted to planning is larger than normal. Even so, it is barely enough to produce a detailed and solid specification, and not enough to include research or exploration of totally new techniques.

2. The half of the schedule devoted to debugging of completed code is much larger than normal.

3. The part that is easy to estimate, i.e., coding, is given only one-sixth of the schedule. In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose. Many of these were on schedule until and except in system testing. (The mythical man-month)