168: Testing @ the Speed of Concurrency with Mike Millgate

By Test Guild
  • Share:
Join the Guild for FREE

Learn the what, why and how of testing with concurrency. In this episode Mike shares his automation journey from in-house machine testing to cloud-based testing. You’ll also discover some lessons Mike learned while working on the HealthCare.org project.

About Author Mike Millgate

See. Try. Ask. Learn. Share…

Along the lines of the old parable, “Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime,” Mike Millgate leads by example, offering up his fun-loving leadership knowledge and troubleshooting skillset to build successful self-sustaining teams.He is an energetic, driven, perfectionist, looking to spread the culture of: See. Try. Ask. Learn. Share…

Mike is a self-proclaimed Automation Architect / DevOps Extraordinaire, promoting the mantra “Quality is a team effort”. He tests. He automates. He innovates, all with a joyful grin.

Quotes & Insights from this Test Talk with Mike Millgate

  • A shining moment in my career path I guess being able to be involved with the healthcare.gov tech surge back in 2013 2014 and really whatever side of the debate you're on was that you were for or are you are against it. Well, I wasn't concerned with that. What I really wanted to do I use that as was a great honor for me to be able to be involved. To be able to help the American people the United States with whatever the direction goes for health care in our nation. And so how I was involved with that the organization I worked for was involved with some of the tooling that was being used to get things up and going. They were needing help. Requests were made. I jumped for the opportunity to go and help. And while I was there it was actually quite a cool experience. It was very chaotic as you could tell because everybody was watching it at the time was on the news it was everywhere. And so where I got plugged in was just trying to test some of the certain features of the website to get it stabilized.
  • I would say the biggest hurdle that was being experienced when I got dropped into it which was like the end of October of 2013 was a communication breakdown. Teams were battling with each other pointing fingers at whose fault it was and they weren't focusing on trying to solve the problem. So that was kind of some of my skill sets as well as trying to get the organization in place to kind of help provide focus on the areas that needed to be focused on to get fixed.
  • I don't know what they necessarily focused in on the performance testing and if performance testing was being done it was being done way late in the game. And so it was kind of an afterthought that and sort of the waterfall approach to testing and seeing what was going on out there with the organizations and the different teams that were involved. When I plugged in to me it seemed like they had lost the ability to communicate and they had lost the ability to kind of take on the testing capabilities of pushing quality further upstream and putting the focus there rather than having it being an afterthought.
  • My perspective and philosophy behind automation and testing is is we don't create silos within the team. We don't have manual testers. We don't have Automator. We have resources and those resources do all the tasks.
  • I don't want the resources that I interact with writing a line of code until they have actually written plain text in a document somewhere or communicated some way that shows what their testing strategy is going to be for automation because they want to make sure that they understand the concepts they need to be able to be successful and create automation that is less maintenance down the line. My perspective is automation and testing in general. It's front loaded. I prefer to have lots of up-front work looking at it designing it solving the problems before we even write a line of code because we might get to a point where we say this isn't even something that should be automated or is impossible to automate right now and we haven't wasted two days worth of time writing all this code to come down the line to say this isn't valuable anymore.
  • Probably the best advice I can give is to have fun with your testing adventure whether it be a single test case or a million test cases all running together. You need to have fun. If you're not having fun then your career choice or your pathway become sort of mundane and we go through lows. We have highs we have lows. We have to work through those. Know your limits understand your limits. We're past your limits and have fun. Concurrency wise. Make things small. They focused on being fast and tweak where necessary. Review review review and be OK to fail.

Connect with Mike Millgate

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!

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