Tuesday of TestBash Manchester week, we’re focusing on all things automation with @lgibbs 
We’ll share any resources mentioned in the talk in this thread as well as stories of how trying Louises approach works for you 
If you’ve got any questions for Louise, add them here and don’t forget to like questions that are already asked to increase the chances of them being answered live 
If people find themselves ready to chuck in the towel when it comes to learning automation - how could they learn to lean in and keep going? Is there a way to foster support?
Any advice on where to start for someone who is looking to start out with automation? I have never done anything in this area before and feel totally lost on where to start! What are the key tools I should be asking the company for?
Have you ever had someone uninterested simply refuse to get involved or want to stay up to date? How have you dealt with that?
In a company where the devs have “owned” automated tests (we do TDD, which is one cause of this), how do you help testers “push” into that space? It can be intimidating and devs might not be keen as it could well slow them down.
How do you work out what tests fit at what level, UI, API all the way down to the Unit Tests?
A common mistake for people new to automation (I fell for it years ago) is to automate everything at UI level when the tests would be better implemented further down the stack, do you have any advice on how to avoid this pitfall?
How do you go about finding out what “next” technology or language might be the best step to progress with?
Do you feel that a Test Automation Engineer is full time role or can it be a mix of Manual and Automation?
If people find themselves ready to chuck in the towel when it comes to learning automation - how could they learn to lean in and keep going? Is there a way to foster support?
Step back and look at what you already know. Set yourself an easy task, which you can complete easily - this will really give you a confidence boost.
Then, explore and expand on what you already know rather than learning something completely new. Be creative, try something a little different. Is there a different way you could have done this? Was it better or worse?
When answering this question, I said that the manual and automated roles can easily be mixed. I’ve never been in a specialist automation role, and not sure I’d ever want to be. The amount of time I dedicate to either varies depending on the current team and what work needs doing.
However, if setting up an entire framework or working on a bigger automation task in general, you’ll need to spend a significant amount of time on this. So, you’ll need to speak to your team about allocating time and arranging for someone else to pick up the slack on other testing tasks. You may find you’ll need to temporarily spend 100% of your time on this.
Once everything is setup, general maintenance of the automated tests may not require 100% of your time. Not all tickets that you work on will require work on the automated tests, but you should have that discussion when refining each ticket. If updates or new tests are required, include this in your definition of done. You could have both the manual testing and automated test updates done by the same person or you can split the task between 2 testers. It depends on the ticket, and the skills of the tester.
If splitting the work between 2 testers, you still want to speak to each other. Discuss what changes need to be made, and how best to implement them. If the tester in charge of manually testing the ticket lacks experience in automation, this is a good learning opportunity for them. Get them involved, show them what you are doing, do some pair programming.
I’d recommend looking at TestProject. The basic version is free, and perfect for experimenting with Test Automation. You’re more likely to get support from the company if the only resource they need to allocate is time (even that can be a challenge).
They have some good documentation on how to get started. They ran a competition last year which I completed (but didn 't win 
) which required us to setup a basic UI and API test. This is a good way to get started.
Here is a blog post I wrote about it:
This doesn’t require any coding at all. However, for long term success, you’ll want to look at their SDKs (Python, Java and C# is available). Full documentation is available for each of these.