Mobile App QA – Should you automate?

Mobile App QA – Should you automate?

Mobile apps have completely changed the way we live our lives. With the touch of a button, I can find a restaurant, get hotel reviews, get directions, or order a cab. Long gone are the days when I printed out my MapQuest directions and studied them whenever I needed to go somewhere new. While I enjoy how easily information is available to me now through my smartphone, I know it would not be possible if businesses didn’t keep up. Thankfully they are!

Businesses are realizing more and more that mobile apps are the best way to reach the highest number of customers. As more apps make their way into the market, the need for QA and testing also increases. With multiple platforms and ever progressing features, this isn’t such an easy task. That’s why we recommend QA automation! I don’t expect you to take my word for it without any facts to back it up so let’s dive in.

Why automate QA and testing?

Mobile app testing is often very repetitive, tedious, and time-consuming. With automation, you can simplify your process by defining a test once that can be executed multiple times. This reduces your time investment, cost, and error margin while increasing your productivity and test coverage. It also enables you to create a more stable application by making it easier to run tests after every minor change to the code. Essentially, automation will increase your productivity, ensure an agile development team, and reduce overall costs.

This is all very nice but the world is unfortunately not so black and white. While the need for mobile app QA is significant, there are many common problems that QA teams encounter that can disrupt and limit the efficient testing of enterprise apps. Some of the problems that enterprise testers come across are:

  1. Mobile app testing is not thorough – or not done at all
  2. Lags in development can lead to shorter testing time
  3. Lack of requirements can inhibit QA capabilities

To read more about the problems QA folk come across, check out this article: Three Common Problems in the Mobile APP QA Process

Native vs. HTML5 – looked at objectively, the debate is over

Native vs. HTML5 – looked at objectively, the debate is over

Posted by Jonathan Rende on Fri, Apr 12, 2013 @ 04:45 PM

Almost a year ago I wrote a white paper about Native versus HTML5 mobile app development, asking ‘Which option is best?’

Even then, the answer was pretty obvious: look at the question objectively, using a set of clear comparisons, and HTML5 is crushed by native development, even though HTML5 wins on a few points.

Strangely, though, the debate rages on. Just this month, ReadWrite’s Brian S. Hall felt the need to discuss “The Facebook Phone & The Triumph Of Native Apps Over HTML5” as if the issue had yet to be settled.

You could argue that triumph was already clear last August, when Facebook itself abandoned HTML5 for its rebuilt native iOS app. But bloggers and consultants continue debating the question, and customers still ask me about which way they should go.

Why are we still having this debate? My take is that it’s like a religious war, where people aren’t really interested in debating the actual facts. If you do take a serious, evidence-based look at the data that’s available, though, it’s not hard to settle the issue once and for all.

The power of numbers  

A good place to start is with app growth. A recent round up in Information Week  counted 775,000 apps now available in Apple’s App Store and roughly the same number in Google’s Play Store. Add the 135,000 claimed by Microsoft and Blackberry’s 100,000, and you get 1,785,000 native apps in the marketplace.

It’s harder to quantify how many HTML apps are out there. But in a 2012 Appcelerator survey of 3,600+ developers working in both the native and HTML5 space, we found that developers were actively writing roughly 6% of their applications in HTML5. Even if you assume that HTML development has always been as popular as native and then double that figure for a wide margin of error, the total number of HTML5 apps now available still would only just clear 200,000.

Shear volume is on the side of native solutions, then, and I’ve seen no evidence to suggest that that’s shifting. App downloads, meanwhile grew 11% in Q1 2013 over Q4 2012.

 

Nine points of comparison 

But there are plenty of other ways in which native- and HTML-developed apps get compared. In my research, I’ve found nine of points of comparison where it’s possible to make objective calls as to which is superior:

1) Rich user experience (native wins)

85% of mobile professionals in a March, 2013 Compuware survey preferred mobile apps over mobile websites. One of the main reasons was the richer experience users get with native apps. Features like VR, NFC, and passport simply aren’t available in HTML. Where HTML has 30-50 native device capabilities open to it, native developers have access to 6,000-7,000.

2) Performance (native wins)

When it comes to both loading and rendering, whether you have good, weak, or terrible internet access, native is always faster. Click on a calendar event in a native app, for example, and it opens instantly. The time it takes to do the same in an HTML app typically drives people nuts.

3) Monetization for developers (native wins)

Recent numbers from Canalys report that native app developers’ combined income in Q1 2013 was $2.2 billion. In contrast, the monetization available to developers building HTML5 apps is essentially zero. It’s pretty obvious, then, that financially ambitious app owners need a massive incentive to move out of the app store fold.

4) Cross platform development costs (HTML wins, but by less than you’d think)

This is usually seen as a big point in HTML’s favor. The line is that you ‘write once, run anywhere,’ and that’s true, but only up to a point. You certainly have to factor in costs for going native for multiple OSs, although solutions like Appcelerator will help reduce those costs significantly. But they are not zero with HTML5, either, thanks to the next point of comparison: fragmentation.

5) Fragmentation challenges (a wash)

