Technical debt is a metaphorical idea which argues that just as one may run into debt problems in finance, software organizations encounter something similar in the buildup of unfinished work during past projects and version releases/sprints.
What is Technical debt?
It represents the effort needed to fix the issues/defects that remain in the code when an application is released. In simple words – it’s the difference (in terms of bugs) between what is expected and what is delivered.
When a development team is busy working on a project and fixing bugs unfortunately, many new bugs appear. Out of these, some are fixed and some are differed for later release. When this differing of issues goes on increasing, at one point it becomes really difficult to release the product on time without any issues. This is the worst consequence of Technical debt if it’s not tackled on time.
In this article, you will learn – what is technical debt, why QA team should be concerned about it and most importantly how to manage it.
Ward Cunningham, the founder of wiki software, conceived of this idea way back in the 1990s, drawing parallels with the impact of bad debt on the financial industry, literally alluding to the unsavory experience of having to pay excessive interest money after defaulting on loans.
The challenge of mounting tech debt per sprint can be visualized in Fig.1.
It has to be mentioned here though that there is a slight difference in the meaning of technical debt (also known as code debt or design debt) from its corresponding analogy in the world of finance – the former is more like an abstract idea, with no mathematical equations to visualize how the interest really accumulates.
Fig 1: Visualizing the scalable increase in tech debt across sprints
What You Will Learn:
During a typical software design & development cycle, there are several things that can lead to a “technical debt” like situation– improper documentation, inadequate testing and bug fixing, lack of coordination between teams, legacy code and delayed refactoring, absence of continuous integration and other out of control factors.
For example, it has been observed that code duplication efforts can lead to anything between 25 to 35% extra work.
However, nowhere are the challenges due to technical debt more evident than in QA testing where test teams have to meet unexpected deadlines and everything may be thrown out of gear.
How often have your testers faced quandaries at the last moment when unexpectedly, the delivery manager came and told them, “Team! We have to roll out our product in a week’s time, sorry about not being able to communicate this in time. Please finish with all test tasks urgently so that we can be ready with the demo.”
Basically, any missed tests or “solve it later” approach can lead to a tech debt like problem. Lack of test coverage, oversized user stories, short sprints, and other examples of “cutting corners” due to delivery pressure play a huge role behind the accumulation of technical debt in QA practice.
A US-based online retailer with significant presence across multiple websites and mobile apps found itself in a real world “technical debt” challenge when the complexity of the testing mesh started compounding with each new sprint.
This happened due to the sudden spurt in the number of mobile devices to be tested, multiple languages to be supported, and more than half-a-dozen social networking sites to be leveraged.
With an automation coverage less than 40%, the tech debt challenge would show up in the following ways:
Most QA managers impulsively view tech debt as the reasonable consequence of focusing all your energy on the current sprint alone, which leads to achieving the test coverage somehow through manual means, and completely ignore automation.
This is known as the quick and dirty approach which has been covered in a blog by Martin Fowler, the author of the technical debt quadrant.
Agile principles dictate that we visualize the tech debt problem as an inability to uphold and meet QA benchmarks.
In fact, based on a survey by the National Institute of Standards and Technology (NIST), insufficient testing tools and methods annually cost the U.S. economy between $22.2 and $59.5 billion, with roughly half of this money spent on extra testing by software developers and around half by software users to avoid failures.
Instead of reacting to failures as and when the incident happens, a proactive approach would be to identify defects after every activity or task that can be measured. You can do all of it manually but given the thousands of test case scenarios for an average project, automated testing control is a necessity.
Clearly, effective testing can help you gain serious ground in the war on technical debt. So, what does it basically mean? It means how well-equipped your system is at identifying defects in the overall application.
As the above equation shows, test case effectiveness can theoretically approach even 100% if the number of customer found defects (i.e. post-production defects) had been mapped precisely to the number of defects found at each stage of testing coverage.
In order to have a well-designed testing bed which can accurately measure the defects as soon as they creep in, automation is a prerequisite.
Testing automation helps you minimize the number of scripts being executed by reporting results and comparing them with earlier test runs. The method or process being used to execute automation is called a test automation framework.
In the past, QA/testing was often seen by organizations and their software teams as a support activity to more important business deliverables, and not a disciplined practice in its own right which would require core, dedicated focus. In fact, a non-core approach to QA/testing is precisely what has led to the ongoing challenge of technical debt in the first place.
Considering the rapid pace of evolution in QA/testing skills that has occurred in last one decade, organizations are having a real hard time upgrading their skills and competencies to the minimum levels desired as per current industry benchmarks.
In fact, there is a growing industry trend to make do with nothing less than the most seasoned professionals in testing automation – sort of like the elite commandos of testing/QA; they are known as software engineers in test (SEiT) and software developers in test (SDiT). These professionals are in high demand due to their vast experience in a chosen vertical (e.g. e-commerce) or a particular professional category.
Most software and product development companies, as we speak now, are struggling to find the desired, qualified technical resources in the face of shorter delivery times. The solution to this challenge is to partner with an offshore QA automation player that can address your skills shortage with the right pool of SDiT/SEiT resources.
Other desired attributes of an outsourcing player in QA/Testing that prove helpful include an Agile, disciplined approach to project execution, sufficient industry experience including hands-on access to reusable automation frameworks and test cases, and last but not the least, a clear intent and ability to address remote team challenges and cultural clashes so that the client is not burdened with extra work in managing contractors.
Like any other debt, technical debt can prove itself to be the bane of enterprises and the root cause of its accumulation is failure to implement a proactive QA practice which removes all backlogs in automation.
About author: This is guest post by eInfochips team. They have come up with a unique approach called Tech Debt Zero which is one of the most structured and efficient ways to gradually eliminate technical debt in QA/automation activities. To know more about tech debt, watch this video on a approach to reduce tech dept.
Hope you get the clear idea about what is Technical debt. Let us know if you have any queries related to it or how to manage it in practice.