An Incremental Technique to Pay Off Testing Technical Debt

[article]
Summary:

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:

  1. 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
  2. Rank the areas according to risk
  3. 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.

 

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 24
Oct 12
Nov 09
Nov 09