If it’s a challenge to develop apps for multiple platforms (and for different versions of those platforms), even with Appcelerator’s help, it’s not the case that developers writing for the mobile web are writing simply for one HTML5. There are at least 15 mobile browsers in existence, each available in different versions and each supporting different levels of HTML. So there’s a fragmentation challenge with both. On this measure, the two are pretty much a wash.

6) Availability of programming expertise (HTML wins)

There’s no debate here. There are millions of HTML developers out there who will look at HTML5 and say, ‘eureka, I can now develop mobile apps.’ Objective-C, meanwhile, and to some degree Java, are much harder to learn, and people who know them are harder to find and cost more to hire. Again, solutions like Appcelerator’s address this by using JavaScript, a language that pretty much every web developer knows well, but the overall comparison still favors HTML5.

7) Immediate updates & distribution control (HTML wins)

Mobile is all about constantly innovating. Because they don’t sit on the device, HTML5 apps can be instantly updated. In contrast, having to go an app store for an update remains a barrier to offering the best, most up-to-date experience. A win, then, for HTML.

8) Timely access to new OS innovations (native wins big)

Apple and Google offer, on average, 1-3 updates a year that offer major new capabilities. When they are making so much money from their app businesses (see #3 above), they have every incentive to coral those new capabilities within their native OSs and zero incentive to offer them in HTML. Meanwhile, it takes years for the HTML consortium to ratify new standards. At the rate at which device manufacturers are innovating, there’s no way that the HTML consortium can move swiftly enough to compete.

9) Security (native wins big)

People are increasingly worried about security, especially as mobile moves ever further into the enterprise and, frankly, there is no way that anyone could say that HTML is more secure than a native app. Native clearly wins thanks to:

– the security of the source code of itself; browser source code is open for all to see, and to then work around.

– the security of data at rest on the device; on a native app, it’s completely secure. In HTML, the browser is typically not secure and as a result exposes the data it’s accessing within its caches.

– the security of data in transit; when using HTML, you are pretty much restricted to using SSL. VPNs are just too slow. With native apps, you can also run VPNs and other encrypted solutions, without ruining performance.

– URL security vulnerabilities; these are unique to web applications and beloved by hackers. Native apps simply don’t have them, so hackers can’t get into native apps in the same way.

From my perspective, that last set of comparisons are the final nail in the HTML5 coffin. It’s clear that from a security perspective, native is the only way to go.

Overall, it’s a strong 5 to 3 win for native development, with one comparison a wash. The icing on the cake is the shear number of native apps now out there and the low current developer interest in building on HTML5.

Looked at objectively, then, the world has already spoken on native versus HTML5, and it’s bizarre that some people seem to be confused about this still.

At Appcelerator we continue to support developers however they want to build their apps and we believe that HTML will continue to have value in niche areas. But we also believe that success and innovation is built on a solid grasp of the facts; and here they indicate a strong advantage for native development, and have done for a while.

Given the evidence, it makes you wonder: why are we even debating this any more?

Jonathan Rende is the VP of Products at Appcelerator.

Who can unify my communications?

Who can unify my communications?

Posted by Perry Nalevka

As I start writing this blog post I find myself surrounded with devices – Smartphone, Tablet, laptop, TV and a desk phone.  This provides me with great flexibility in the way I can communicate and get my work done but I can’t help but notice that the user experience needs much improvement to allow a smoother transition between screens.

Vendors are doing a good job of making services available on multiple devices but need to spend more time and effort in the fine details. It’s great that when someone sends me a message I can receive it on all of my devices, but do I really have to see the notification in three different places AFTER I have read the message. Isn’t it a little strange when I’m chatting with someone on my iPad to receive the notifications about it on my laptop & smart phone? Shouldn’t it be easier to see all of your conversations with someone in one place.

The idea of unified communications has been around for a long time now, but it hasn’t kept up with the times. When all of the communications was clearly contained “inside the network” this was easier to control and manage but now that much of the communication is happening on top of the network and intelligence has moved into the client the problem got more complex.

It’s clearly time for some innovation here. In the short term vendors will need to respond by ensuring that their service is available in every device and through strategic partnerships and service integrations but ultimately there needs to be some true unification. The question is, will this come from one of the many software startups or will it be enabled in the network (and in which one). In short who will unify my communication?

Mobile Testing & QA Tools – Should I be using automation?

Mobile Testing & QA Tools

mobile-headerI am not going to answer the above question as there is not right answer but hope to have a conversation that will help answer for those asking. With the smartphone revolution upon us and the multitude of applications being released on a daily basis there is an increasing need for tools and automation to test all of these mobile applications. We are partnering and continuously vetting out tools for our customers.  One thing I can see now after 8 years in this space is that there is not one tool that is perfect or that can be called the best.  This is because it highly depends on the application.

Some questions are:

  • What parts of the app can be tested through automation?
  • Is location relevant?
  • 2G, 3G, Wifi, LTE or is connectivity available?
  • Does usability need to be tested?
  • Is this an enterprise or consumer app
  • How important is security
  • Does the backend need to be stress tested?

These are only some questions – please feel free to add more.

I have seen the tools fall into 3 categories with each one having a multitude of solutions:

  • Crowd Testing
  • Remote access to devices
  • Mobile QA / Test automation