Automation in Testing Superfriends

How do you educate the other members of your team about your automation? How do you talk to management about automation? We sometimes focus so heavily on the tooling that we lose sight of what it is we’re trying to test.
In this episode, we’ll Test Talk with Richard Bradshaw and Mark Winteringham about their new, imitative website, automationintesting.com. Discover how to be truly successful with your testing efforts by leveraging the right tools to help you test the right things.

About Richard Bradshaw

Richard Bradshaw is an experienced tester, consultant and generally a friendly guy. He shares his passion for testing through consulting, training and public speaking on topics related to testing. He’s a fan of automation that supports testing. With over 10 years’ testing experience, he has a lot of insights into the world of testing and software development. Richard is a very active member of the testing community and is currently the FriendlyBoss at the Ministry of Testing. Richard blogs at https://thefriendlytester.co.uk and tweets as @FriendlyTester. He is also the creator of the YouTube channel, Whiteboard Testing. He can often be found in the bar, with a beer in hand, discussing testing.

About Mark Winteringham

Mark is a tester, coach, teacher and international speaker, presenting workshops and talks on technical testing techniques. He has worked on award-winning projects across a wide variety of technology sectors working with various Web, mobile and desktop technologies and is an expert in technical testing, test automation and a passionate advocate of risk-based automation and automation in testing practices which he blogs about at mwtestconsultancy.co.uk. Mark is also the co-founder of the Software Testing Clinic in London, a regular workshop for new and junior testers to receive free mentoring and lessons in software testing.

Quotes & Insights from this Test Talk

So AutomationInTesting.com(AIT) is basically a new namespace created by myself and Mark. Not to dictate and say this is how it’s done. But it is a place where Mark and I can work together and produce content that we both aligned with and also we think it’s something that the industry needs because it’s not as much about the tools AIT is more about the bit that goes in before and the bit after it. So yes a namespace me and Mark can actively be working on trying to improve the automation space and testing.
I’ve always had this notion that I’ve been using tools to support my testing effort. I’ve never been able to replace myself with a tool. There are little bits of the activities that I would do. But the actual whole end to end process I’ve been unable to ever fully automated
AIT is essentially you know a namespace where we talk about the design factors. A lot of the theory that goes into automation. We then talk about the creation. So how would you go about creating good, maintainable automation that isn’t flaky for one? But then we also delve into the world of education. So how do you educate other members of your team about your automation? It could be other uses, could be other testers in your view who are going to use your automation or it could be management. How do you talk to management about automation? And so those are the kind of the key aspects of what you want to shift away from the tools. If you can master the theory then you should be able to pick any of the tools out there and hit the ground running.
Lately, I’ve been really interested in using the GROW model for coaching. But as a means to identify problems that automation could solve. Now nobody else is really talking about how you could use coaching techniques to support your automation. And it’s through these discussions that we’ve had this kind of opened up all these new different avenues of research and sort of experimentation which is really cool.
First of all, it’s not to say that we’re sort of against tools and saying they’re useless. They’re obviously an essential part but what we’re saying is that sort of the process of implementing something should start with the analysis of problems. Like from my perspective I’m very keen to talk about modeling and learning about our products and our teams and how they work. Sort of asking questions and exploring and learning as much about them as possible and then bringing that together it’s a successful model that you can actually use as a way to sort of identify different types of problems. Because once you sort of identify those problems the actual tooling side becomes a little easier. So that’s why I say you want to have a good knowledge of different tools. But knowing what the problem is making it easy for you to just choose the right tool. When it comes to implementation things sort of becoming a bit more fluid. They flow a bit better because you’re not fighting against the tool trying to get it to work in a way that’s not necessarily right for you.
One aspect I want to do with ministry testing going forward is getting the community talking to the tool vendors more. A lot of the time it’s one way. It’s the tools vendor saying we need their tool. But I think some of them could benefit from engaging with the community to find out what problems they’re actually facing and they may find new opportunities there. New products that they could build. They may find they may only have a product that they can be framed. But if they don’t start having these conversations then you know then that they’re going to miss the opportunity. Those conversations will benefit the whole community and the whole industry.

Resources

Connect with Richard and Mark

May I Ask You For a Favor?

Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page.

Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.

Test Talks is sponsored by the fantastic folks at Sauce Labs. Try it for free today!