How to test a wearable companion app

01Direct answer

02What counts as a wearable companion app

A wearable companion app here means the iOS or Android app paired with a wearable over Bluetooth that syncs, stores and shows its readings and alerts. It counts when the app stores health readings, shows alerts from the band or depends on a vendor cloud for sign-in or sync. Software cleared as a medical device that controls dosing is out of scope, and so is a phone-only app with no paired hardware.

Adjacent product types not covered here

• software as a medical device: Software as a medical device is regulated from the start and controls doses, while the companion app's regulatory risk is a new alert turning it into a device.
• mental health app: A mental health app collects mood and questionnaire answers without hardware, so pairing, Bluetooth range and band battery do not apply.
• telemedicine app: A telemedicine app connects patients to clinicians in scheduled visits, with load at appointment slots instead of overnight sync with a band.

03Risk map

04Mandatory tests (9)

1. 1

   Step 1: release smoke tests

   Why:store-rejection

   Done when: On the release build, the app opens to a demo mode without a band, pairs with a real band, and shows a reading synced in the last minute.

   Tool class: mobile automation. Who usually runs it: QA engineer.

2. 2

   Step 2: end-to-end functional tests

   Why:user-harm

   Done when: A threshold breach recorded on the band produces a phone notification, and a band disconnected for longer than the set interval shows a 'not connected' warning instead of the last value.

   Tool class: mobile automation. Who usually runs it: QA engineer.

3. 3

   Step 3: exploratory testing

   Why:user-harm

   Done when: A session log covers walking out of range, toggling Bluetooth, force-quitting the app, low band battery and a second phone sending repeated pairing requests within range, and states what the user saw in each case and whether band alerts kept working.

   Tool class: test management. Who usually runs it: QA engineer.

4. 4

   Step 4: compliance checks

   Why:regulatory-penalty

   Done when: A signed review lists every health alert and claim in the app and store listing, and states for each whether it makes the product a medical device and who approved it.

   Tool class: test management. Who usually runs it: product manager.

5. 5

   Step 5: security scanning

   Why:data-breach

   Done when: The scan of the app binary and its sync API shows no open high-severity finding and no health data stored unencrypted on the phone.

   Tool class: SAST scanner. Who usually runs it: security specialist.

6. 6

   Step 6: penetration testing

   Why:data-breach

   Done when: A tester with a second phone in range cannot pair with, read data from or send commands to a band already paired to another account.

   Tool class: proxy. Who usually runs it: security specialist.

7. 7

   Step 7: analytics and event tracking tests

   Why:data-breach

   Done when: A network capture during pairing, sync and browsing shows no heart rate, sleep or cycle data sent to an analytics or advertising endpoint the user did not authorise.

   Tool class: proxy. Who usually runs it: security specialist.

8. 8

   Step 8: resilience and failure testing

   Why:dependency-failure

   Done when: With the cloud API blocked, the app still shows readings stored on the band and phone, and queued data uploads once when the cloud returns.

   Tool class: chaos tool. Who usually runs it: developer.

9. 9

   Step 9: device and browser compatibility

   Why:store-rejection

   Done when: Pairing, background sync and alerts work on each phone model and OS version in the support list, with battery-saver mode both on and off.

   Tool class: device cloud. Who usually runs it: QA engineer.

05Recommended and optional tests

• regression suiterecommended

  Becomes mandatory when firmware and app release on separate schedules.

• offline and poor-network testingrecommended

  Becomes mandatory when the band can store more than a day of readings.

• integration testsrecommended

  Becomes mandatory when other apps read the band's data through the phone's health store.

• accessibility testingrecommended

  Becomes mandatory when the product is sold to public bodies or marketed for users with disabilities.

• data integrity and migration testingrecommended

  Becomes mandatory when readings are shared with a clinician or insurer.

• unit testsoptional

  May help: checks on unit conversion and threshold logic before device testing.

• usability testingoptional

  May help: first pairing is the first step a new user completes without help.

06Not needed and why

• performance and load testing

  Not needed: sync traffic is spread across users' days with no launch-day peak evidenced. Becomes recommended when a new band launch is expected to bring a pairing spike.

• localization testing

  Not needed: one language and one unit system. Becomes recommended when imperial and metric units or a second language ship.

07Order of work

08Tools

Listed alphabetically inside each test type, filtered to the tests above and to the platforms of wearable companion app (ios, android). Not recommendations.

09What to send to the person who will test

Send the checklist and the brief below. The printable checklist for wearable companion app has the same 9 items with checkboxes.

Download the checklistMarkdownCSVBrief (Markdown)

Acceptance criteria wording

A release of the wearable companion app is accepted when a threshold breach on the band produces a phone notification and a band disconnected past the set interval shows 'not connected' instead of the last value, on each phone model and OS version in the support list. A second phone in range cannot pair with a band paired to another account, and with the cloud API blocked the app still shows readings stored on the band and phone.

Brief

# Test brief: wearable companion app

Product type: wearable companion app. The phone app paired with a wearable device over Bluetooth.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/wearable-companion-app/
Printable checklist: https://howtotestaproduct.com/checklists/wearable-companion-app/

