Test Driven Development, aka TDD, as a process of writing your unit tests prior to your development. This helps the developer in several ways, the biggest advantage is, in my opinion, the developer's mindset when starting the task.
For example, your developer is starting out on a new task. They get their requirements, writes their code and then their unit tests. While writing his test they notice they missed a scenario in the code and has to refactor the code. After a couple hours of refactoring code that they already spent a couple of hours to write, they feel like they are in a position to run the tests again.
After a couple of hours of refactoring to make it pass the unit testing, the code is finally complete. The code is sent to QA and defects are found. The code is fixed, unit tests are added into the code and code is sent to QA. These steps are repeated until the code is considered acceptable.
The developers gets their requirements. The developers discusses with QA (hopefully) the planned unit testing. The unit tests are written and reviewed. The developer builds the code in order to be passed by the unit tests. The developer continues to build and refactor code until all unit tests are passed.
The code is sent to QA, QA finds defects and defects are resolved. The developer writes further unit tests for the defects that are found and once the code passes all unit tests it goes back to QA. This process repeats until the code is considered acceptable.
The primary benefit is, hopefully, the reduction in amount of code written and refactoring. The focus of the developers at the beginning of the project is what is the ultimate goal of this code instead of where do I start to write this code. This ensures that the requirements are clear, there is little doubt in the developer's mind as to what is supposed to happen and less gathering of requirements while in the middle of development, causing more and more wasted time for the developers.
Does it lead to better quality code?
Yes and no. It will usually give better quality code on the first release to QA. This typically will lead to overall better code as defect fixes are typically hastily written and will a lot of times cause other issues. No in the sense that it might still lead to poor quality code if the developer's requirements were vague to begin with.
The main benefit, in my opinion, is extremely thorough unit testing. This will lead to much cleaner code in the long term when someone else comes in to refactor the original developer's code because there is a change.
How does it pertain to QA?
Expect nothing better than normal development. Don't rely on their unit testing and make sure that you do your job as thorough as possible. However, do attempt to discuss the developer's testing methods with them before they write a line of code. This will hopefully ensure that they cover more scenarios with their unit testing and (hopefully) give you a better product to start testing with.