The earliest vastly-adopted wearable was a calculator-watch presented back in the 1980s. Next incorporated idea of a wearable was implemented in 2008 when a hidden Bluetooth mic was hidden into earrings. The Spy Tie was realized approximately at the same time – a necktie with a concealed color cam. Today it’s the whole new level.
When creating wearables apps, the following 10 points should be kept in mind:
App and device dependency
All today’s wearables are based on sensors and fully depend on smartphones, permanently synchronizing to provide required data to end users. And because wearables usually possess very limited computing functionality, much smaller screens and different engagement approaches to end users, it’s vital to seriously consider such distinctions from the initial stage of design all through testing and up to deployment.
With constant growth of the wearables market developers have no other choice except creating a device lab and coverage of total testing with the new emerging devices and unique device platforms such as Android, Apple or Samsung.
Original use cases
New wearable app use cases must be reviewed, adapted and included in test plans, test environment and support tools by application development and Q/A teams. It’s now required to test notifications not only on smartphones but on wearables as well in order to guarantee a stable experience for end users and run app adoption on both sides.
Specific architecture for wearables
Pairing technology becomes indispensable when it comes to wearable application development. It provides users with instant access to a lot of apps running on a smartphone, allows focusing on wearable interface and the ability to deploy app updates which can only be done on smartphones. As a result, such a workflow changes classic SDLC and causes many dependencies. It’s no longer an option to build apps without considering wearable UI because now most of apps should automatically synchronize to the wearable. Thus tests for both devices are inevitable.
Build a container app regardless of your wearable project goal
If you're only intending to create a game to be played on wearables, you still have to build a container app for the purpose of carrying, setting up and installing the game application and connecting your game to the real world.
It makes sense not to rush with any release schedules and start small, while gradually stabilizing internal processes and increasing coverage of the new device by adding more complicated scenarios. It may be a good idea to follow the next guideline:
- Existing Q/A plan (select known market leaders and target them, get feedback);
- Involvement (choose the leading platform and ensure all cases on both devices);
- Test plan prep automation and CI (expand for automation);
- Adaptation (adjust the strategy at all times, test on all devices).
Relevant device selection
Leading vendors should not be overlooked in case of developing and testing your first device. Expand device coverage matrix, cover new test cycles and releases, always keep them up-to-date, collect market feedback and specific customer requirements, make sure your device works on multiple platforms.
Q/A Plan for a wearable app dev project
Automation is essential; as such, more testing is required. There’s a higher demand for a top quality lab which can investigate ever-growing mobile requirements and new complex wearables needs.
Solid test plan
Make sure to cover the following items in your test plan:
- Performance testing
- Installation testing
- Memory Leak
- Security testing
- Usability testing
Mobile environment significantly affects wearable apps and devices, therefore it’s important to consider performance testing and different networks as an essential part of a mobile app release cycle for the sake of bug-free end-user experience.