Run these 9 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: store-rejection). Tool class: mobile automation. Usually run by: QA engineer.
   Done when: On the release build, the app opens to a demo mode without a band, pairs with a real band, and shows a reading synced in the last minute.
2. end-to-end functional tests (risks: user-harm). Tool class: mobile automation. Usually run by: QA engineer.
   Done when: A threshold breach recorded on the band produces a phone notification, and a band disconnected for longer than the set interval shows a 'not connected' warning instead of the last value.
3. exploratory testing (risks: user-harm). Tool class: test management. Usually run by: QA engineer.
   Done when: A session log covers walking out of range, toggling Bluetooth, force-quitting the app, low band battery and a second phone sending repeated pairing requests within range, and states what the user saw in each case and whether band alerts kept working.
4. compliance checks (risks: regulatory-penalty). Tool class: test management. Usually run by: product manager.
   Done when: A signed review lists every health alert and claim in the app and store listing, and states for each whether it makes the product a medical device and who approved it.
5. security scanning (risks: data-breach). Tool class: SAST scanner. Usually run by: security specialist.
   Done when: The scan of the app binary and its sync API shows no open high-severity finding and no health data stored unencrypted on the phone.
6. penetration testing (risks: data-breach). Tool class: proxy. Usually run by: security specialist.
   Done when: A tester with a second phone in range cannot pair with, read data from or send commands to a band already paired to another account.
7. analytics and event tracking tests (risks: data-breach). Tool class: proxy. Usually run by: security specialist.
   Done when: A network capture during pairing, sync and browsing shows no heart rate, sleep or cycle data sent to an analytics or advertising endpoint the user did not authorise.
8. resilience and failure testing (risks: dependency-failure). Tool class: chaos tool. Usually run by: developer.
   Done when: With the cloud API blocked, the app still shows readings stored on the band and phone, and queued data uploads once when the cloud returns.
9. device and browser compatibility (risks: store-rejection). Tool class: device cloud. Usually run by: QA engineer.
   Done when: Pairing, background sync and alerts work on each phone model and OS version in the support list, with battery-saver mode both on and off.

Acceptance criteria wording:
A release of the wearable companion app is accepted when a threshold breach on the band produces a phone notification and a band disconnected past the set interval shows 'not connected' instead of the last value, on each phone model and OS version in the support list. A second phone in range cannot pair with a band paired to another account, and with the cloud API blocked the app still shows readings stored on the band and phone.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.

For founders: what to forward and what to ask back. For product managers: turning this page into tickets.

10Questions about testing a wearable companion app

11Evidence

1. ev-0189regulatorprimary

   FDA Informs Patients, Providers and Manufacturers About Potential Cybersecurity Vulnerabilities in Certain Medical Devices with Bluetooth Low Energy, U.S. Food and Drug Administration

   These cybersecurity vulnerabilities may allow an unauthorized user to wirelessly crash the device, stop it from working, or access device functions normally only available to the authorized user.

   FDA states the Bluetooth Low Energy flaws also reach consumer wearables, the radio link every companion app pairs over, so unauthorised pairing and device crashes are risks of this product type.

   published 2020-03-03 · verified 2026-10-07

2. ev-0188regulatorprimary

   Warning Letter: Owlet Baby Care, Inc. (MARCS-CMS 616354), U.S. Food and Drug Administration

   FDA treated a wearable sock and its oxygen and heart-rate notifications to parents as an uncleared medical device, so the alerts a companion app shows can turn a consumer wearable into a regulated product.

   published 2021-10-05 · verified 2026-10-07

3. ev-0013standardprimary

   OWASP Mobile Application Security Verification Standard (MASVS), OWASP Foundation

   MASVS defines security requirements for mobile apps, including secure storage, network communication and authentication.

   published undated · verified 2026-10-07

4. ev-0111regulatorprimary

   FTC Finalizes Changes to the Health Breach Notification Rule, Federal Trade Commission

   FTC rule update stating that health apps outside HIPAA are covered and that an unauthorized disclosure of identifiable health information counts as a breach that must be notified. Supports regulatory-penalty and data-breach for mental health apps and fitness apps that sell direct to consumers, and wearable companion apps, since the FTC ties the update to health apps and connected devices.

   published 2024-04-26 · verified 2026-10-07

5. ev-0190post-mortemprimary

   Garmin issues statement on recent outage, Garmin

   many of our online services were interrupted including website functions, customer support, customer facing applications, and company communications.

   A wearable maker's own statement on a cyber attack that took its cloud and companion services offline while watches kept working, which is the device-works-but-app-cannot-sync failure this product type must handle.

   published 2020-07-27 · verified 2026-10-07

6. ev-0001store-guidelineprimary

   App Review Guidelines, Apple

   Apple reviews every iOS, iPadOS and macOS App Store submission against these guidelines, including crashes and bugs at review, privacy disclosures, in-app purchase rules and extra rules for medical, financial and kids apps, and apps with user-generated content must let users report offensive content and block abusive users (guideline 1.2), and apps offering loot boxes or similar mechanisms must disclose the odds of each item type before purchase (guideline 3.1.1).

   published undated · verified 2026-10-07

12Disclaimer

This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.