Hi Tom,

I was writing about the difference of Waterfall and Agile/Lean approaches, but it was too long, and not really relevant. I prefer to refer to Kent Beck and what he explains about both.

https://www.youtube.com/clip/UgkxtDsi3VZOwkZscK9G42Ih3Xe7AccOp3u3.

Of course, testing cannot verify that a program works, and it never will. Edsger Dijkstra already said that in the 60s, and he proposed a new branch of mathematics that allows to verify any program formally. It was useless because the problem of the program is not that they work correctly as specified, but that they work as we expected. IKIWISI is a variant of this, but it is also aligned with what Kent Beck explained.

I know the V-cycle, I know shift-left, but they are different concepts. And yet, both cannot be applied to TDD.

TDD is usually taught alone, as just a small practice of three rules. But it is more than this. It is true that TDD was born as just the practice of writing the minimal amount of test before the code, but once their creators dominated that part, they started to think about what how TDD could deliver more. About how to extract the maximum potential.

At the end of the 90s, they realized that they could use the same principles to improve the communication with the customer (business). The idea is that a test is just an example of usage: they asked the customer about how the application will work (behave), and then wrote the exact examples.

One typical misunderstanding about TDD is thinking that it generate Unit Tests. They generate unit tests, but not QA unit tests, but TDD Unit Tests. These tests can be understood as Acceptance Tests, System Tests, Integration Tests, or Unit Tests, but in fact they must be the tests that forces the programmer to generate the code. In this case, if we apply the previous paragraph, we will see that they are the tests that checks that the agreed examples are satisfied, and that means that there is no need of testing after it is finished.

I recommend also read the website of Dan North, the inventor of BDD, the tool that he invented for weeks to teach TDD. He speaks that you can go faster, but so fast that it is even difficult to imagine, I love when he writes: «But surely that’s impossible, otherwise we would already be doing it? The problem is, you are looking where the action is and trying to make it more efficient. We look where the action isn’t: the hand-offs, the waiting, the back-and-forth with process documents, the stuff that falls between the organizational cracks.» The problem of how we explain it, is that I am confident that only those who know can perceive the subtleties.

I remember a few months ago, speaking with a colleague, about how we should improve the BDD process. Then I said to him that we should be able to cycle every three hours. He said impossible, for him, being agile was, at most, since the conception of the idea, until the production of the code, weeks. But not, that was because he was thinking in big batches. Do not do that. The idea is thinking in small of little improvements. Imagine that what could happen if the customer (business) could review several times a day the progress of the software, and came with better ideas. (Note: nowadays, we are aligned, and btw, that was the idea of the Tesla anecdote)

That is the point that TDD, it is to accelerate the software development, but not by producing more, but by producing better. No fewer bugs, but better functionalities. And remove the problem of miscommunication between the coder and the customer (business).

So, it is not "quality", definitively it is not testing, it is the process.

By the way, thanks for giving me the opportunity to reflect on about it.