How to start with TEst driven development(TDD) for my project

[DarkKnightess]

I am the Scrum Master for a project and we are now planning to start implementing TDD. I have not used TDD so have a lot of questions pertaining to that. So here it goes.
1. Are there any pre requisites before we start TDD?
2. Do the developers start writing all unit test cases as soon as sprint starts and then start writing code to pass all those cases?
3. If QA is doing automation testing, then how does TDD and automation scripts gel in?
4. Where does the team capture these TDD test cases, is it on JIRA and if so where?
5. Are there any tools that the team would need to start TDD?
6. How do we showcase to the client that we are indeed doing TDD? Is there a way we can capture something from JIRA?
I would love to get answers to any of the above questions or all of the above questions.
Your help would be highly appreciated.

Thanks.

[Marta Woźniak-Semeniuk]

- it is an old question, but maybe someone will find it before asking their own, so here it goes :) -

First of all - it is awesome you want to start doing TDD. 
Most important question to ask yourself is - why did you decide to do TDD - because answer to that will guide the next steps.

1. It would be good to first make sure that all team members - including PO - know why are you doing TDD, understand what TDD is and how it should be done to bring the outcomes and outputs you are aiming for.

2. Yes, in TDD you write the simplest test possible that will prove whether code works/ requirement was met and then write the minimal amount of code that will make the test pass. In my organization QAs would write test ideas a sprint before so that developers could see them before they start coding - this helped the team to avoid many bugs before even the first word was written.

3. I have seen TDD that was only done on UT level and a TDD that was encompassing more complex things - a BDD. It depends on a project - but in every case it is worth talking about what things will be tested with TDD so that automated tests written on a another level do not re-test the exact same thing in the same way - what is UT tested as a single thing can be tested again in a chain as for example - user workflow or business path. 
It usually takes a sprint of a few for the team to figure that out - pairing or mob sessions help a lot!

4. My teams did this in the code repo, but included link in the JIRA issue to keep easy access.

5. That strongly depends on your tech stack - search for "TDD" + "whatever language/tech you use" and you will easily find an answer. If you go towards more BDD than TDD - cucumber.io

6. Invite them for a session with an example story shown - how you as a team took a business requirements, made them into tests in TDD and then wrote code - while telling them what possible traps or misunderstandings did it help to avoid.

Hope that helps!