Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been asked to create a report about the technical debt of an application, but I haven't receive farther guidelines about its elaboration. I'll be assisted by Sonar code analysis tool. My main doubt is: What fields would be useful to include in the report? I mean, what metrics, parameters, findings, suggestions, etc. would be the most important in such a report?

Thanks in advance.

share|improve this question
up vote 8 down vote accepted

When someone asks me to do something and I have questions about what they want, I go back and ask them. That's the most direct way to get an answer.

As a manager, I would want these fields:

  • description, i.e. what's the issue and why it's a problem
  • amount of risk if not fixed
  • pervasiveness
  • level of effort to fix, including testing effort
  • associated bug numbers, if any

Note also that technical debt, as I've heard the term used, is a broader area that the set of problems a code analyzer will identify for you.

share|improve this answer
May I ask you for a little explanation about what you mean by pervasiveness? Is what wikipedia explains in this article? – Eduardo Nov 7 '13 at 19:14
I mean how much of the code is impacted by the change, e.g. is the problem in just one place or is it spread all over? – user246 Nov 7 '13 at 20:11
Understood. Thanks! – Eduardo Nov 8 '13 at 12:57

In addition to user246's suggestions, I'd also recommend looking at these areas:

  • presence/absence of unit tests
  • effectiveness of unit tests (that is, do the unit tests cover more than the code paths - they should be covering all the potential logical boundaries as well)
  • presence/absence of higher-level automated tests (including system, API, GUI, integration...)
  • effectiveness and coverage of higher-level automated tests - as with unit tests this is more than simply how much of the code base the higher-level automated tests cover
  • areas of the application where customer-reported bugs cluster - this won't be found by a code analyzer, but it's usually a good pointer to areas of the application that have a high level of technical debt.

I also second user246 about the importance of talking to your manager/lead to find out more about what they want to see in the report. You've got a very broad task here: your manager could want a detailed analysis, or they could be looking for a thumbnail guide to where they need to focus improvement efforts.

Regardless, I strongly suggest talking to the developers and testers - anyone who has worked with the application for any length of time will have a good idea where the problem areas are. In my experience, the problem areas in an application are the areas with the greatest technical debt.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.