For a time, desktop applications were declared dead. They became too costly to develop and deploy compared to web apps, which allowed businesses to easily onboard new users, release updates instantly and introduce recurring pricing models rather than one-off purchases.

But then ironically, the web actually saved desktop apps. With advances to JavaScript and HTML5, developers can create desktop apps with the same languages used to develop on the web and then adapt it for desktop or devices with a tool like MacGap, Electron, or Cordova.

Businesses can offer their customers the best of both worlds (online and offline access) without taking on massive development projects.

Now hybrid apps are increasingly used by all ages in all industries. Spotify, Slack, Skype…all of these are hybrids.

Hybrids pose some unique challenges when it comes to QA, though. Here, I’m giving more insight into how the nature of hybrid apps requires an additional consideration during testing strategy.

What are hybrid apps, exactly?

A hybrid app could refer to just about anything.

  • It could refer to an app that works in a web browser and as a desktop application
  • An app that works in a web browser and as a mobile application
  • An app that works in web, mobile, and desktop
  • OR…mobile applications that don’t have a web access component but use web coding languages to create a unified code base across iOS, Android, and/or Windows Phone

For the most part, I’ll be discussing web-desktop hybrids, but there are certainly hybrid mobile testing challenges worth considering too.

Ideally, hybrid mobile apps don’t actually require separate versions for different operating systems, since they run on CSS, JavaScript and HTML5. But in practice, some native coding is often required for various platforms.

As you can see from the bulleted list above, hybrid really just means “combo.” Some take a broader view of the term “hybrid.” It’s not about how the app was built, but the fact that it’s integrated into local files and accessible via web, and that it gives users more options for access, like certain features or files being available offline.

But because HTML is the easiest, fastest language for developing hybrids, the fact is that these types of apps are increasingly built this way.

Why hybrid apps keep growing in popularity

We talk a lot about how picky customers are these days (and how testing can help). The only real reason for developing a hybrid app is because it’s what your customers demand.

On mobile, allowing a user to check out your app and use certain features without downloading anything can be a major advantage. As for desktop, having a docking icon and a separate window whose automatic size fits the app features can increase user adoption of an originally web-based app.

So the number one reason a business will decide to go hybrid should be because of the features and type of access their customers demand.

However, there are certainly some plusses for developers that have made this an increasingly popular choice. As mentioned, matured web coding languages have allowed developers to cut costs of native app development by allowing more unification of the underlying code.

The ease with which hybrid apps can be now developed make it less of a “why?” question and more of a “why not?.” It’s not that native apps are dying, but rather that capabilities for seamless coding are growing, and along with them hybrid apps.

Testing challenges with hybrid apps and how to overcome them

Because hybrid apps can be accessed in different devices and environments, they’re naturally a little trickier to test. Unless built with completely unified code, they require unique test cases for automation, and of course require unique sessions of manual testing in each platform regardless of the development process.

  • Seamless notifications: The notification process for all major functions will need to be tested. If a user is logged into a messaging app on their desktop and chatting in real time, they’ll likely not want to receive pings on their phone for responses they’re currently reading. If the user is logged out on all platforms and views a notification on their mobile app, will it show on the desktop app later as well, or will that notification be cleared? Testers will need to understand the various requirements for notifications, how they work within one user account and across user accounts.
  • Intuitive navigation: There may be shifts in the UX of different platforms. The desktop app may pull a small chunk of functionality from the web app and have a very different appearance. Testers will need to explore each platform within its own context to validate the intuitiveness of the navigation, as well as examine how differing designs compare. Does it all add up to a seamless user experience, or are some design differences simply confusing?
  • Data syncing: With some data hosted on local files and some data on servers, accurate syncing can be a major concern with hybrid apps. Testers must check that for each function, the app is pulling in the right information.
  • Integration with outside apps: Particularly for B2B products, integrations can be a major draw for customers. But even for B2C apps, integrations can be important, like with popular email providers or social media networks for example. First off, desktop apps have to integrate with their own web app counterparts’ APIs and then with the APIs of external apps as well. Testers can execute tasks that result in an action in an external app in each supported platform to verify integrations across user behavior.

  • Offline storage: A music streaming app might allow a user to download certain playlists for offline listening. An audiobook app might allow downloads of certain chapters. A word processing app might allow offline edits that are supposed to sync up later. Whatever the feature, and whatever the environment, hybrid apps are likely to have some features affected by a mix of offline and online storage. Any such feature is a great candidate for exploratory testing.
  • Connectivity: The issue of connectivity can play a part with notifications, data syncing, and offline storage, but it warrants its own mention because connectivity is often why hybrid apps are developed in the first place. What needs for offline functionality do users have, how is this being supported, and is the application delivering on those needs? Dependant on whether the components of the hybrid app are desktop or mobile, testers will need to test in 4G, 3G, WiFi and offline environments.
  • Automation and test case writing: Hybrid apps either make automation really easy or really hard. If built only on web based languages and adapted with as little native coding as possible, it’s very easy for QA engineers to write automated scripts that function across various OSes, which is truly a novelty. But if the app is created with completely different languages and/or has very different navigation features, then writing automated scripts will need to be accomplished in each support platform.
  • Device and desktop security: One reason that enterprises will choose to develop desktop apps over web apps is because the internet is notoriously unsecure. When native desktop or mobile apps pull data from the internet, the access can conceivably go the other direction. Apps can be used to access or take over computers and phones. Dependent on the product, risk analysis might not be enough. Actually attempting attacks might be required.

The good news is that all excellent testers love a challenge, and hybrid apps are certainly challenging. They provide a fun puzzle for QA managers when it comes to test design and strategy and create lots of opportunities for testers to come up with creative cases.

For strategic testing of hybrid applications, get in touch with us!

Dayana is a QA engineer turned technology writer living in Milan, Italy. She's always down for a smoothie.