Thread by @RonJeffries

XP has a Customer / Programmer role separation at its core, and Scrum has the analogous Product Owner / Dev team separation. Arguably these separations are inherent flaws in the approaches, because what would be "better" would be a collaboration without the power gradient.

1/22

A truth that lends legitimacy to the separation, however, is that software development is often done by one group at the behest of another, and XP/Scrum's model helps that relationship work better.

2/22

So, maybe you start there and work toward more of a partnership / collaborative model, or maybe you are fortunate enough to do that right out of the box.

Purely collaborative decision making is hard, though, so expect that you might never get there.

3/22

But we're here to talk about "testing". XP's founder introduced TDD née Test-First, which can be seen as a simple ritual of calling your shot with an automated check, and then making the shot, rinse, repeat.

4/22

This check, this calling of the shot, was called a "test", and testing experts rightly have wished that another word had been chosen. But we're here now, so we'll deal with it.

Now as for the "DD" part ... variously -Driven Development or -Driven Design, ...

5/22

The idea is that the test/check serves to say what's to be done and that when the code does it, we have confident that that little step has been taken. We use that check/do cycle in two main ways:

6/22

In programming, we use it to give the developer, programmer, pair, or mob confidence that the code does whatever new thing they've set out to do. This new thing, quite often, is such a tiny piece of the "real requirement" that only the developers recognize it.

7/22

We're creating a report, but this code right here is formatting a number into a comma-separated dollars and cents format. The developers write a test for that, format a number, repeat until they're sure they've got it.

8/22

XP called those checks "Programmer Tests", because XP called the developer role "Programmer", I believe because the founder wanted to take back the word "programmer" as an honorable title. In Scrum, we'd call those "Developer Tests", because Scrum calls it the "Dev Team".

9/22

Now in early days, we XP folks also wrote "Customer Tests", tests that belonged to the XP Customer. We used those to be sure we knew what was needed. (See Card, Conversation, Confirmation.) And we found value in pretending that when the Customer Tests ran, the story was done.

10

It /was/ pretending. It was a convention we create for communication so as not to get into he said / she said arguments about whether the programmers didn't understand or the customer didn't state the problem. We just agreed that if the tests ran, that was done, ...

11/22

and if we weren't happy yet, we just created another story (Card, Conversation , Confirmation) and iterated until we were happy. So the Customer Tests are about communication, and a kind of "conventional" acceptance.

12/22

This idea was adopted and often misused. We used it to help us turn from recrimination to collaboration: some teams used it to continue recrimination. "THE ACCEPTANCE TESTS RAN, THEREFORE **** YOU" wasn't quite what we had in mind.

13/22

Be that as it may, note that a term from real testing had slipped into the parlance, "Acceptance Test". Agile isn't about demands and acceptance, it's about collaboration. So the Acceptance Test notion really doesn't fit well, but the words are known and have often been used.

14

Same thing happened with "Unit Tests". In real testing, in software engineering, "Unit Test" has a specific meaning relating to the size and complexity of the thing under test. Programmer [Developer] Tests are small and often do meet the definition of Unit Tests.

However ...

15

Often Programmer/Developer Tests may check a few objects in collaboration. There's no rule about sticking to one Unit: there's a sort of meta-rule about small and fast.

16/22

Now the upshot of all this is that the Customer/Programmer testing notion came from XP, and was adopted into Scrum as Acceptance Test / Developer Test (sort of, Scrum has never really understood software development).

17/22

Because of semantic drift, the key notion of communication of intention, followed by confirmation that the intention was met, central to both TDD and what we often call ATDD, kind of got lost.

18/22

Nonetheless Customer, or if you must, Acceptance Tests, are essentially for communication between Customer and Developers, and Programmer or Developer Tests are for communication within the developers about the more micro things that concern them.

19/22

These two notions are probably poles within which there are gradations. We'll not go there today. This is just history.

One more thing ...

20/22

Because we do all these kinds of tests in very short cycles, minutes for TDD, a day or so for ATDD, the cycle provides us with clear and concrete software, working as we intend, at the end of each cycle.

We use that real software to guide what we do next.

21/22

The software helps us drive. And that is Test-Driven Development.

22/22

(How's that for improv?)