Introduction

Extreme Programming, or XP, was first introduced by Kent Beck in 1996. Since that time, programmers around the world have been embracing it with great enthusiasm. If you ask programmers on an XP team why, they will respond with answers like, "It's fun," "It just feels right," "It's the way code is supposed to be developed," and "It's all the good without any of the bad." In fact, Kent Beck has described XP as coming close to the practices programmers would follow "in the wild."

XP is not a throw-out-the-rulebook, anything-goes technique. It is actually a deliberate and disciplined approach to software development. And despite the name, XP practitioners are probably more concerned about following rules than developers using traditional methodologies. Rules do exist in XP, but only a few, and they lead to an entirely different type of development process.

In this book, we'll focus on how the rules of XP affect testing and quality assurance activities and illustrate how those activities can and should be carried out on an XP project. This may seem, at first glance, like arranging a date between oil and water. But testing and quality are at the core of XP, and XP offers solutions to some vexing testing and quality assurance problems that arise in traditional software development. All the parties stand to benefit from this seemingly unholy alliance.

We'll start with a brief overview of XP and describe what it has to offer in terms of solving testing and quality assurance problems. In the next chapter, we'll go on and make our case that testers have something to offer XP.