Understanding Technical Debt in Software Testing: Why is it important for Productive Software Testing in Future
Managing technical debt has been one of the most emerging problems for the current general of software testers, especially those organizations that develop and maintain large software systems. Similar to a bad debt in the financial industry, the term was devised by Ward Cunningham to draw an analogy with financial debt to indicate how incurring debt in the short run is beneficial but hurts badly in the long run if not repaid. Basically, the term was meant to remedy the practice of making non-optimal technical decisions.
Technical debt usually occurs when teams knowingly or unknowingly make technical decisions in return for short-term gains in their projects. The test dimension of technical debt is known as ‘test technical debt’ or ‘test debt’ for short.
What is Technical Debt?
Ward Cunningham coined the term ‘technical debt’ wherein long-term software quality is traded for short-term gains in development speed. We incur financial debt when we take a loan. The debt does not cause problems as long as we repay the debt. However, if we do not repay debt, the interest on the debt keeps building over a period of time and finally, we may land in a situation where we are not in a position to repay the accumulated financial debt leading to financial bankruptcy. Technical debt is akin to financial debt. When we take shortcuts during the development process either knowingly or unknowingly, we incur debts. Such debts do not cause problems when we repay the debt by performing refactoring to address the shortcut. If we keep accumulating technical debts without taking steps to repay it, the situation leads the software to “technical bankruptcy”.
A high technical debt in a software project impacts the project in multiple ways. If neglected, technical debt can lead to a broad spectrum of difficulties, from collapsed roadmaps to an inability to respond to customer problems in a timely manner. Specifically, the Cost of Change (CoC) increases with increasing technical debt that leads to poor productivity. In addition, it starts the vicious cycle where poor productivity leads to more focus on features (rather than associated quality) in the limited time, and that leads to more technical debts due to time constraints. Apart from technical consequences, high technical debt impacts the morale and motivation of the development teams in a negative manner.
Causes of Technical Debt
There are several well-known causes that lead to technical debt, including:
- Schedule pressures.
- Lack of skilled engineers.
- Lack of documentation.
- Lack of process and standards.
- Lack of test suite.
- Delayed refactoring.
- Lack of knowledge
Test Debt under Manual Testing
In manual testing, test engineers execute test cases by following the steps described in a test specification. Here is a list of common contributors to test debt that relates to manual testing.
- Limited test execution– Many a time, the available resources and time to carry out complete and comprehensive testing is not sufficient. Hence, testers execute only a subset of tests for a release (i.e., a shortcut), thereby increasing the possibility of residual defects.
- Improper test design– Manual testing is a time consuming and arduous process. A test case could be designed with a lot of variations using different data combinations but then it is necessary for the tester to execute all these combinations. Since the execution of all combination of test cases is a laborious process for testers, they restrict themselves to few happy scenarios for testing taking a shortcut in test design. This increases the risk of residual defects in the System Under Test (SUT).
- Missing test reviews– Test reviews help to improve the quality of test cases and also help in finding the problems earlier. Missing test review could delay finding defects or increase maintenance of test cases.
Test Debt in Automation Testing
Automation testing involves executing pre-scripted tests to execute and check the results without manual intervention. The list of factors that contribute to test debt in automation testing is as follows-
- Inappropriate or inadequate infrastructure– Tests conducted in infrastructure not resembling customer’s infrastructure could lead to unpredictable behaviour of the software resulting in reduced confidence in the system.
- Lack of coding standards– Automated tests need to adhere to a common coding standard. When a common coding standard is not adopted and followed, it increases the effort to maintain the test code.
- Unfixed (broken) tests– Not fixing broken tests or tests not being updated when functionality changes reduce confidence on the tests, decreases quality and increases maintenance effort.
- Using record and replay– It is easy to use record and replay tools for testing Graphical User Interface (GUI) applications. However, using record and replay has numerous drawbacks. Better alternatives may be available to use instead of record and replay tools.
Given the vital role that testing plays in the software development process and the impact test debt can have on software projects, test debt and corresponding management techniques deserve more focus for developing high-quality software in industrial contexts.
Connect with KiwiQA to leverage focused capability for focused QA and Testing services.
