Can you share any insights on how to measure technical debt? Do you have specific tools you’d recommend for this, or certain testing frameworks you’ve had success with?

As technical debt could have different forms, it will be the sum of different things.

For example, all our applications are documented in BizzDesign (used to be in Casewise before last year).   We can trace all the components (software, middleware, hardware) link to an application.

Then,  for specific technologies such as the version of database or a webserver, we could do queries to find which applications is using an obsolete version.

We also have development framework that we've built.   Some are dating as far as year 2000 while new ones are from 2023.   Once again, we have in BizzDesign the framework component.   So if, for example, Dev Framework V1.1 has been declared "obsolete", we know immediately how many applications carry a debt.

Extracting data and using PowerBI let us easily keep track of where we are, what we've done to reduce the debt, having some KPIs and goals.

Your team will recognize technical debt when they see it, but a more precise approach involves defining your team's standards and then measuring compliance with those standards. As your code standards evolve, these changes will inherently generate technical debt. Measuring the percentage of code that does not adhere to these standards using static analysis tools is key. 

We use SonarQube to identify the areas of non-compliance (technical debt) and conveniently it provides time estimates for each issue. This helps us prioritize and systematically manage technical debt to maintain long-term code quality and maintainability.

As others have mentioned we have manual identifications of technical debt but those are tracked as regular work.

Manually - we create tickets to track technical dept as it is identified through code meetings and through automated code scanning reports which also result in tickets