Technical Debt in Agile Projects & its Impact in Test Automation

Technical Debt in Agile Projects & its Impact in Test Automation

As QA professionals, you may have heard the concept of technical debt and its implications in the development team. However, for those that are not aware, “technical debt” was first coined by Ward Cunningham. The financial metaphor refers to what happens when the team decides to “fix it later.”

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

Ward Cunningham, Computer programmer.

The metaphor compares design choices to accounting: every credit requires a debit. By not correcting faults during development, one takes out a loan on the system and pays for that loan down the road. One may then choose to accept the charge or, if feasible, pay off the debt through corrections. Thus, technical debt in agile projects can be necessary to move forward with the business at hand, much like financial debt.

All the fixes or changes we put off or postpone are considered technical debt. In every case, the bill will come due– with interest. Avoid the confusion related to bugs that need to be fixed. Bugs are almost always associated with the function of the system, not testing tasks.

The development teams working on these applications spend more time dealing with usual issues than developing new functionality, which reduces the delivery of customer value. Technical debt in test automation is understandable, as software development, like testing, is not a linear process. As QA professionals, we should aim to keep technical debt from getting out of hand; this helps us spend more time on new development.

Test Automation Debt

When doing automation testing, we must consider the amount of test debt we have accumulated. Keep in mind that, according to Cunningham’s definition, not fixing issues early on could lead to an unfortunate interest payment; this can mean less test automation coverage, missing validations, or useless test scripts. These consequences can pile up, leading to an accumulation of technical debt in our test automation process.

diagram of technical debt in software test automation by Enrique A Decoss
Enrique A Decoss

Let’s look at some common reasons for technical debt in test automation:

  • Test cases are too big or complex to be automated.
  • The team did not fully understand the test scenario.
  • Lack of estimating skill or consistently unrealistic estimates for test automation stories.
  • The team is too pressured to “automate everything.”
  • High maintenance cost related to unstructured automated test scripts.
  • Test automation is not part of the definition of done (DoD).
  • Unexpected things happened during test automation.
  • Lack of coding standards for test scripts.
  • Lack of understanding from Scrum Masters/Managers about the test automation process.
  • Short timeframes for sprints make test automation teams rush and focus only on what must be done to pass the test reports.

Once we identify technical debt in our test automation process, it is essential to track, communicate and plan accordingly:

  • Track – Work with your management and plan to allocate a portion of future effort to reduce the technical debt; it’s imperative to identify and add some test debt stories during the sprint.
  • Prioritize – Prioritize work to reduce technical debt in test automation that will have the most significant impact. Focus on reducing the interest that is accruing on that debt instead of providing the perfect solution.
  • Communicate – The longer the test scripts remain in poor condition, the more significant the impact is likely to be. We must communicate about the test script code and how best to improve it. 
diagram of how to repay technical debt in software test automation by Enrique A Decoss
Enrique A Decoss

Prevent test automation debt by investing heavily. Plan accordingly and always prioritize your most significant technical debts. It is an undeniable truth that the more you invest in the design and coding standards for test automation, the greater long-term payback you will receive. Shortcuts and sloppy test automation will wind up costing your team more in the immediate term and significantly more over time.

Final Thoughts 

Many test automation teams struggle with the need for speed in agile development. Some teams use unstructured record and playback methods or inaccurate testing tools to create and automate tests quickly, resulting in “throw-away automation”. In my experience, we need to rethink our test automation effort to avoid draining resources.

“Just because your test automation is working doesn’t mean that it adds value.”


Test automation debt is inevitable, and it’s futile to make any attempt to avoid it entirely. Instead, Test automation teams should focus on managing it effectively. Proper management and repayment will help your team consistently release quality software products and likely improve productivity throughout several cycles.

Happy Bug Hunting! – Enrique A. Decoss

Free QA Strategy Template for Startups

Use our step-by-step template to prepare your QA plan based on real examples from startups like AppZen, Gumroad, Linktree, and Tailwind.

Want to learn more about QA?

Get the latest articles and resources from MuukTest emailed to you once a month.