Software Testing & QA Online Community > Detail: What Testers Can Do about Technical Debt (Part 2)
|A StickyMinds.com Original|
What Testers Can Do about Technical Debt (Part 2)
By Johanna Rothman
Summary: 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 last column, she listed several indicators of technical debt. This week, 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
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.
- 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
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.
I thank Esther Derby, Dale Emery, Dave Smith, and Jerry Weinberg for their
review on this column.
About the Author
Johanna Rothman observes and consults on managing high-technology product development, looking for the leverage points that will make her clients more successful. Johanna was the Conference Chair for the Software Management (SM) Conference in February, where she conducted a management-improv tutorial and participated in a panel discussion of mentoring and manager making. She recently co-moderated a RoundTable discussion “Making the Transition to Management” with Esther Derby. You can reach Johanna at email@example.com or by visiting www.jrothman.com. For more information about analyzing job candidates, you can refer to Johanna’s upcoming book Hiring Technical People.
Back to Top
StickyMinds.com Weekly Column From 8/26/02