In 1975, IBM computer architect and software engineer Fred Brooks published “The Mythical Man-Month”, a book of essays on software engineering that has since become an industry classic. While much has changed over the past four decades in regards to virtually every component of software development, many of Brooks’ lessons still hold true. Here are five key software testing lessons from “The Mythical Man-Month.”
1. The More People Involved, The Longer the Process
*“Since software construction is inherently a systems effort—an exercise in complex interrelationships—communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men then lengthens, not shortens, the schedule” *
The central theme of “The Mythical Man-Month” is that “adding manpower to a late software project makes it later.” While it’s easy to assume that throwing more people at a task will propel it forward faster, in practice it slows progress considerably. Brooks asserts that the added weight of communication for a larger team — in addition to the time-cost of training new members — drags down the time to completion rather than speeding it up.
For software testing in particular, many teams find that adding more people to the testing team often slows down the overall QA process. Instead of adding headcount to their QA team, many continuous and Agile teams now opt to find ways to cut down on manual testing labor through automation, outsourcing or crowdsourcing.
2. Change is the Only Constant
“[S]ome changes in objectives are inevitable, and it is better to be prepared for them than to assume that they won’t come. Not only are changes in objective inevitable, changes in development strategy and technique are also inevitable. ”
Software testing is, by its nature, a dynamic endeavor. Codebases are constantly being updated, as are the apps they integrates with, the devices and operating systems users rely on and the needs of the customers. Recognizing that changes are inevitable and planning for them helps keep the team from constantly playing catch-up.
QA teams must be experts at adapting to change. Adopting a testing methodology that accommodates the fast pace of development is critical to having a QA strategy that truly ensures quality. QA teams should strive to create a testing infrastructure that is repeatable, easy to edit and fits into their overall development workflow.
3. There’s No Such Thing as “No More Bugs”
“Program maintenance involves no cleaning, lubrication, or repair of deterioration. It consists chiefly of changes that repair design defects. Much more often than with hardware, these changes include added functions. Usually they are visible to the user.”
While it may feel like the logical goal of testing is to eliminate every last bug before you ship, the reality is that there’s no way to guarantee that there isn’t a single defect left after testing. What’s more, the longer a product is on the market, the more likely it is for unknown bugs to surface. Brooks notes that as a product reaches wider adoption, users begin to use the product to its full potential, bringing users into contact with more and more edge cases.
The process of finding and resolving bugs in a product provides an ever-shifting target. For modern software teams who update code on a daily or weekly basis, a continuous testing strategy is critical to spotting bugs early on. As a result, they must implement regular smoke tests in production and focus testing on the areas of code that are changing regularly, e.g. features that rely on 3rd party integrations that may change without warning.
4. The Cost of Shipping Bugs is Real
“As a rule of thumb, I estimate that a programming product costs at least three times as much as a debugged program with the same function.”
Development teams can now ship bug fixes in a matter of minutes, making the risk of shipping each individual bug feel somewhat trivial. But the cost of shipping bugs is a real cost for teams. Brooks estimates that shipping buggy software can triple the overall cost of a product, making the value of a sufficient QA process significant. While deployment cadences have gotten faster since 1975, Brooks’ essential argument that bugs are expensive remains relevant.
Since shipping completely bug-free software is an impossible goal, development and QA teams must understand the business impact of any issue that they ship. Focusing a testing strategy on finding issues that will have the greatest impact on user experience helps minimize the overall cost of shipping bugs without overextending development resources.
5) Quality Needs an Owner
“The surgeon [chief programmer] will need a bank of suitable test cases for testing pieces of his work as he writes it, and then for testing the whole thing. The tester is therefore both an adversary who devises system test cases from the functional specs, and an assistant who devises test data for the day-by-day debugging.”
Brooks advocates for a team with specialized roles that complement each other and improve the overall effectiveness and productivity of the team. His suggested role of “tester” doesn’t necessarily imply that a team must have a full-time QA tester. Rather, it means that someone on the team must be responsible to the overall quality of the product.
No matter what your team’s makeup, assigning someone to own quality processes and testing helps to ensure that your quality expectations are fulfilled. Whether that person is a developer, a QA engineer, a product manager or something else, assigning quality assurance as a responsibility makes it a more tangible, actionable goal for the entire team.
Want more lessons on how to implement a QA strategy that keeps up with development? For a modern take on what matters most in software testing, check out the CTO’s Guide to Continuous Testing.
