What is Technical Debt

and Why QA Testers

Should be Concerned
About 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.
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 its 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 its 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.
image source
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

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 situationimproper
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 weeks 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 Real World Example

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:
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 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 effort 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? 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.
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.