I love TDD as a programming technique and evolutionary approach for designing a system. As any technique there are places where TDD can be applied easier than in others. For example it’s not that straightforward to start writing implementation test-first for the codebase which did not have any tests for years.

In my point of view when talking about Testing one should distinguish the term into two, while defining it for a particular context. There are, usually, a combination of activities people put into word ‘Testing’.

Word ‘test’, on a higher level, can mean two things: test(noun) – like a test case or automated test, and ‘to test'(verb) – as an activity, e.g. to perform testing, look for issues, defects, new verification ideas.

Depending on what’s a situation in a team, either time, budget constraints or other constrains, usually force people to neglect either one or both of these Testing dimensions. Which later result into growing number of production issues, bugs and technical debt.

Testing, both verification(running manual or automated checks) and exploration(looking for opportunities and issues) should be taken into account early on the planning stages and be included to the team’s ways or working agreements to preserve a desirable level of end product quality.

Where TDD is a good engineering practice to get a number of automated verifications(checks) at the end of implementation, it has nothing to do with the Exploratory side of Testing.