Testing Debt

There isn’t a whole lot that I can see out on the big wide world web on what I am calling Testing Debt (or so says Google). Perhaps most folks call it something different. I’m seriously open to debate about what exactly Testing Debt is, and/or how it should be defined.

I would currently define it to be the debt of testing that is accumulated when development of a production code-base outstrips development of testing mechanisms.

As a software developer this means a debt of automated test code that needs to be written in order to cover production code that has already been written. The longer this is ignored, the greater the debt that is built. But as a larger I.T. solutions delivery team in a business, this would include all kinds of other testing mechanisms and methodologies (automated testing, user acceptance testing, exploratory testing etc).

How can Testing Debt be repaid without impacting on development/release deadlines? And how can you ensure that the quality of the Test mechanisms created to repay that debt are to a high and independent standard (i.e. testing what the solution should do, not what it does do)?