As announced by Apple at the WWDC 2017 there will be a new AppStore coming this year with the possibility of a phased release for automatic updates. The new feature will provide companies and developers the chance to roll out new app releases to a smaller user base to see if the new version is stable and if the new feature is appreciated by the customers. Apple offers the following steps:
Day 1: 1 percent
Day 2: 2 percent
Day 3: 5 percent
Day 4: 10 percent
Day 5: 20 percent
Day 6: 50 percent
Day 7: 100 percent
Apple selects users for each bucket randomly based on their Apple ID, which is better than the device ID, because users may have several devices like an iPhone and iPad and then they get the same app on each device. And users can only be selected by Apple if they turned automatic updates ON.
Once an app is configured for the phased release, the app must pass each step, which is from my point of view not really flexible. Maybe companies want to start the phased release with a bigger customer group than 1, 2 or 5 percent to get faster feedback. However, on the other side it provides a nice way to monitor new features in the live environment and to react on possible issues and it’s the right way to give companies and developers more options to release an app. Stopping the phased release is possible. Developers have the option to push the app to 100% at any time via the iTunes connect. Read more
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.
Are you an Android developer or app tester? Do you want to learn from or get connected to other peers in the Android community? If so, there is something useful you should read and check out.
Andreas and Jessica from AnySoftwareTools, recently created a big list of Android development resources. The list covers a wide range of materials including blogs, tutorials, forums, podcasts, and social media communities. Whether you are new to Android programming, or you are a veteran who’s managed to develop an app, you’ll love this resource.
The list includes 46 blogs and tutorials, 11 forums and Q&A websites, 12 YouTube playlists, 5 podcasts, 10 Google+ communities, 11 Facebook groups, and counting. Did we miss any resources you like but not mentioned there? Let us know, we will be happy to consider adding them. That’s the value of keeping a resource updated, isn’t it?
Anyway, check it out and let us know what you think. If you like it, feel free to share it out. Happy reading and coding!
About the author
Jessica Carrell is a technology enthusiast who founded AnySoftwareTools with several geek friends. When she is not coding or writing tech stuff, she loves shooting photographs behind her camera lens.
At the start of my testing career ten years ago, I chose to tackle the challenge of mobile device test coverage. At the time, I tested multiple apps that had been developed for BlackBerry devices. Each carrier in North America had their own set of BlackBerry devices with their own unique version of the BlackBerry OS. It was important to verify that the app functioned properly on both GSM and CDMA carriers, so testing one hardware/OS combination on one network would not be enough as there were multiple screen sizes, not to mention multiple versions of the OS on the same hardware. The combinations were endless and it was quickly realized that, without a QA team of a hundred people and an endless and varied supply of hardware, we were going to have to make some tough decisions about where to focus our testing.
Today, this problem is even more evident. With literally thousands of hardware/OS combinations of Android devices, it’s just not feasible to test each of them and expect to release a product in a timely fashion.
7 Considerations To Achieve The Best Test Coverage
Let’s assume you are developing a mobile app for Android and iOS. Where do you start when it comes to identifying the hardware/OS combinations to focus on? I have identified seven things to think about when working to maximize your test resources. Read more