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
What are your Mobile Testing Pain Points?
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 … Read more
The Mobile Release Train
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.
[Reblog] How to convince your colleagues to write Automated Tests or why would you use Cucumber as an Automation Tool
This post is a reblog from Serghei Moret, who is my colleague at XING. Serghei is an awesome test automation engineer developing really helpful solutions for our mobile app environment for iOS and Android. Lately he started to write on his own blog http://www.waysoftesting.com/. In his first post he is writing about “How to convince your colleagues to write Automated Tests or why would you use Cucumber as an Automation Tool”.
I really like the first post from Serghei and I want to help him spread the word about his blog and about his work and effort he is putting in mobile test automation. If you haven’t seen his blog, check it out.
Here is a short excerpt of the blog, the full article can be found here.
How to convince your colleagues to write automated tests? I think that a lot of people have asked this question and probably already found a dozen of correct and incorrect answers. In this article I’ll try to describe the way, how the automation framework was successfully implemented for several teams in different companies. Also I’ll speak about the reasons why you might use Cucumber in a wrong way. […]
Mobile Bug Matrix
Let’s start the year 2017 with some fresh and new mobile content. Today’s post is about the mobile bug matrix. Developing, testing and releasing mobile apps can be a challenging task. However, patching an app to fix bugs is not easy, too. How do you decide which bug is going to be fixed in an hotfix or not? Once a bug is online and installed on user’s mobile phones, there is a high likelihood that the bug will stay there for a longer time period, because not everyone is updating apps every day or has the auto update enabled.
There is no way in rolling back an app version once it has been uploaded. When I explain this problem to people who are not into mobile developing and testing I use the metaphor of a burned CD. Do you remember the good old times, when magazines added CDs with useful tools or CDs containing important drivers for your PC? Then you also remember how frustrating it was when the software on that CD had bugs or was completely broken. Once the CD is burned and delivered there is no way of rolling it back. The only way to solve the problem is to send a new CD ;). The same happens with native mobile apps. Once the app file was uploaded to an app store and users have installed the buggy version, you only have the chance to patch/ update this version with the next version.
Patching an app is time consuming, requires development and testing efforts and maybe even more alignments with other departments in the company. Furthermore, the planned development and testing in the current cycle will be slowed down or paused until the app is patched. And you should also keep in mind that some app stores have a review process in place, which may take some days until the patched app is available to the users.
One way to minimize the likelihood of doing a hotfix is an extended internal testing phase with your colleagues. Another way is to distribute the app to some beta testers to gain their feedback. But we all know that the real nasty bugs happen in the wild on the customer phones and companies need to handle them as soon as possible.