Quality Assurance for Smartwatches and Wearables

As smartwatches and other wearables are more embraced by consumers, compelling software applications remain the key to increased adoption of this new technology. With developers working on the cutting edge of a new software platform, QA engineers are also faced with learning how to properly vet applications for wearables. Do some of the same issues found when testing smartphones also apply on this new mobile device type?

This article offers an overview of the QA process for smartwatches and other similar devices, with a focus on app testing for Apple’s watchOS and Google’s Android Wear platforms.

Is Smartwatch Testing just an Extension of Mobile QA?

Some software development firms see wearable platforms as suitable for modified versions of their existing mobile app library. While this works for many simpler apps, the extremely limited screen real estate on a smartwatch somewhat tempers this enthusiasm. Wearables typically leverage a different set of gestures, which needs to be taken into account during development and testing.

Additionally, some smartwatch apps work in tandem with an app on a smartphone; for example, receiving a notification about an event on a wearable that gets handled on a paired smartphone app. In this case, a QA team is responsible for testing apps on two different devices simultaneously. Despite some similarities with mobile, software quality assurance on the wearable platform really needs to be treated as a different entity.

Software QA on watchOS

App development for the Apple Watch targets watchOS, Apple’s wearable operating system. Developers are able to use either Objective-C or Swift as a programming language, in a similar manner as iOS apps. Also like iOS, UX and design guidelines with watchOS are very strict, and Apple enforces them as part of their submission process, so your QA team needs to include vetting these guidelines as part of their testing regimen.

The Apple Watch user interface includes a digital crown and a variety of unique sensors, as well as the touchscreen, buttons, and microphone typical of a mobile device. Any watchOS test plans need to consider all possible inputs to the smartwatch. An Apple Watch connects to an iPhone using WiFi, Bluetooth, or NFC (near-field communications), so keep this in mind when testing watchOS apps that work with an iOS app.

Include a few Apple Watches as part of your mobile test farm if your development team plans on building apps for watchOS.

Android Wear and Quality Assurance

Google’s smartwatch operating system, Android Wear, is closely based on the regular Android platform. One advantage compared to the smartphone OS is Google made the UI interface standard among device manufacturers, which makes development and QA easier with little smartwatch model fragmentation. While not as strict as Apple, Google also provides a host of design guidelines and principles your developers and QA team need to be aware of.

While the Android SDK provides a Wear emulator, leveraging actual devices as part of your QA process is a must, as with the Apple Watch. With 10 different manufacturers offering Android Wear devices, acquiring models of the different smartwatches makes sense, but Google’s standardization of the interface lessens fragmentation problems compared to Android smartphones.

The inputs of an Android Wear smartwatch are similar to the Apple Watch, with the exception of no digital crown. In addition pairing with Android smartphones, Wear smartwatches can also be connected to iOS devices. Keep both of these points in mind when creating your test plans.

If you want more detailed information on software testing for wearables, check out this eBook by QA engineer, Daniel Knott. In addition to watchOS and Android Wear, he also covers QA on the TizenOS and PebbleOS wearable device platforms.

Keep checking back at the Betica Blog for further insights on software quality assurance – no matter the platform!

Monitor API Usage with Runscope

Any company involved in the development of APIs, or even those simply building web or mobile applications dependent on them, benefits from being able to analyze API performance before deployment to production. A tool combining this performance testing functionality with testing and monitoring capabilities offers a full range of features wanted by most software teams. Runscope is just this kind of application.

What follows is an overview of Runscope to help you determine whether it makes sense to add it to your organization’s API testing toolbox. It may just ensure your applications and APIs perform as expected in production.

A Closer Look at Runscope

Runscope is a relatively new product and company. Formed by two software engineers, John Sheehan and Frank Stratton, the initial version of the application became available in the first half of 2013. The primary goal of their API analysis tool involves trusting an API running on a remote server just like it was running on a developer’s local machine.

Runscope Monitoring Features and Functionality

Uptime monitoring of an API – in real-time – is a major selling-point for Runscope. The product promises the engineers responsible for tracking an application in a production environment will know if an API breaks before the client or customer. It integrates with a wide variety of popular notification and messaging apps, including Slack, PagerDuty, email, as well as offering support for webhooks.

