When discussing TDD with my friends and coworkers, often heatedly, an interesting pattern has appeared. All of the arguments about expensive refactoring and the need for up-front design are never really challenged. Instead, what has always been the final refuge for those arguing for TDD is that it makes development fun again.

A Reflection on Up-Front Testing
As we were saying, up-front testing really isn’t testing at all. It is really up-front design through the analysis of our tests. Can we take this testing even further? When XP came out and suggested doing unit tests, many of us realized that if we combined a series of unit tests together, we could get the equivalent of automated acceptance testing.

What main factors contribute to success in test automation? What common factors most often lead to the failure of an automation effort? There are no simple universal answers to these questions, but some common elements exist. We believe that two of the most important elements are management issues and the testware architecture:

Testing is often seen as a surrogate for quality and if you ask a developer what he is doing about quality, “testing” is often the answer. But testing is not about quality. Quality has to be built in, not bolted on, and as such, quality is a developer task. Period. This brings us to fatal flaw number 1: Testers have become a crutch for developers. The less we make them think about testing and the easier we make testing, the less testing they will do.[...]
When testing becomes a service that …

“As we were saying, up-front testing really isn’t testing at all. It is really up-front design through the analysis of our tests. Can we take this testing even further? When XP came out and suggested doing unit tests, many of us realized that if we combined a series of unit tests together, we could get the equivalent of automated acceptance testing.”

One of the most common mistakes that teams made was treating specifications or related automation code as less important than production code. Examples of this are giving the automation tasks to less-capable developers and testers and not maintaining the automation layer with the same kind of effort applied to production code.
Reference: “Specification by Example – How successful teams deliver the right software”, Gojko Adzic, Manning, 249 pages, IBSN 978-1617290084

A test is not a unit test if:
* It talks to the database
* It communicates across the network
* It touches the file system
* It can’t run at the same time as any of your other unit tests
* You have to do special things to your environment (such as editing config files) to run it.

Defects are not so much a technological as a sociological problem. So the measures we take to control them can be expected to lie largely in the sociological plane, affecting the structure and organization of projects, the allocation of goals, and the fostering of new attitudes.
Tom DeMarco, “Controlling Software Projects”, Yourdon Press

As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications.
Dave Parnas, Communications of the ACM (33, 6 June 1990 p.636)

“We define an agile tester this way: a professional tester who embraces change, collaborates well with both technical and business people, and understands the concept of using tests to document requirements and drive development. Agile testers tend to have good technical skills, know how to collaborate with others to automate tests, and are also experienced exploratory testers. They’re willing to learn what customers do so that they can better understand the customers’ software requirements.”
Source: “Agile Testing”, Lisa Crispin and Janet Gregory, Addison-Wesley, 2009