# 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.