An on-premises agent (supporting Linux, OS X, and Windows) allows for the seamless monitoring of private APIs. This is in addition to Runscope’s standard Cloud-based SaaS (located in 12 global data centers) used for public API analysis. The tool includes threshold-based notifications to lower the instance of false positives. 

Real-time performance data helps analyze an API’s response times as well as the ratio of successful calls to failures. Engineers are able to quickly detect any issues requiring closer analysis and debugging. Runscope’s data can be imported into third-party analytical tools, like Keen IO, Datadog, and New Relic Insights.

Additional API Testing Capabilities

Runscope sports other functionality aimed at the testing of APIs. You are able to verify data in the JSON and XML formats, as well as validate HTTP headers and response status codes. Advanced validations are also possible in code using JavaScript and the Chai Assertion Library.

Users are able to create dynamic test scripts for vetting API workflows, without any coding effort. Test plan creation in the Swagger format, among others, offers a more structured level of API QA. Runscope also integrates with Jenkins and other similar tools for organizations leveraging a Continuous Integration release cycle.

Interested customers can test drive Runscope on a free trial basis. Their premium service is structured across three tiers based on the number of API requests and users, with monthly prices ranging from $79 to $599; the higher two levels also include priority support and live chat. There is also a Premier level with additional custom features and extra traffic handling.

In short, Runscope’s full range of API monitoring and testing features, along with its compatibility with industry standard messaging and analytical tools, makes the tool worth checking out at any shop specializing in API development.

Stay tuned to the Betica Blog for additional dispatches and analysis from the software development and QA world. Thanks for reading, as always.

StopLight makes API Development an Easier Process

Modeling applications have assisted programmers in architecting software for years. So it stands to reason the process of API design and development would also benefit from the use of models during the SDLC. StopLight is one such application, offering shops a full visual API modeling suite, including documentation and other useful features.

The best applications used for software development stay out of the way, while making the entire architecting, coding, and testing processes easier. With that said, let’s take a closer look at StopLight to see if it needs to be part of your team’s API tool arsenal

The Need for a Better API Design Tool

Like many other innovative technology products – Ruby on Rails comes to mind – StopLight was developed by software engineers wanting a better tool to make their work easier. Company founder Marc MacLeod commented on how the need for a better API tool led to StopLight’s genesis. “I’m an engineer, and StopLight is the solution to problems I faced repeatedly. Before StopLight, best practices were very manual — with no easy way to document and test APIs in an accessible, collaborative setting. StopLight changes this paradigm,” said MacLeod.

StopLight first became available in February of 2016. The designer tool is free to use for singular developers, while team subscriptions are also available – starting at a monthly rate of $8 per person. At those prices, downloading the application to test drive its features and functionality is a smart call for any API shop. The app is available on the Mac, Windows, and Linux platforms.

StopLight – Features and Functionality

The StopLight application suite includes three main modules. The API Designer is the heart of the tool, providing a way for developers to collaborate on model design leveraging open standards. A documentation module automatically generates API documentation every time the model changes – a boon for public API shops.

Prism Proxy gives developers a way to validate and mock API requests. Users can either install the proxy on a local server, or use StopLight’s Cloud-hosted version for up to 20,000 requests per month. One useful feature provided by Prism Proxy is the ability to reverse engineer an API – simply run traffic through the proxy and StopLight automatically generates end point and model definitions.

An Easy to Use API Design Tool

StopLight’s easy to use API Designer module lets everyone work together on API designs, no matter their level of technical expertise. Even business stakeholders with little to no programming experience are able to use the tool. This is one feature attractive to DevOps and Agile development teams where collaboration and interaction are vital to the success of a project.

Version 2 of StopLight entered a public beta phase in July, with a new module used for testing APIs, including the debugging of HTTP requests. Better collaboration features are also part of the new release. A new pricing model adds flexibility to shops of all sizes.

StopLight is worthy of further exploration for any API development shop. This product continues to garner a lot of buzz in the industry.

Keep coming back to the Betica Blog for additional insights into the world of QA and software development.