Releasing an app is not an easy process. Once an app is rolled out to the customers there is no way of rolling it back like on web platforms. Imagine a native mobile app as a good old burned CD that was shipped as a part of a magazine or hardware parts containing the drivers. Once it’s burned and shipped you can’t fix it. The same applies for native mobile apps. Therefore, a solid mobile app launch strategy is key to success for every company.
Before an app can be released it’s important to know all the technical information about the software development cycle. How many developers, testers (internal or external) are involved in the app development. How often will the app be released, what is the sprint cadence. Is there an internal or external beta testing community in place that can be used before rolling out the app to the customers? As a foundation for the release strategy this kind of information is important.
When the development cycle comes to an end it’s important to gather all the required release information from the product team. Every release should have meaningful release notes informing the user about the new release. The store descriptions must be updated as well images.
Before building the release candidate of the new app version, every team must execute the automated checks and see if they pass. Additionally, it’s recommended to perform a last exploratory testing session to see if all the critical parts and the new features are working as expected.
The last thing before going live is to check the release checklist. A checklist for a release must be in place to double check that nothing was missed out. Find out in my last blog post for applause what the release checklist is all about and what needs to be done in the post release monitoring.
Read the complete article here:
LINK 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.
Mobile Testing Checklist
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.
Link to the survey
Once the survey is over, I will publish the results here and will outline upcoming blog posts.