For our fourth TestBash Netherlands talk, we were joined by @alihill to talk about how we can share the testing with other members of our team.
If you’ve got questions for Ali about the talk, add them here 
Remember to 
questions that you like to show appreciation for others.
Access the Q&A Session at 1:00 PM here:
https://app.hopin.to/events/testbash-netherlands-online-2020-16-october/sessions/836eb89c-6e98-4ca7-9867-8ff9511bf928
My laptop shut down in the middle of your talk so I apologise if you addressed this already 
What would you say to people who ask:
Great talk! Can you share a few tricks to get developer on board with this? A bit context about this question, I have managed to do some of these however some developers are more resilient to this approach. Sometimes just chocolate and sharing Spotify playlist are not enough.
Just wanted to say it was a very good talk. Very recognizable. I also try to empower my developers in the team into testing. And they really enjoy it ! Making the feedbackloop as short as possible and having fun delivering value to the customers.
What’s your vision on being the ‘rubberduck’ to the team? I think it a very strong ‘technique’
How do you deal with developers who see the value of automated testing but still neglect the maintenance it requires or fails to see it as part of their responsibility?
Thank’s to @alihill for answering!
The team I’m in has access to the tests, they’re part of the production codebase and they’re always involved in PR reviews, however when the tests fail they just shrug and expect QA to jump in and sort the problem. It has to do with this step not being a part of the deployment pipeline, however I also notice is a matter of mentality and a sense of ownership. Any insights you have on this would be helpful. Thanks again!
Thanks Maria!
I’m still doing a bit of hypothesising so sorry if I make any incorrect assumptions below!
My recommendation would be to speak about your team’s Definition of Done or working agreement. I suppose if we look at it from the developer’s perspective, they don’t need to fix the tests before they release software, so why should they bother?
A Definition of Done can be really powerful if the team respects it. That means that people in the team need to hold themselves, and each other, accountable when this standard isn’t being met.
On the other side - are the tests failing often? Does the team see value in the tests that are failing? Does it highlight a problem in the product when the tests fail, or are the tests flaky?
If people don’t see value in the tests they’re running then they’ll also be less likely to fix them. I’d suggest that any test that doesn’t provide value should be deleted from the test suite.
Hope this helps! Let me know if I’ve misunderstood anything, happy to keep this conversation going.