Running afoul of Brooks' Law in Quality Assurance

Quality assurance is critical to avoiding late software projects, the temptation to add additional staff, and running into Brooks' Law. The reality is that projects that are running late rarely turn the corner and finish on time. Quality assurance that's part of the project plan from the beginning (continuous testing) helps pinpoint problems in the beginning that would only grow more cumbersome and stubborn as the project develops.

Perhaps the biggest danger is allotting too much testing to the end of the project - the overhead of training and communicating is too great. Just like Brooks' Law posits that additional software engineering resources slow down a project that's already overdue, additional software testing resources will too. The same pitfalls of training and communication will befall your QA team.

Software testing also fits naturally at the end when the system is complete to ensure its viability and functionality, but it doesn't belong only at the end. The alloted time for thorough testing at the end is invariably used up in the middle of project development. Team members need to test their work as it progresses. Waiting until the end means there won't be enough time left to properly train testing staff and communicate testing procedures.

Quality assurance should span the entire development life cycle, from the time the project is analyzed and requirements are gathered to the end stages. Since 1975, we've seen a tremendous amount of change in software development. Yet Brooks' Law is still in effect after all these years. You can't force software testing in at the end of a project. It must be baked in at the beginning and continuously emphasized as the project unfolds.