Podcast

47: Richard Bradshaw: Can Automation Do Actual Testing?

By Test Guild
  • Share:
Join the Guild for FREE
Richard Bradshaw TestTalks Feature

Can automation perform actual testing? What’s the difference between test automation and automation in testing? Discover a mind-shift that will help you improve your testing efforts and take your automation to the next level. In this episode, your friendly tester will free you from the common misunderstandings and myths of test automation and leave you smiling. Check it out!

About Richard Bradshaw the Friendly Tester

RichardBradshawHeadshot

Richard is a friendly tester with a real passion for testing. He is very active in the testing community and hosted the very popular meetup in Nottingham called #NottsTest. Richard is also a founding member and co-organizer of the Midlands Exploratory Workshop on Testing (#MEWT).

Richard is currently working as an Independent Tester after having set up Friendly Testing Limited in 2014. He has been testing for over 8 years now.
Richard is a big advocate of automation, but not the silver bullet type, the type that really supports testing and testers. He is very technically minded and encourages the use of tools.

Quotes & Insights from this Test Talk

  • Test Automation is any use of hardware of software tools to support testing
  • Instead of saying Test Automation we should refer to it as Automation in Testing. This mind-shift should help you to consider other ways in which automation can help you with testing.
  • Our basic Automation Architecture should include at least functionality for Data Management, Page Object  and Driver Factory
  • We should focus on testing and how automation can support it NOT replace it
  • Automation is really good at checking which is just a small piece of testing
  • Checking is making evaluations on an algorithmic bases
  • Automation can't think and learning is a big part of the testing process
  • Automation doesn't replace testers it supports testers
  • Testers should get involved in the development process as early as possible
  • Much, much more!

Resources

Connect with Richard

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.
SauceLabsSponser

Sponsored by Sauce Labs

Special offer for TestTalks listeners, get 20 hours of automated testing for free when you sign-up with promo code testtalks14 (more info).

Also sponsored, in part, by: https://www.business2community.com/cryptocurrency/best-bitcoin-casinos-with-instant-withdrawals

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  1. I agree with a lot of what Richard is saying, funny thing is that these ideas and thoughts have been around for a long time. And that is part of the problem in that they are not communicated to the masses outside of the testing world. When they are they are either ignored or misunderstood because of not explaining clearly what is being talked about.

    The ideas of using “automation” to do non-testing activities (data generation, data/test condition setup, etc.) as “utility” type processes is something that just doesn’t get thought about. Automation is a way of doing “computer assisted software test execution” (CASTE). Automation of testing allows for shifting the workload to a computer, or set of computers, to perform the repetitive actions of a tester. This primarily translates into aiding in Regression Testing. We let the machine do the grunt work for us, and by also taking the workload stack and putting it on its side we can divide it up and then schedule it to run in parallel. Thus a perceived increase in speed of execution, what I like to call the “Illusion of Speed”. The overall time to run the tests is the same, but because you can run them in parallel you get a “compression” effect. You get greater efficiency in execution.

    All in all the key thing is for us, as testers and “automator’s”, is to communicate these principles and make sure people understand what automation of testing can do and cannot do. Fixing misconceptions first will make the rest of our work a lot easier later on. I’ve spoken about this a lot over the years, and especially during presentations at conferences.

    I heard you say Joe the idea of “magic” in automation. My favorite saying is “It’s Automation, Not Automagic!” Good talk with Richard though.

    Regards,

    Jim Hazen

  2. Hello Jim,

    Couldn’t agree more, one reason I no longer use the term Test Automation, because people read it as that. Regression Testing is actually something I am turning my attention to soon, because as you mention, its highly associated with automation. I believe this to be a big problem. But words are flowing yet, but they will do soon.

    Nothing of what I said is original, perhaps the phase Automation in Testing but everything else should be obvious, but sadly it isn’t, again as you alight to.

    I for one will keep pushing the testing message and that I can use automation to support me in many aspects of my testing, I know many others are, hopefully some progress will be made.

    Regards

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

267: Smart Test Execution with Eran Sher

Posted on 08/25/2019

Do you run an entire automation test for every build because you don’t ...

266: Automation Journey and TestNG with Rex Jones II

Posted on 08/18/2019

In this episode we’ll test talk with Rex Jones about his automation testing ...

265: TestProject a Community Testing Platform with Mark Kardashov

Posted on 08/11/2019

In this episode, we’ll talk to Mark Kardashov, CEO and Co-Founder of TestProject, ...