How to test a smart home or IoT app
Direct answer
Shipped untested, a smart home or IoT app lets passwords leaked from other sites log attackers into camera accounts with no second factor, and a stranger who took over the account talks to a child through the camera's two-way audio from the app. 8 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with penetration testing: a leaked password list, a second account and access to the same Wi-Fi are how an outsider reaches a camera feed, its audio or a lock.
8 mandatory testsfirst: penetration testing
What counts as a smart home or IoT app
A smart home or IoT app here is the iOS or Android app that pairs with and controls connected devices such as cameras, locks, lights, plugs and thermostats over the local network or the vendor cloud. It counts when devices stream video or audio, control locks, are sold in markets with connected-product security rules, or can be controlled locally when the internet is down. A wearable's companion app that only reads health data from a band is out of scope, and so is the device firmware itself.
Adjacent product types not covered here
- wearable companion app: A wearable companion app reads health data from one band over Bluetooth, so uncleared health alerts lead instead of camera account takeover and lock commands.
- fleet and logistics tracking: A fleet tracking product sends commands to trackers in vehicles on the road for a business, while a smart home app controls cameras and locks inside a household.
- desktop application: A desktop application installs helpers and folders on one machine, with no paired hardware, home network or vendor cloud between the user and the device.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Physical or psychological harm to a user user-harm | harm | primary | A stranger who took over the account talks to a child through the camera's two-way audio from the app. | |
| Fraud or abuse by users fraud-abuse | money | primary | Passwords leaked from other sites log attackers into camera accounts, with no second factor. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | A hub ships to UK buyers with a shared default password and no published security update period, so it cannot legally be sold there. | |
| Personal or sensitive data exposed data-breach | data | primary | The phone app keeps the camera account password in clear text on the handset, or the account accepts passwords leaked from other sites, and an outsider watches the live feed of the home. | |
| Third-party dependency fails dependency-failure | outage | primary | The vendor cloud goes down and every bulb, plug and thermostat stops answering the app, because commands only route through the cloud. | |
| App rejected or removed by a store store-rejection | distribution | secondary by design analysis | App review cannot get past device onboarding without a physical hub, so the build needs a demo home with simulated lights and locks. | |
| User actions lost on bad networks or devices lost-actions | trust | primary | With the home internet down, tapping "unlock" in the app does nothing and shows no message, although the phone and the lock share the same Wi-Fi. |
Mandatory tests (8)
Step 1: release smoke tests
Why:store-rejection
Done when: On the release build, the app opens a demo home without hardware, adds a real device and switches it on and off from the phone.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 2: penetration testing
Why:data-breachfraud-abuseuser-harm
Done when: A tester with a leaked password list, a second account and access to the same Wi-Fi cannot view a camera feed, speak through it or change settings on a device they do not own.
Tool class: proxy. Who usually runs it: external lab.
Step 3: end-to-end functional tests
Done when: A sign-in from an unknown phone sends an alert to the owner, and with two-factor sign-in on, the same login fails without the second factor.
Tool class: mobile automation. Who usually runs it: QA engineer.
Step 4: compliance checks
Done when: A signed record per device model shows a unique or user-set password, the published security update period and a vulnerability report contact before the model ships to a new country.
Tool class: test management. Who usually runs it: product manager.
Step 5: security scanning
Why:data-breach
Done when: The scan of the app binary and device API shows no open high-severity finding and no account password or device key stored unencrypted on the phone.
Tool class: SAST scanner. Who usually runs it: security specialist.
Step 6: resilience and failure testing
Done when: With the vendor cloud blocked, the app marks each device's last known state as stale, and queued schedules run once when the cloud returns.
Tool class: chaos tool. Who usually runs it: developer.
Step 7: device and browser compatibility
Why:lost-actionsstore-rejection
Done when: Device setup, local control and push alerts work on each phone model and OS version in the support list, including with the phone on a different Wi-Fi band from the device, and the demo home opens without hardware on each.
Tool class: device cloud. Who usually runs it: QA engineer.
Step 8: offline and poor-network testing
Why:lost-actions
Done when: With the internet link cut but home Wi-Fi up, lock, light and thermostat commands from the app still work and the app says it is in local mode.
Tool class: proxy. Who usually runs it: QA engineer.
Recommended and optional tests
integration testsrecommended
Becomes mandatory when devices are sold as working with a voice assistant or another home platform.
regression suiterecommended
Becomes mandatory when firmware and app release on separate schedules.
accessibility testingrecommended
Becomes mandatory when the product is marketed to older or disabled users or sold to public housing bodies.
unit testsoptional
May help: schedule logic breaks quietly across daylight saving changes.
exploratory testingoptional
May help: home networks vary more than any lab setup.
usability testingoptional
May help: onboarding is where new devices get returned.
Not needed and why
Not needed: no demand-peak outage is evidenced for this product type. Becomes recommended when a holiday sale is expected to bring a setup spike.
Not needed: one language ships. Becomes recommended when the app or device setup ships in a second language.
Order of work
First release
- release smoke tests: On the release build, open the demo home without hardware, then add a real device and switch it on and off from the phone.
- penetration testing: Have an external lab use a leaked password list, a second account and access to the same Wi-Fi to try to view a camera feed, speak through it or change a device they do not own.
- end-to-end functional tests: Sign in from an unknown phone and confirm the owner gets an alert, then turn on two-factor sign-in and confirm the same login fails without the second factor.
- compliance checks: Record per device model a unique or user-set password, the published security update period and a vulnerability report contact, signed before the model ships to a new country.
- security scanning: Scan the app binary and device API and confirm no account password or device key is stored unencrypted on the phone.
- resilience and failure testing: Block the vendor cloud and confirm the app marks each device's last known state as stale, then restore it and confirm queued schedules run once.
- device and browser compatibility: Run device setup, local control and push alerts on each phone model and OS version in the support list, including with the phone on a different Wi-Fi band from the device, and open the demo home without hardware on each.
- offline and poor-network testing: Cut the internet link with home Wi-Fi up and send lock, light and thermostat commands, confirming each works and the app says it is in local mode.
Ongoing cadence
- release smoke tests: On every release build, before each store submission.
- compliance checks: Before a device model ships to a new country.
- device and browser compatibility: When a new phone OS version is published or a phone model is added to the support list.
- offline and poor-network testing: After each change to local control or device firmware.
- resilience and failure testing: After each change to how commands route through the vendor cloud.
- penetration testing: When a new device type with video, audio or lock control is added.
- regression suite: When firmware and app start releasing on separate schedules.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of smart home or IoT app (ios, android, embedded). Not recommendations.
release smoke tests
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
end-to-end functional tests
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- DetoxGray-box end-to-end testing for React Native apps. iosandroidopen-source
- EspressoAndroid UI testing framework from Google. androidopen-source
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- MaestroMobile UI flows written in YAML. iosandroidfreemium
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- XCTestApple's framework for unit and UI tests. iosopen-source
security scanning
device and browser compatibility
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
offline and poor-network testing
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- Network Link ConditionerApple tool for simulating poor network conditions. iosopen-source
integration tests
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- JUnitTest framework for the JVM. apiandroidopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
regression suite
accessibility testing
- Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for smart home or IoT app has the same 8 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the smart home or IoT app is accepted when the store build opens a demo home without hardware and switches a real device on and off, and a sign-in from an unknown phone alerts the owner and fails without the second factor when two-factor sign-in is on. With the internet link cut and home Wi-Fi up, lock, light and thermostat commands still work and the app shows local mode, and no account password or device key is stored unencrypted on the phone.
Brief
# Test brief: smart home or IoT app Product type: smart home or IoT app. A phone app controlling connected devices over local or cloud links. Risk map and evidence: https://howtotestaproduct.com/how-to-test/iot-app/ Printable checklist: https://howtotestaproduct.com/checklists/iot-app/ Run these 8 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 a demo home without hardware, adds a real device and switches it on and off from the phone. 2. penetration testing (risks: data-breach, fraud-abuse, user-harm). Tool class: proxy. Usually run by: external lab. Done when: A tester with a leaked password list, a second account and access to the same Wi-Fi cannot view a camera feed, speak through it or change settings on a device they do not own. 3. end-to-end functional tests (risks: fraud-abuse, user-harm). Tool class: mobile automation. Usually run by: QA engineer. Done when: A sign-in from an unknown phone sends an alert to the owner, and with two-factor sign-in on, the same login fails without the second factor. 4. compliance checks (risks: regulatory-penalty). Tool class: test management. Usually run by: product manager. Done when: A signed record per device model shows a unique or user-set password, the published security update period and a vulnerability report contact before the model ships to a new country. 5. security scanning (risks: data-breach). Tool class: SAST scanner. Usually run by: security specialist. Done when: The scan of the app binary and device API shows no open high-severity finding and no account password or device key stored unencrypted on the phone. 6. resilience and failure testing (risks: dependency-failure). Tool class: chaos tool. Usually run by: developer. Done when: With the vendor cloud blocked, the app marks each device's last known state as stale, and queued schedules run once when the cloud returns. 7. device and browser compatibility (risks: lost-actions, store-rejection). Tool class: device cloud. Usually run by: QA engineer. Done when: Device setup, local control and push alerts work on each phone model and OS version in the support list, including with the phone on a different Wi-Fi band from the device, and the demo home opens without hardware on each. 8. offline and poor-network testing (risks: lost-actions). Tool class: proxy. Usually run by: QA engineer. Done when: With the internet link cut but home Wi-Fi up, lock, light and thermostat commands from the app still work and the app says it is in local mode. Acceptance criteria wording: A release of the smart home or IoT app is accepted when the store build opens a demo home without hardware and switches a real device on and off, and a sign-in from an unknown phone alerts the owner and fails without the second factor when two-factor sign-in is on. With the internet link cut and home Wi-Fi up, lock, light and thermostat commands still work and the app shows local mode, and no account password or device key is stored unencrypted on the 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.
Questions about testing a smart home or IoT app
What testing does a smart home or IoT app need?
8 tests are mandatory, starting with a demo home and real device smoke run on every release build and penetration testing by an external lab. Each is tied to one of the 7 risks in the map, from camera account takeover and strangers speaking through two-way audio to locks that ignore taps when the internet is down. Integration, regression and accessibility tests are recommended, each with the event that makes it mandatory.
What gets a smart home or IoT app rejected by an app store?
The map marks store rejection as a by design analysis risk: app review cannot get past device onboarding without a physical hub. The release smoke run opens a demo home with simulated devices before a real device is added, and compatibility opens the demo home without hardware on each phone model and OS version in the support list.
What is the minimum testing for a smart home or IoT app at MVP stage?
The minimum is the 8 mandatory tests once devices stream video or audio or control locks, the app ships through the stores and any command routes through the vendor cloud. Unit, exploratory and usability testing are optional, and performance and localization tests that vendors often add are not needed until the conditions on the page change.
Which tests in a vendor test plan for a smart home or IoT app are not needed?
Performance testing is not needed while no demand-peak outage is evidenced, until a holiday sale is expected to bring a setup spike. Localization testing is not needed while one language ships, until the app or device setup ships in a second language.
What should I send to the person who will test a smart home or IoT app?
Send the release build with its demo home, one real device of each type with video, audio or lock control, and test accounts for an owner and a non-owner. Add the phone models and OS versions in the support list, a way to cut the internet link while home Wi-Fi stays up, and a way to block the vendor cloud.
Evidence
ev-0253regulatorprimary
FTC Says Ring Employees Illegally Surveilled Customers, Failed to Stop Hackers from Taking Control of Users' Cameras, U.S. Federal Trade Commission
Credential stuffing involves the use of credentials, such as usernames and passwords, obtained from a consumer’s breached account to gain access to a consumer’s other accounts.
The FTC charged a home camera company whose accounts were taken over by credential stuffing and brute force, after which attackers watched video and used two-way audio to harass people, including children, in their homes.
published 2023-05-31 · verified 2026-10-07
ev-0037standardprimary
NIST SP 800-63B: Digital Identity Guidelines, Authentication and Authenticator Management, National Institute of Standards and Technology
SP 800-63B sets requirements for authenticators, multi-factor authentication, session management and throttling of guessing attempts.
published undated · verified 2026-10-07
ev-0255regulatorprimary
D-Link Agrees to Make Security Enhancements to Settle FTC Litigation, U.S. Federal Trade Commission
The FTC settlement with a router and camera maker cites hard-coded device credentials and mobile app login data stored in clear text, and requires testing for vulnerabilities before release and automatic firmware updates.
published 2019-07-02 · verified 2026-10-07
ev-0256regulatorprimary
The UK Product Security and Telecommunications Infrastructure (Product Security) regime, UK Government (GOV.UK)
The UK regime sets minimum security requirements that connectable consumer products must meet before they are made available in the UK, with duties on manufacturers, importers and distributors, including that passwords are unique per product or set by the user and that the minimum security update period is published.
published undated · verified 2026-10-07
ev-0254regulatorprimary
Marketer of Internet-Connected Home Security Video Cameras Settles FTC Charges It Failed to Protect Consumers' Privacy, U.S. Federal Trade Commission
In addition, the FTC alleged that TRENDnet’s mobile applications for the cameras stored consumers’ login information in clear, readable text on their mobile devices.
An FTC order against a home camera maker cites the companion phone app storing login data in clear text, which is the app side of a connected-device product.
published 2013-09-04 · verified 2026-10-07
ev-0257standardprimary
ETSI EN 303 645 V3.1.3: Cyber Security for Consumer Internet of Things: Baseline Requirements, ETSI
Consumer IoT devices should remain operating and locally functional in the case of a loss of network access and should recover cleanly in the case of restoration of a loss of power.
The consumer IoT baseline standard asks for resilience to network and power outages, unique per-device passwords and a secure update mechanism, which the phone app controlling the device has to respect.
published undated · verified 2026-10-07
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
ev-0002store-guidelineprimary
Developer Program Policy, Google Play
Google Play applies these policies to every Android app it distributes and can reject, suspend or remove apps that violate them.
published undated · verified 2026-10-07
Disclaimer
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.