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 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
In this context, 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.
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.
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.”
ENRIQUE A DECOSS, SENIOR QA MANAGER AT FICO
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
