Why do some testers get a much better response from development than others? Part of the answer lies in the defect report. Following a few simple rules can smooth the way for a much more productive environment. The objective is not to write the perfect defect report, but to write an effective defect report that conveys the proper message, gets the job done, and simplifies the process for everyone. This paper focuses on two aspects of defect reports: 1) the remarks or description and 2) the abstract.

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.

This document looks at the issues that can arise and suggests solutions when a testing
project becomes constrained by deadlines. While this is true of most testing projects, there
are some with farther reaching consequences than others, especially if the deadline is
immovable. I hope to impart a few key points along with a few tips and techniques on what to do when
you find yourself in this situation. This list is not exhaustive and the ideas presented here
may need to be adapted to your own specific project. However, when the chips are down and
you need to bring in some semblance of software that is tested, these ideas may be a good
starting point. This paper is intended for testing managers, but the points and tips contained within it will be
of use to anyone involved in planning for a deadline-fixed project.

Is your company drowning in debt? No, we don't mean the fancy fleet of cars that aren't paid for, or the new artwork in the lobby bought on credit-we're talking about technical debt. In this column, Johanna Rothman has a few tips on how to recognize technical debt in your organization.