Podcast

119: Mobile Selenium Grid Setup with Justin Ison

By Test Guild
  • Share:
Join the Guild for FREE
Juston Ison TestTalks Feature


Are you looking for an awesome mobile grid solution like Sauce Labs, but don’t yet have a budget for this type of service? Although using an existing Cloud-based service is optimal, there are times when — and reasons why — having your own in-house mobile grid setup can be useful.

In this episode Justin Ison, a senior software engineer at Microsoft, will walk us through the tools, best practices and pitfalls to avoid when setting up your own Selenium mobile grid.


You’ll want to listen up, because Justin works on the popular and cool app Wunderlist — a simple task management app that can be used across loads of devices — so he knows how to get mobile automation done.

About Justin Ison

Justin Ison

Justin has have over seventeen years of experience in Quality Assurance and Software Development. He has been a Director of QA and Test Automation for several different companies, both startups and large corporations. Responsible for implementing best practices, automating the entire technology stack, hiring personnel, and mentoring. A skilled engineer with a relentless passion for breaking things for all the right reasons mercilessly tests and scrutinizes applications in the ongoing pursuit of bringing them to a state of public readiness.


Justin has a passion for architecting test automation frameworks, finding new efficient and effective ways to improve software quality with software, and giving back to the open source community by contributing and giving insightful talks at meet-ups and conferences.

Quotes & Insights from this Test Talk

  • I had no intention to ever go this route. There's well established test automation cloud services out on the market currently and there are several in Europe as well. However at the time, Wunderlist was a small startup and we didn't have a lot of funding allocated in our budget to run all our tests all the time, we'd never commit to these tests services. However, I still wanted to run tests there whether it's run or quick smoke tests just to get exposure to more devices.
  • Running tests in parallel brings on a whole other level of complexity. Especially with data sets like you said. Fortunately at Wunderlist we have an API, public API that we use. Every user on every thread is it's own user, creates his own data and then after that test is completed, it's torn down and deleted, the information is deleted. None of the data on the other tests is impacted by that user.
  • We used Jenkins internally for the local lab and yes, it's just setting up a job for Android and iOS to compile and build. Once a change has been detected for, we use anything like as a master branch, we compile it and from that job we have a downstream job that will then do like a test set up for our mobile devices like, even for emulators, if you're emulators, it will actually launch emulators, get them ready. Once the emulators have started, it then has another downstream job that runs the test. Then once the test runs we have a downstream job to then close all the emulators.
  • Allure is an open source framework, test framework. It's almost in every single language out there. I use Rspec Ruby, but there's one for J-units, end units I'm sure for C Sharp, I can't remember how many but it's getting more and more popular. I believe its a Russian company that built it. It's really nice because you can, it's very dynamic, you can customize it to the way you want it. You can attach different types of attachments in it, which is nice. That's what I do for ours. All the meta-data that I capture like logs and videos and screen shots, I can throw those all into the test report so I have them there for de-bugging after.
  • It's almost basically very similar to like a web automation test approach. Just very small tests. Each test doesn't rely on another test to pass. I think the smaller the test the better. I think you should for good tests framework setup, you should always try to maximize all your tear ups and tear downs into common steps in those areas so that whey when you're tests actually run they're only running steps specific to what you need to do for the tests. Sort-of along those lines.
  • The one advice, yes, just don't give up. How frustrating it could be, I've been there. Just like any automation, just keep at it and you can end up getting it to do what you need it to do by working through it.

Resources

Connect with Justin Ison

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.

SponsoredBySauceLabs

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