Test Design

The components of software processes work together in important and sometimes unrecognized ways. The removal of one of those components will affect the others. In this article, which originally appeared in the August 2010 issue of the Iterations eNewsletter, Jennitta Andrea takes a look at the value of acceptance test-driven development and the costs of making it an optional practice.

In recent years within the object oriented and agile community, several approaches to software design and development have materialized and are in use by professional software developers. Test-Driven Development (TDD), Domain-Driven Design (DDD), Behavior-Driven Design (BDD) and Feature-Driven Design (FDD) are some of the more well known approaches. While these philosophies all imbibe the classic agile principles of an incremental and iterative mindset to software development, they subtly differ from each other.

Linda Hayes has worked in the software industry for a long time and through a lot of changes. But a series of recent events has led her to question whether the industry has changed for the better or worse. In this article, she recommends some attitudes we should lose and some we should adopt in order to save our software and—in some cases—our lives.

Approaching performance testing with a rigid plan and narrow specialization often leads to testers' missing performance problems or to prolonged performance troubleshooting. By making the process more agile, the efficiency of performance testing increases significantly—and that extra effort usually pays off multi-fold, even before the end of performance testing.