162: Shift Left Mobile Application Testing with Satyajit Malugu

He blogs at mobiletest.engineer and you can find him on twitter at @malugu

Quotes & Insights from this Test Talk

• GoDaddy has been going through a shift-left transformation when I joined it. They were interested in mobile apps and a lot of the newer concepts of agile and test automation by the time I cam in. But nothing in the test automation side for mobile. So when I got in we had some of Calabash test but they weren't running as part of the bill. So that was my task. Create a framework both for Android and IOS apps that would give the feedback quickly. This is the time when I was listening to your podcast and I picked up the word shift-left from you. So I explored more and more about it and that seemed like what we need to be doing.
  
• One of the first steps that I did was our Dev build jobs are already running on Jenkins. So I wanted to make our UI test part of that as well.So whenever there is a pull request unless the UI test passes you can make the build job as green. So that's the first step that I started and then I realized this is much more than that. The developers started using the fast feedback that they were getting. So we started going in more deeper. So right now I went a step further and now all the automation that we have is part of the same depot as the dev depot and whenever there is a commit we will trigger a build.
  
• Expresso has helped a lot with test reliability and also Expresso is in Java. So the developers have no excuse – they can look at the automated tests and understand them much better.
  
• One of the difficulties for test automation is getting to a parallel state. And it's especially difficult for mobile.
  
• Do as little as possible in the UI tests and more in the API test or Integration tests and much more at the Unit tests. The principle is if you can do something at a lower level of the pyramid make a preference to that. Only if you need a scenario coverage or if you can't do something at a lower level then only then create a UI test. And also, in general, we go by like one one test case for a feature like there is a new feature it will have one UI test but not usually really more than that unless the acceptance criteria say so. 
• One thing that many test automation testers miss is — writing the automation part is easy. Keeping them running and making them constantly give feedback is the hard part. Anybody can pick up a test automation tool and write a few test cases and say “My job is done". But a good engineer would follow thru. Even if it's like two years down the line. He's automation code so still, be running to be running and should be giving feedback when it's useful.
  

Resources

• Shift Left Mobile Testing Slides

Connect with Satyajit Malugu

• Twitter: @malugu
• Blog: mobiletest.engineer
• LinkedIn: Linkedin.com/in/satyajitmalugu

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!