98: The Hitchhiker’s Guide to Test Automation with Mark Fink

By Test Guild
  • Share:
Join the Guild for FREE
The Hitchhiker's Guide to Test Automation Test Talks Feature

Do your test automation efforts leave you feeling depressed and bored, like Marvin the Robot in The Hitchhikers Guide to the Galaxy? Do you wonder what the meaning of test automation really is? Good news! In this episode we’ll be speaking with Mark Fink, author of The Hitchhiker’s Guide to Test Automation, where he’ll reveal the answers to all your burning test automation questions.

About Mark Fink

Mark Fink The Hitchhiker's Guide to Test Automation Author

Mark runs an independent consultancy FinkLabs that provides software testing services. His combination of academic qualifications and 20 years' practical experience have made him a popular software test automation and performance testing speaker at a number of international conferences. He’s also the author of The Hitchhiker's Guide to Test Automation and the creator of many test automation and performance tools including GoGrinder, which can help you and your team check the stability and performance of your code.

Quotes & Insights from this Test Talk

  • This is really a main part of the book. Sometimes people maybe talk about test automation. They jump right to the tools and I added this chapter to make it very clear from the beginning that this test automation is also about people. It's very important to deal with the fact that not everything can be automated and people are involved and also the software development process that we are talking right now is very, very important. We are talking about a software process and in this discipline is the most important factor. Without that, that test automation doesn't really make much sense.
  • Often, when teams want to improve for an area, they just look for tools. Then they want to do some monitoring so they install Nagios or for continuous integration, maybe they start in this area. They just installed Jenkins. For analysis, they install Sonar, et cetera. The tools is usually the easy part. Many times the initiative stops with the tool installation. Once the tool installation is done, for my perspective, it takes much more than that. The tool needs to be configured and it also needs to be maintained because the situation changes over time and different team consolation, more developers, less developers. That needs also always some adjustment to the tooling.
  • I think the most important factor is that you have the scope right. You cannot test everything and usually this is a requirement. The business people require from the developers, from the project that everything is tested. This is also a question of resources of time, and so you cannot just test everything so you have to find an intelligent way to structure your test and I was already referring to this pyramid of scope.
  • I have seen many times that project put a lot of effort into test automation but once the test read the reports, failed tests, it's usually difficult to see what failures are new and what failures are already known. People start not to care anymore about the test results and then you put in a lot of effort without getting any benefits from test automation. It's very bad place to be but often very permanent. I think this API dependencies is one of to make sure things that cause this problem.
  • GoGrind is open source tool to similar target load on your application and to measure the response time and throughput. I work in technical testing and a main part of that is performance testing for more than 12 years now. I use the old kind of proprietary and open source tools. Many things happen during the last couple of years. This really changes the environment. I'm thinking about DevOps, a lot of tools for visualization monitoring. Also provisioning tools that make it easier to performance testing, low testing of the application.
  • One thing I learned recently. There is this book Toyota Kata from Mike Rother. This is really important. I think he studied, I don't know exactly anymore, but I think he studied Toyota for like 20 years. He came up with this framework how to approach things in an enterprise environment. He said it's very important to know your current situation and to know the target situation. Then you can identify a gap and you make an alternative plan how to close the gap. This is very helpful to improve testing efforts in my opinion.


Connect with 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!

Leave a Reply

Your email address will not be published.

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

{"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, ...