Technical debt can shorten a product's life. But when technical debt mounts, it can be difficult to see how to pay it off. Using the practices discussed in this column, Johanna Rothman explains how you can start paying off that debt—and how to ease the product's development and maintenance for a long time.
Technical debt is the unfinished work the product development team accumulated from previous releases. This debt includes: design debt, where the design is insufficiently robust in some areas; development debt, where pieces of the code are missing; and testing debt, where tests were not developed or run against the code. Technical debt is common, but the practices in this article may help you reduce the amount in your project.
Let's assume your current project has substantial testing debt—the state of the software could be better understood if you could run more tests, automated or not, in several areas of the product. But the amount of debt is so large that it seems like an overwhelming problem to write, or even plan, a lot of tests, never mind trying to determine which ones to automate.
If that's the case on your project, consider trying these practices:
- Decompose each area into several use cases or scenarios. If you don't define requirements with use cases or scenarios, use your own technique to break the big area into smaller pieces. You don't have to have perfect requirements, but you do need to have a specific idea of what you need to test
- Rank the areas according to risk
- Develop tests in timeboxes, starting with the highest risk areas, until this release is complete
Once you've finished the work for this release, you'll want to reevaluate the risky areas (in case the product has changed direction) and follow these steps again.
Decompose Each Area into Scenarios
Let's assume you have a store application on the Web. The only part of the product that has been tested well is the security for credit cards. Other areas that need more development include the following: the application links to several product catalogs, and searching through each of them works only under specific circumstances; customers can't search all of the catalogs with one search; and not all the images render quickly enough when the pages load.
If you take these areas at face value, they are: broaden search, search all catalogs with one command, and accelerate loading time. But each area has more than one scenario. Here's what it might look like if we decompose each area into several scenarios. Note that the search areas are related, so we'll lump them together in the broaden search category and then decompose by type of search.
- Broaden search: by types 1, 2, and 3, search by catalogs, and through all catalogs
- Accelerate page loading time: browsing loading time, and search results loading time
These example phrases are similar to user stories—phrases that mean something in the context of the application but are not fully formed requirements. That's OK, because we want something to rank before we fully define the specific tests.
Rank Each Area According to Risk
Once we have a list of what we want to test, it's time to rank the listed items. This relative ranking is determined by what's most useful to the customer, not necessarily the area with the most technical debt.
One technique is to ask the product manager to assign points to each area. You will use the points to decide which area to test first.
In this example, we'll use fifty points. If you had more than twelve items on your list, you might find it useful to use 1,000 points. That way if the product manager assigned 250 points to one area, you would know that the risk of leaving that area untested was very high. Seeing all the points assigned provides you a relative priority, because the amount of points is related to the product manager's assessment of risk. I find this especially useful if I'm not sure the team can complete all the desired testing prior to release.