“You’re free to think what you like, but sovereign self-confidence need not lead to objective results.” – Yang Wen-Li

---

You Know What It Means, But Do You Know What It Is?

When I first heard the term technical debt, in the context of the conversation it made sense. In my head, there was technical work that needed “paying back” because someone in the past had borrowed from the future.

After the conversation, I looked it up, asked a few follow-up questions. It all made sense.

Here’s what my brain proudly reported at the time:

“That makes so much sense. I know what it is. Onwards!”

I Did Not Know What It Was

If you’ve never had direct contact with technical debt before, do not underestimate it. It is a powerful lurking beast.

If you’re creating a Test Plan for a project with technical debt, there’s a decent chance that increasing your fudge factor won’t cut it. Advice One: do not more forwards without a clear impact assessment from your code team. Ask questions. Find out how much debt is owed in each part of the project and the scope of changes to systems once that debt is paid back in full.

When The Beast Comes Out To Play

I firmly remember saying to myself, “Oh, so this is technical debt” when the bugs just didn’t subside. Everything would seem OK, I’d do some regressions and bam. Bugs would appear in seemingly unrelated places and I’d realise that I’d have to do another full sweep of a particular feature.

Advice Two: Treat it like a new project and draft your estimates like that. Do not treat it like it is almost finished.

Because it’s not almost finished.

Legacy logic might have made sense with the right context at the time it was written but without that context, it can be difficult to refactor in a mannar that doesn’t have a knock-on effect.

Taming The Beast

From now on, I’m going to have a whole new system for technical debt. I will put a much greater emphasis on the risks, get a much deeper understanding on the whole teams’ understanding of the debt and greatly increase my estimates of required resources.

Technical debt is no longer just spaghetti code to me, it’s high risk in a pretty, seemingly fully functional, package.

---

Wrapping Up

To newer QA professionals, I hope this post gives you a step up when you hear techincal debt being discussed for the first time.

To seasoned QA professionals, what’s your approach to technical debt?

I’ll share my new Tech Debt Team Survey, the questions I will be asking when I hear the words technical debt, as soon as I have drafted them.

Be safe out there QA peeps!