“Technical Debt” is a term that has been used for some years now to define the amount of unwanted issues that are knowingly placed into the live environment, i.e. knowingly introducing errors that have not been resolved. The term is also used to refer to the amount of damage that currently exists within the live environment, ignoring the fact that each project that releases to live with known issues, that are not scheduled for resolution, increases the technical debt for the organization.
Tools can be used to assess code and realize the extent of the organization’s Technical Debt but this ignores the fact that the debt is a moving target and that the cause of a lot of this increase is the release of new, known defects into production.
Using known valuations for the incremental impact of defects, dependent on their severity, Test is in a brilliant position to be able to not only identify the problems but to put an estimate on the cost of resolving these issues in the future.
For example; if we assume that we are running with 4 levels of defect criticality, Very High, High, Medium and Low, we can assume the cost of resolving these in the future is as follows:
Low Defect = £100
Medium Defect = £1,000
High Defect = £10,000
Very High Defect = £100,000
By multiplying the volume of defects by the associated value, Test can estimate the value of the Technical Debt. It is quite normal to expect that the lower the severity, the more defects may be considered acceptable to place into live. However, even high numbers of mid-level severity defects can cause an ongoing issue.
Let’s assume an example case where there are 32 low level defects, 15 medium level defects, 5 high level defects and 1 very high level defect. This would equate to an estimated Technical Debt as follows:
So why is the cost so high? Imagine that the one remaining Very High issue is the one that causes a problem. Being Very High it could cause a cessation of service. This will have a direct impact on the organization, be it a website that can no longer take orders, or a series of customer services personnel that cannot use the broken system. The organization is now in emergency fix mode and lots of people have been called into action in order to resolve the problem. Developers are being called in, operations are creating task forces to deal with issue and business work arounds are being put in place. Perhaps the software version needs to be rolled back to an earlier version not exhibiting the problem or maybe a project needs to be defined to create a fix for the problem. The impact to the business coupled with the amount of people involved reaches the £100,000.00 figure very quickly.
Testing as a discipline requires that defects are identified prior to going live but the business often demands that the change be implemented as quickly as possible, despite the issues that have been identified. Testing applies as standard as a series of constraints called exit criteria which are there to protect the business from themselves. If the exit criteria is not met, the Technical Debt should be used as a means of identifying to the business the potential ramifications of placing software live before major issues have been resolved.
From a testing perspective we are there to bring awareness and allow the organization to make informed decisions regarding the risks that they are taking. If they still wish to proceed knowing these issues, then that is acceptable. What is not acceptable is the business being ignorant of the situation that they are potentially entering and the associated risk they are taking. Always make the reasons for exit failure a known situation and put it into business terms that the end users can understand.
