What Testers Can Do about Technical Debt (Part 2)

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:

1. 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 last week's 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.
2. 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?
3. 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.
4. 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.
5. 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 .
6. 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