Mobile apps release process at Metropolis:Lab
After attending Test Automation Day 2018, the first thing I did after returning to the office was to order the books recommended by the speakers and watch Pan Thomakos video of his talk at Pipeline Conf 2018 on “how Strava releases their mobile apps to the world”, recommended by @JonHW87.
15 minutes into the video I shared it on slack with the mobile developers with the quote “oh my god, this is amazing!!!”, only to get a reply “dude, we’re already doing this”.
The “the grass is always greener on the other side” saying was never applied so well before…
Our current process
So after that reality check I started investigating exactly what we were doing right (and wrong) in our mobile app release process andthis is what I found.
For development builds we are using Fastlane and Bitrise, releasing a new build on every merge to development branch.
For beta builds we’re releasing to Crashlytics (now integrated with Firebase) and sending a build to all the testers and Product Owners.
Each “lane or flavour” is setup differently, connecting to a different database in firebase and only the beta builds are sending crash reports to Crashlytics.
Translations
We’re still trying to find the right tool for translation handling / localisation. We’re giving Loco a go to see if it works for us (beats having an excel sheet every day of the week :D ).
Where does the tester participate in the process?
Continuous Testing
We’re still trying to define our QA process, but the main idea is to practice continuous testing both manually and automated.
We’re building a test framework based on Appium (using Kotlin) and we want to have some basic UI tests done in Espresso and XCUITest that will run on Bitrise. This will give the developers quick feedback if something major is wrong, like the app is not booting or elements on the home page are not showing up.
We want to also practice the Shift Left “methodology” in order to discover bugs sooner rather than later and give the developers a testing mindset, focusing on unit tests and trying some happy paths on the app before they merge the code (lost count of the times I picked up a build to test and it wouldn’t even start, C’mon people!!!)
Conclusion
I’d say we are very much on the right path, we’re just starting to define our processes but we a have very senior and experienced team that knows what they’re doing and when they don’t, they know where to look for solutions.
