What can we learn from the Gmail iOS App escapade?
FarazSyed 270003YF35 Visits (1372)
Since its invitation-only beta release back in 2004, Gmail has grown to become of the most popular email services in the world boasting over 260 million users. It has received critical acclaim from across the ecosystem, ranging from the media, to users and web developers, and it has become a central hub from which Google has promoted other successful services.
With the rapid adoption of smartphones, the ability to access email on your handset in a simple, fast and function-rich environment has become a basic requirement for the end-user. Online services have begun to leverage HTML5 to provide this functionality irrespective of the device; however, demand for native applications that provide smoother functionality is still in high demand.
Getting Gmail on the iPhone has, up to now, been a bit of an arduous task. Users have had to input their Gmail data into the phone’s Mail app or access it via a browser, which ultimately lacks several of the features that are included in the online version. So, when on Wednesday, the Gmail App for iOS became available, the industry was excited – well until they tried it out.
A flood of complaints from early adopters around a bug with notifications resulted in an apology from Google (both on Twitter and their blog) and the removal of the app from the App Store. So, what happened that allowed a buggy app get through two traditionally comprehensive testing processes? Well we don’t know and are never likely to, but perhaps we can learn a lesson or two.
When speaking to our customers one of the most common reasons that we have found is that they previously only tested a fraction of the real-world scenarios. Bug proofing on an emulator, a single test phone hooked up to the computer or a quick trip down the road for real world testing is not enough and they were surprised when they encountered end-user complaints.
I am not suggesting that Google or Android test this way, in fact they both have an impeccable track record in my opinion, however it illustrates the point that companies need to test a lot of different scenarios before going live with a new app. Now, we don’t expect people to fly all over the world, purchase thousands of local handsets and go to remote mountain summits to test functionality – it’s financially prohibitive and impractical to say the least. But by leveraging a cloud-based, SaaS solution which automates the testing of all of your mobile apps and websites, combined with a test plan, you can have a comprehensive real-world QA process. But it shouldn’t end there, as mobile is far from static, it is constantly changing with new spectrum, operating systems and user-cases requiring ongoing monitoring, product improvements and updates.
As this case shows, no one can guarantee that an app will never go out with a bug or not perform as expected in a certain user case, but we can work together to mitigate the risks.