Software testing is a costly – but important – activity, as any software developer knows. While it’s a necessity, there are a number of ways that organizations can carry out testing. Automated testing, which requires significant investment but reduces required effort, and manual testing, which is labor intensive but the more common approach. Both techniques can be effective, but they also both have their own set of challenges, including technical debt.
Exploratory testing (ET) is a type of manual testing. The IT Pro article, “Exploratory Testing as a Source of Technical Debt,” examined this technique for a better understanding of the technical debt it creates.
Using this technique, testers run tests based on their intuition and knowledge of the system, which requires less test documentation and planning – it’s a flexible system that is most useful when there is only limited time available for testing. As a testing technique, ET is known to be quite cost effective – at least to begin with – but it can also increase the amount of work that has to be redone, creating additional costs.
The diagram below, recreated from IT Pro, illustrates how ET results in technical debt, and the type of technical debt created.
Source: IT Pro, "Exploratory Testing as a Source of Technical Debt"
Technical debt is not necessarily bad, nor is it entirely avoidable. The article notes three methods for dealing with technical debt, as proposed by Frank Buchman:
- Paying the interest: Deal with the debt and the additional costs associated with it, on a regular basis.
- Repaying the debt: Rework the system to eliminate the source of technical debt.
- Converting the debt: Replace the source of technical debt with another solution that results in less debt.
Regardless, management will need a strategy for dealing with it, which may mean adjusting testing techniques. With both structured and unstructured techniques available, like ET, it is up to management to choose a solution that best fits the project at hand.
For more information about technical debt, check out our Trusted Advisor report, What is Technical Debt and What Should We Do About It?
Of course, if you’re interested in new ways to improve your testing processes, you may be interested in the Test Maturity Model integration (TMMi) framework. The framework focuses on defect prevention, not detection, to help you find and fix errors more effectively.
Read the IT Pro article: Exploratory Testing as a Source of Technical Debt