Mobile devices and mobile apps are everywhere these days. Customers are using mobile devices and apps to play games, listen to music, and work from wherever they are. According to TechBeacon, more than half of mobile users will delete an app if it is crashing, freezing, or showing too many errors. As those who work in the field of mobile testing know, a mobile testing strategy is the key to success for a high-quality app. But defining a strong mobile testing strategy isn’t that easy. Mobile testers are facing many challenges to solve. There is device fragmentation, user mobility, high mobile user expectations, and device-specific hardware functions just to name of view.
And the challenges don’t stop there for mobile testers. More and more apps are now able to connect to wearable devices and other IoT devices.
Defining a Mobile Testing Strategy
With the rising complexity of mobile testing, a mobile development team needs to define a mobile testing strategy. With the help of a tailored test strategy, a mobile team can focus on the most important parts to deliver a great app to their users. It’s fairly easy to define a mobile testing strategy that will help downsize the amount of work needed during the development and testing phases. All you need to do is to gather user insights, define user scenarios, and specify your mobile testing approach. If you want to know how to define your own mobile testing strategy in three steps, read my last blog post at the Applause blog.
This is a reblog, of my blogpost iOS Calabash Launcher for MacOS from tech.xing.com. I want to share the post with you, because it might be of interest.
Today, the XING mobile releases team want to give something back to the Open Source community. At XING, using Open Source software in our projects is natural. For our mobile apps (iOS and Android) we use Calabash to write end-to-end automated checks, to verify that the user flows are covered before going live. For those people who worked with Calabash for iOS and Android they know that it’s sometimes really hard to define screens, to detect the ID as well as the text behind an element. The default Calabash installation provides a console based element inspector, which makes it not easy to work with. Furthermore, the default installation from Calabash doesn’t offer any visual device detection, test execution, element inspection or setup possibilities.
But this will change today! We are proud to Open Source our Calabash Launcher. Read more
Every new feature that is implemented on a mobile app must be tested. Of course, software testers can write long test cases and test plans but we all know that the requirements of feature can and most likely will change during the development phase. Sometimes new requirements are showing up or requirements are not important or valid anymore. If a huge test plan have been written it needs to be adapted and this is time consuming. A couple of blog posts I published the mobile testing cheat sheet, to help you not to forget to test important aspects of mobile testing. In this blog post I want to share a quick mobile testing checklist which may help you to concentrate on 10 very important things to test. Besides that I recommend you to create mind-maps instead of long test cases to outline your tests against the requirements.
In this post I want to find out, what are your current mobile testing pain points? I created a very short survey with just 2 questions to gather some information from you. The goal of this short survey is to understand the current problems mobile testers have in their daily work-life. The outcome will help me to outline new blog posts that may help you in solving your problems.
Please feel free to share this survey on all known social media channels or with your colleagues.
In one of my last blog posts, I wrote about the Mobile Bug Matrix and how to use it to identify bugs that are worth doing a hotfix. Today, I write about the mobile release train and how to use this approach to release apps to the different app stores.
The release train concept is nothing new and is part of the scaled agile framework. It describes how to deliver software in a specific way. The concept of the mobile release train can be used by small and/ or bigger distributed teams who work on one app, but in different teams. Usually smaller app developer teams/ companies release an app whenever there are enough bug fixes or new features that make sense for their users. However, apps that are developed across multiple teams need an aligned approach to plan releases in advance. If more than one team is developing features they may depend on each other and can’t release without the changes from other teams. In this case, it is not possible to just push the release button to upload an app, this approach will fail.
The Mobile Release Train
Let’s take a look at a mobile release train. In the following picture, you see a simple one. It has a defined development phase in most cases 2-4 weeks. On a defined day and time let’s say on a Monday at 3pm, there is a code freeze happening. Until this time, the teams have the time to review, test and merge the features to the master branch that should be part of the train. At 3pm someone will create a release branch from master branch, either manual or in an automated way. This release branch will get a final integration testing phase. In this phase, all team members should check that the new features are working as expected. If there is a problem on the release branch the bug will be fixed on the release branch and later merged back to the master branch.