Hi Scott,

Thanks, for your comment. I am sure that more people think like you, so thanks to give me the opportunity to respond to your doubts. Although, with other responses I have experienced the similar opinions in the past, that is not in the case that you have explained. So, I am sorry, but I cannot share your point of view. Not as it is presented.

Of course, you cannot trust automated tests, in one hand they can have bugs, but in the other, like Dijkstra said, a test will never prove that a program works. It does not matter how many tests you will create, they will never prove your program. Neither automatic, nor manual.

Although, you talk about TDD-style. There is no TDD style tests. There are tests created with the practice of TDD, but there is nothing in their form or structure that reveals that were created with TDD. Even worse, there are countless people who say that practice TDD, but they create faulty tests because they practice faulty TDD. And sadly this is most coders. So, if all you have seen are these tests, then it is normal for you to think that they are not trustworthy.

What I cannot agree is that you can trust your manual tests. Manual tests are repeated each time by a human, who is well known to be unable to do repeated tasks without failure. (In fact, that is the reason why we test the result in the first place). Each time that you test an application, manually you can fail, and you can pass a bug. Compared to an automatic test, once you detect that an automatic test has a bug, you can solve it forever; but that does not happen with manual tests, you repeat the manual test each time, and each time you can make a random mistake several more times.

Even worse, I do not know any company that do a full regression manual test every time that a programmer changes something. They often limit the scope to what they believe that is more relevant, and forget the rest. And that is because humans are very slow and expensive.

So if we consider that humans fail and humans are slow, there is no point to compare automatic tests with manual tests. They play in different leagues.

Despite all of these, there is true that there are cases in which you need manual testing, like exploratory tests. But that is a use case very limited.

And about misunderstood requirements, that is another signal that TDD has not been followed correctly. With TDD, the developer has examples to test, and those examples are the ones that are part of the contract with the customer. In addition, here is where QA may help because they can come with a different set of examples that might be relevant, the ones that they would "manually execute". But the TDD practitioner must get those examples and put them in tests, as they were redacted. So, there is no misunderstanding of requirements, neither misalignment. Everyone is on the same page because everyone agree on exact examples.

I know that it is a shift in the mental paradigm and culture.

And by the way, there are other techniques that can be used like monitoring, and releases to subset of users, etc. that can give an extra boost of confidence. And the most extreme cases that I know, and I have explained in other responses, are the cases of Tesla or SpaceX that can deliver in few hours or less with automatic testing, and full safety.

So, the question is, how do you think that we can avoid manual tests, that are expensive, slow, and not reliable; and how can we shift towards their automatization?