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. […] Read more
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.
Mobile Bug Matrix
It’s bin a long time since I wrote my last blog post. At the moment there is not so much time for me to write down all the posts I have in draft mode. Sorry for that! However, since christmas is almost there and the german edition of my book Hands-On Mobile App Testing is available since end of September with the title Mobile App Testing, I want to give all my german speaking blog readers/ lurkers 😉 the opportunity to win a signed copy of the german edition.
This time I changed sides and created the 30 days of mobile testing challenge in cooperation with Ministry of Testing. The last software testing challenge created by Ministry of Testing was a huge success and many software testers from around the world participated. It was great seeing the progress of so many people and I really learned a lot during this time. If you want to check my 30 days of testing challenge, take a look here. Since the last challenge was about general software testing, Ministry of Testing asked me, to create a dedicated challenge just for mobile testing. Over the weekend I shaped the challenges and I hope you like them. I am really looking forward to see your results on all the different social channels. Feel free to share your progress also as a comment to this blog. The challenge will start in October, but don’t hesitate to start it today :).
At the end of the 30 days of mobile testing challenge I will pick the best challenge/ progress and I will send the winner a signed copy of my book Hands-On Mobile App Testing.
And here are the tasks/ challenges. Click the image to get all the details on the Ministry of Testing page. Read more
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