Software bug can be found at any phase of the development process. It also can be found later by external beta testers or (that is the worst) by luckless client after the release.
It is well-known fact that on these latter phases it gets much costly to change something, when shipping dates slip, and the organization can lose clients as well as funds.
But well-planned development cycle with a fully thought-out architecture permits the organization to make software inexpensive. It is a proven fact.
Having a plan means that you have the luxury of defining the best possible step when certain software bugs should be fixed.
Finding 100 bugs a year before the product is released is not a big trouble. The work that must be done in order to address the defects can be scheduled in with other necessary work.
Finding 100 bugs the day after shipping the software product means a very high cost will be incurred to fix them. Not only will they probably be scattered throughout the code, necessitating that a lot of fields to be touched, but the changes will need to be redeployed either to the servers hosting them, downloaded to the clients, or even new CDs burnt and shipped to clients. The cost of supporting clients and fielding their calls when they recognize the defects prior to fixes being in place only adds to the price of late bugs.
Looking through the specifications and identifying the fields of risk are right methods to amend the general quality of the software product.
One of the most recent studies executed by the U.S. Department of Commerce demonstrated that software bugs cost the U.S. economy alone an evaluated $59.5 billion a year.
Betterments in software testing are able to decrease this cost by a third part. Taking into account that the study went on to demonstrate that more than a third part of the $59.5 billion was cost-incurred by the development effort or the vendors, a more firm testing effort would decrease that emphatically.