Costs of Defect Fixing at Different Stages of Development

Blog Image

Bugs are an inevitability in software development as people are always doomed to make mistakes. If we accept this, then instead of trying to stop defects occurring, we should focus our efforts on detecting them in the early stages when they are cheaper to fix.


In this stage of the project cycles, a bug is discovered by the developer before their development unit is integrated with the rest. The overall cost of the bug to the project is minimal for two reasons: one, only one person is involved in discovering and fixing the bug, and two, that person is actively working with that piece of development so they will be quick to understand what went wrong and where. This is considerably cheaper than the process of fixing a bug if it is discovered in later stages, so it is of high priority to rigorously test the software even as early as this.

Code Integration

After the code has been integrated and a defect is discovered, the process of fixing the defect is already more demanding. The system engineer in charge of code integration process will need to investigate what code from the last integration cycle is causing the defect. They would then need to go reverse the integration process for that piece of code to retrieve it from the integrated system and inform the developer that a fix is required. The developer, who has already moved on to the next task, has to go back to that code, fix it and resubmit it for integration. It is obvious to see that the cumulative time to fix a fault between the two project resources involved is at least two or three times higher than in the development phase.


If a fault is discovered during the testing phase it will take up the time of yet more members of the project team. Other than developers and system engineers two more profils are sapping resources in fixing the bug: a quality assurance tester and the project manager.

The quality assurance tester must attempt to recreate the bug, logging each step he takes in doing so.The project manager needs to assess the defect and pass it back to the development team. Then once it has been fixed, the code must be re-entered into the test environment, where all the previous tests must be reperformed to make sure no new issues have been created by the repairing process. Finally the bug must be updated into a bug tracking system.


During the user acceptance testing stage, the developers would require a UA tester to explain a bug found to the systems tester. The systems tester then has to try and reproduce the fault to decide if it is a bug or if the program is working as it should. If the systems tester can reproduce the bug, the process needs to be documented thoroughly and afterwards they must meet with the developers to discuss their findings. When the developer has fixed the defect, the code must be reintegrated into the test environment where testing has to be redone. Finally the code must be entered into the UAT environment to resume user acceptance testing.

The bugs discovered at this stage have further sensitivity as they give the users a glimpse into the quality of the software that is delivered to them. It is not unusual that if the number of bugs found is bigger than expected, the whole UAT process is terminated. If this happens, the development team is then asked to assess the reasons for poor quality, rethink their QA process (or even the software architecture itself), and come back to the UAT team once the quality issues have been thoroughly and fundamentally addressed. The overall cost, therefore, can go far beyond the IT resource costs: it is now ‘time to market’ that is the most significant cost, where the business is losing money due to the delayed delivery of their software.


A defect that shows up during live usage of software will stop or atleast seriously affect the process it is supposed to aid. If your ecommerce site stops processing orders, well... no orders will be processed until the issue has been fixed (unless you have a manual fallback procedure). So talking about the costs of bugs that make it to production is mainly about the costs of your business not functioning. The previously discussed IT costs of fixing the bug, which will now be increased by the costs of the support staff involved in the process, can pale into insignificance when compared to the overall costs to the business.

What can be done?

This brief analysis ultimately shows that a great deal of time and money can be very easily wasted by failing to discover bugs in the early stages of development. As a rule of thumb, you can expect that the costs of fixing defects will at least double at each further phase of the project.

To prevent defects from being discovered at later stages, rigorous testing must be performed at all points in the development of software. If this testing is not done frequently enough, then it increases the chances of a bug slipping through the cracks and costing you significant money further down the line.

Leave a reply

Your email address will not be published. Required fields are marked*