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

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.

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