Developers are very, very good at abstraction. If you give us half a problem, we’ll come up with the whole solution. In fact, we’re so good at this, we won’t even notice that we’ve only got half the problem. We’re “solution space” people. Our job is to solve problems.

Testers, on the other hand, are “problem space” people. They’re the ones who ask, “What about X? Or Y? Have you thought about Z?” They know how to break our code before we’ve even written it. If we’re really nice to them, they’ll tell us. Their job is to understand the problem backwards.

An analyst or SME might be good at working out which problems are the most important to solve, but once they’ve made that decision, testers are just as good as they are at understanding the nature of the problem chosen. Devs tend not to be good at this because of our “solution space” heads; we blind ourselves to the things we don’t know.

In an environment where you’re doing BDD or TDD, testers are invaluable for helping you, and the business, spot the tests or scenarios that you’ve missed. They’re also great for doing exploratory testing, so they find the things that automated tests can’t (for instance, one of my favourite testers spotted that I’d put an SQL call in the wrong place and that a particular behaviour was making 10 calls to the DB where it only needed to do 1).

I tend to refer to “tester” these days rather than “QA”, since assuring quality is indeed, as gurun said, more than just one person and a bit of process.

TDD is a design tool used by developers, it is more about design than tests and verifications.

BDD is a communication tool to bridge the gap between developers, QA , Product owners or business analysts. BDD makes sure we share the same vision of what need being built using concrete examples instead of relying on an abstract specification.

QA is a role with the responsibility of verification testing around features, security, performance, compliance so on…QA can also be responsible for providing test automation tools.

So as you can see they are three orthogonal things (In a three dimensional space of course).

It’s certainly arguable that you do not need “QA”, though that depends on what you mean by “QA”. Do you need a separate QA team or department? Probably not. Do you need trained QA professionals? Probably so.

Testing is a skill, and it is typically not a skill that most developers have. Every team should have trained, professional testers. Their job should be to make sure the software is well tested by both working with the developers to write good tests during development, and to perform their own testing such as end-to-end exploratory testing.

As an analogy, think about a building inspector. For example, if a carpenter checks that the roof they built isn’t leaking, why have a building inspector? Do you just take the word of the carpenter? You still need a building inspector because they know the common mistakes that are made and how to spot them.

So, even if you have a development team that conscientiously does TDD, ATDD, BDD, or one of its variants, you still need trained testers to insure you have well tested software.

automated testing scripts help with logic and clicking around the application to ensure its all connecting nicely.

What it doesnt account for is:

has the automated script checked for all the features created?
does it check the logic properly?

Lastly:
The layout of the design is not checked here. Testers with keen eyes for detail are very helpful to catch lots of little things in the UI experience between different screen sizes, platforms, and devices. Also more eyeballs on the software checking things tends to improve logic flow for a better UI experience with less confusion.

You wrote “If this is true how a QA fit in?” which implies you are talking about a person responsible for QA. I’ll get back to that in the end of the answer.

Quality assurance and quality control are two very distinct concepts. I believe when we as developers talk about QA we most often refer to the people either creating the tests, or executing them, or both. For me, quality assurance is the systematic planning and documentation of quality related activities. Most often documented in an overall quality system. We do that to provide some sort of “assurance” that we care (in plain English). Quality control, to put it simple, is activities related to the verification that we are following the plan.

So when you ask this question you need to put TDD, BDD (or any other practice, methodology, technique, etc.) in the right category. You also have to figure out what you actually mean with QA.

Blunt; Just because someone is doing TDD it doesn’t mean that there will be quality. It also doesn’t mean that even if someone is good at doing TDD it will be enough coverage. Also the quality system would include criteria for how much testing would be enough, and it can often be as simple as “test what needs to be tested”. But in a real quality system that definition wouldn’t be able to stand on its own of course. You need to be able to judge this from as unbiased position as humanly possible.

I think there is often a misconception that QA/QC needs document requirement, tests, etc. I often have to argue (with our QA) that quality is not created by the process itself. Quality needs to exist in development, and the role of the process is to collect sufficient evidence to prove that you have quality. That means that QA from the perspective of “having a plan” is actually more important to me than quality control. And that is where TDD and BDD plays a role as activities and practices we practice to assure quality output of our work.

A QA as you write it, like it is a specific person you are thinking about, probably mean what we usually label as QAE (engineering). That is basically the art and business of creating material for verification and validating the result of coding. And it is truly an art. A person/department doing QAE usually do a lot more than testing the system individually, since verification and validation activities usually stretches far beyond basic BDD/TDD.
But from a pure “coders perspective” I tend to look at this as a responsibility. And then it depends highly on the organization structure, size, business, etc. if that responsibility is connected to a role (or several).

I would strongly argue that regardless how and what you do, you always need, and always have QA. You always have QC. You always have QAE. It’s just that in small teams this might not be an explicit resource, role or organisation.

So what is the role of TDD in all this? Well, to me it could have no role at all, or mean everything. TDD to me is an approach to writing code, not writing tests. People seems to argue about things like “is London style better than Chicago or even Piteå style”. I would argue that Piteå style always win, since that is my style. And Piteå style mean that most of the time after writing something extreme TDD style I end up with everything from functional, integration, unit, black-box, white-box. The only thing I can say for sure is that from TDD Piteå style I always end up with much simpler, more to the point, more covered, better building .. code. Piteå style also mandate that it is perfectly OK to not produce any code at all if quality so dictates. Occasionally Piteå style mandate a beer or several, but that is a different kind of quality assurance.
In Piteå Quality System TDD is the foundation I build my assurance that what I produce will be of sufficient quality, and being able to maintain it later. And my CI server is tireless and continuously controlling that I don’t slip up.

But ultimately, as far as real quality goes, only the users of my code can bare witness. I can only assure them that I do quality at the best of my ability. Quality first, always, then TDD.

[Piteå is my hometown]