technical debt
"Technical Debt" is a term used to describe inadequate software. It is intended to express the problem of inadequate software quality in business categories. 1. It is intended to show managers that failures in software development have negative consequences that cost them later. The term debt is a reminder that you will have to pay it off at some point. The amount of software debt of a project is measurable. It can be expressed as an absolute cost number or relative to the development cost of the project in question.
The term was coined by Ward Cunningham at the OOPSLA meeting in 1992. "Technical Debt" in Cunningham's original sense is "all the not quite right code which we postpone making it right". 2. By this he meant the internal quality of the code. Later, the term was expanded to mean all that belongs to a proper software system but is postponed because of time constraints. In his book "Managing Software Debt - Building for Inevitable Change", C. Sterling addresses these failures 3. They are not a few, occurring several times in the course of development. The longer you put off correcting them, the less likely they are to ever be corrected.
This is exactly where an important task for the tester on the team can arise: To point out and evaluate debts in order to bring about a correction as quickly as possible. To do this, however, they must be able to identify what all is missing. Simple metrics like test coverage measurement are not sufficient for this, because e.g. functions that are not there cannot be tested. The tester therefore also needs more technical skills, such as programming knowledge and an understanding of software design and architecture. For one thing, it's about uncovering everything that belongs to the code that isn't there. This accounts for most of the technical debt 4.
The other part of technical debt makes up the quality of the code. This is what Ward Cunningham originally meant. Compromises may be made about the architecture of the system and the implementation of the code in order to move faster. The result is executable but not maintainable and updatable. The user doesn't notice at first. So the technical mountain of debt grows from release to release.
Timely problem detection
One advantage of agile teams is constant feedback. That's why testers are on the team. When it comes to preventing quality degradation, testers on an agile team have more to do than just test. They ensure the quality of the product is in place during its creation. They do this through a number of measures. This includes ongoing reviews from user stories to design to code, assisting the team with testing methodology for the various intended tests, and of course, directly implementing and executing tests 5.
Agile testers must always be able to quickly provide feedback to developers 6. "Continuous Integration" makes this possible 7. The tester has an integration test framework into which he puts the new components. The previous components are already there. They are supplemented daily with the new ones. Of course, test automation plays a crucial role here. With the test tools, it is possible to repeat the regression test daily, while also running the functional test of the newest components. Problems that occur can then be reported back immediately. This is the decisive advantage over conventional, bureaucratic quality assurance, where it often takes weeks before error messages and defect reports could be reported back to the development team. Thus, valuable hours and weeks were lost.
In agile development, this is no longer the case. There is no such idle time anymore. In order to keep up with the development results, a tester in the team has to be
- are well versed in the development environment
- have powerful tools
- have a good relationship with the other team members
If these three conditions are not met, then testers cannot deliver the value expected of them, no matter how well they master the testing technology. Agile testing simply demands more from testers than has been the case in the past.
Timely detection of problems and quick feedback to developers are the main benefits of agile testing 8. While the quality of the software is a matter for the team as a whole, the testers on the team have a special responsibility. They must ensure that technical debt is contained and reduced.
- Kruchten, P./Nord, R.: "Technical Debt - from Metaphor to Theory and Practice". IEEE Software, Dec. 2012, p. 18
- Cunningham, W.: "The WyCash Portfolio Management System" Proc. of ACM Object-Oriented Programming Systems, Languages and Applications - DOPSLA, New Orleans, 1992, p.29.
- Sterling, C.: Managing Software Dept - Building for inevitable Change, Addison-Wesley, 2011
- Lim, E./Taksande, N./Seaman, C.: "A Balancing Act - What Practioneers say about Technical Debt", IEEE Software, Dec. 2012, p. 22.
- Janzen, D., Hossein, S.: "Test-Driven Development - Concepts, Taxonomy and Future Direction", IEEE Computer, Sept. 2005, p. 43.
- Bloch, U.: "When integration fails to keep pace with agility", Computerwoche, No. 24, June 2011, p. 22
- Duvall, P./Matyas, S./Glover, A.: Continuous Integration - Improving Software Quality and reducing Risk, Addison-Wesley, Reading Ma., 2007
- Cockburn, A.: Agile Software Development, Addison-Wesley, Reading, Ma., 2002.