Signs of technical debt are everywhere in software development organizations, ranging from developers leaving because they're tired of only doing maintenance, to daily patches being released for poorly tested products. In Johanna Rothman's Part 1 column, she listed several indicators of technical debt. She continues the topic by showing how you can diagnose the magnitude of the debt, and some things you can do to decrease it.
Technical debt is the unfinished work your organization owes your product. It comes in varieties: requirements debt, design debt, and testing debt. It causes the developers to have trouble finding and fixing defects, and causes testers to have trouble knowing how and what to test. Is there anything you, or your organization, can do about technical debt when you see it?
Diagnosing and Decreasing Debt
If you're seeing signs of technical debt in your organization and you'd like to reduce that debt, you have some choices in your testing:
- Keep tabs on the debt yourself. Know what you're looking at and the magnitude of the debt. Measure the size and FFR (Fault Feedback Ratio) of the product over time. I prefer weekly measurements to monthly or quarterly measurements, because the earlier you know, the earlier you can choose to do something about the problem. For the product I mentioned in the Part 1 column, we first gathered quarterly data to see if we had an idea where the problem was. Then, for the next project, we gathered weekly data, to be able to make quick course corrections in the product.
- List the kinds of testing you're doing now, and review the field-reported defects. If you're not doing end-to-end, performance, reliability, or standard dataset testing, should you? Could you give the developers different information if you changed the testing you do? With that information, could they better recognize or reduce technical debt? Do your tests address the field-reported defects, or are there entire classes of problems your testing is missing?
- Create testing experts. Staff the testing projects with testing staff for long enough that the testers become experts in the product area. One of the problems in the organization I mentioned in my previous column is that the testers were only assigned to the project for a few weeks at a time. In the course of a year, the developers had to explain how the product worked to numerous testers, not all of whom understood how they could help test the product.
- Reduce the number of concurrent projects you are working on. If you're a tester, and you think you need to take on more projects because otherwise you're not helping the company succeed, step back a minute and reassess. If you're not doing a great job on one project, if you're only doing mediocre to poor jobs on projects, are you really helping the company? (In my experience, no.) If you're a manager, stop assigning your staff to multiple concurrent projects. You can't squeeze more work out of people, and the more projects you assign people to, the less work they can do on each project. You're better off not staffing projects you can't adequately staff, so that no one is under any illusions. To see some pictures of the dynamics of inappropriate test staffing, see Elisabeth Hendrickson's paper, "Better Testing, Worse Quality?" posted here on StickyMinds, and on Elisabeth's Web site.
- Help the developers test the requirements. One way testers can be helpful is to test for a complete definition of the users, including the users you want to prevent from using the system. You can do this two ways: Use personas (as described in Alan Cooper's book, The Inmates are Running the Asylum); or if your group is not familiar with personas, group all possible users as favored, disfavored, and ignored a la Gause and Weinberg, Exploring Requirements, Quality Before Design.
- Help the developers test the design. You can participate in informal design reviews, using some rules of thumb: Did the developers consider three alternatives before choosing the one they took? Under what circumstances will this design not work? Are there performance limitations of the design?
If technical debt is a reality for your organization, then learn how to increase your testing sophistication and expertise to help diagnose and decrease the debt.
Technical debt impedes you from making project progress, and in my experience, it appears to dramatically affect how much testing you can do. Remember, technical debt is like credit card debt. The more you accumulate, the more you are impeded.
You might be able to shortchange your product on one or two releases, but at some point if you don't pay it off in a planned way, the debt buries you.
Acknowledgements
I thank Esther Derby, Dale Emery, Dave Smith, and Jerry Weinberg for their review on this column.
