What is Technical Debt and Why QA Testers Should be Concerned About It?

In this article, you will learn all about technical debt, why QA team should be concerned about it and most importantly how to manage it.

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.

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.

Why is it important to manage it?

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 differ 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.

What is Technical Debt and Why QA testers Should be Concerned About 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 challenges 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

Why QA Teams suffer the most due to Technical Debt

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, 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. The 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 Real World Example

A US-based online retailer with a 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 automation coverage being less than 40%, the tech debt challenge would show up in the following ways:

• Excessive time consumption in release testing – With the number of browsers, devices and scripts growing with each test sprint, the release cycle would keep getting delayed leading to loss of time-to-market.
• The increasing cost of hiring – The number of testers needed to support the project nearly doubled which translated into $500k additional costs
• Complexity in project – With the growing complexity of the project, keeping track of test cases and bugs was becoming a challenge.
• Too much time wasted in chasing false positives – Again, a fall-out of increasing project complexities.
• Increase in test development efforts by as much as 60% – It goes with the territory

Tech Debt Management in QA Practices

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? This shows 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 customers found defects (i.e. post-production defects) have 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 lessen 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.

Typical examples would be commercial-off-the-shelf or free tools such as Selenium, MonkeyTalk, Robotium, Borland SilkCentral, HP Quality Center and IBM Rational Rose.

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.

Conclusion

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. We hope this tutorial was useful in explaining this concept effectively.

About the author: This is a guest post by the 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 learn more about tech debt, watch this video on an approach to reduce tech debt.

Hope you have got a clear idea of what Technical debt is all about. Let us know if you have any doubts or queries related to it or how to manage it in practice. You can post them in the comments section below. We would love to hear from you.