The Latest

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.

Vendors and gurus agree that having a structured testing methodology is key to gaining maximum advantage from automated testing, but what this means in practice isn't always clear.

If you're in business today, then you're relying heavily on enterprise and eBusiness applications for your success. But given our dependence, these applications are being upgraded and customized constantly.

Key points from this presentation: define meaningful performance requirements; we're always searching for the maximum number of users, design bottlenecks, and performance tuning points; changing your site (hardware or software) invalidates al

With increasing demands for high-quality software applications in shorter development cycles, it's clear that teams need to go beyond simply running tests at the end of their development cycle.