A reader asked: “I am hoping that you can answer my question to clarify something for me and another co-worker. Could you tell me the difference between TDD and Automated Testing? He says that TDD is for unit testing and Automated Testing is for System test. He also says Scrum doesn’t include anything about TDD so we don’t have to do it.”

Let’s start with definitions.

TDD stands for Test Driven Development, a specific technique introduced with Extreme Programming (XP). TDD tests are unit and sometimes code-level integration tests. But TDD itself is a development approach rather than a testing approach. However, a key result of doing TDD is that you end up with a fully automated set of code-facing tests. The Wikipedia article on TDD provides a good overview.

So the characterization of TDD being about unit testing is partly correct, but it is a misleading oversimplification.

Now, about automated testing. An automated test is one that can be executed by the computer rather than by a human. The term applies to any kind of automated test, and is not limited to system tests.

However, the distinction between developer tests and acceptance or system tests is useful. Developer tests are code-facing, and a result of TDD. Acceptance tests are business-facing, and on Agile projects, their automation is the result of a collaboration between the business stakeholders and the developers. Both are important. One of the mistakes that Agile teams tend to make is attempting to substitute unit tests for acceptance tests, or vice versa.

Now back to the assertion that “Scrum doesn’t include anything about TDD so we don’t have to do it.” It’s true that in Agile Software Development with Scrum, Ken Schwaber and Mike Beedle say: “During a Scrum, only the team can define its work.”

But that doesn’t mean it’s responsible to say: “Scrum doesn’t say we have to do it. So we don’t have to if we don’t wanna. Neener neener neener thbbbbpppt.”

Scrum also says that “Although a team has the authority to decide how to do its work, the team is responsible for using and conforming to any existing charters, standards, conventions, architectures, and technology. These ensure that the products of the project and the Scrum Team fit in with other organizational products and can be understood by others.” (See Agile Development with Scrum, pages 38 - 39)

Furthermore, as the Agile Project Leadership Network’s Declaration of Interdependence states, being Agile means delivering a continuous flow of value. To achieve that continuous flow of value, we have to use development practices that provide the visibility and feedback needed to make frequent, incremental changes.

Put another way, Mary Poppendieck says that speed requires discipline. I extend that to agility in general: if you want your team to be Agile, it must also be disciplined. Agile doesn’t mean “do whatever feels good.”

That need for disciplined development practices is why many teams have found that embedding XP-like practices (TDD, continuous integration, collective code ownership, pairing and/or frequent code walkthroughs, etc.) within Scrum is an incredibly powerful combination.

The bottom line: automated testing at all levels can be difficult, but the alternatives are worse. Without automated testing, both code-facing and business-facing, the manual testing burden becomes too large, the team begins incurring technical debt, and velocity slows.

So I don’t buy the argument that “Scrum doesn’t say we have to…” I think the real question is not what Scrum says or doesn’t say, but rather what practices are needed to ensure continued Agility.