# Test brief: desktop application

Product type: desktop application. A native or Electron app installed on macOS, Windows or Linux.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/desktop-app/
Printable checklist: https://howtotestaproduct.com/checklists/desktop-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, data-breach). Tool class: device cloud. Usually run by: QA engineer.
   Done when: The signed installer opens on clean macOS and Windows machines with no Gatekeeper or SmartScreen warning, and lists the same files and services as the previous release plus documented changes.
2. penetration testing (risks: data-breach, regulatory-penalty). Tool class: proxy. Usually run by: security specialist.
   Done when: A hostile web page opened in each supported browser cannot launch the app, join a session or read app data through a local port or URL handler.
3. compliance checks (risks: store-rejection, regulatory-penalty). Tool class: test management. Usually run by: product manager.
   Done when: Each build passes notarization and Microsoft Store certification, and release notes name every helper, service or login item the update installs.
4. end-to-end functional tests (risks: data-corruption, data-breach). Tool class: device cloud. Usually run by: QA engineer.
   Done when: After install, update and uninstall on a test machine with redirected Documents and a moved data folder, every user file is still present and no helper remains.
5. regression suite (risks: data-corruption, data-breach). Tool class: test management. Usually run by: QA engineer.
   Done when: Install, update, uninstall and local-port cases rerun before each release, and any new listening port or deleted user file blocks it.
6. device and browser compatibility (risks: store-rejection, data-corruption). Tool class: device cloud. Usually run by: QA engineer.
   Done when: Install, update and uninstall cases pass with no Gatekeeper or SmartScreen warning on each supported macOS, Windows and Linux version and on both Intel and Arm machines where offered.
7. unit tests (risks: data-corruption). Tool class: unit framework. Usually run by: developer.
   Done when: In the test report, the cleanup and repair code refuses to delete the home folder, the root folder, an empty path or any folder the app did not create.
8. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist.
   Done when: A port and process scan of a test machine after install shows no listening service beyond those in the docs, and the bundled runtime has no known critical advisory.
9. data integrity and migration testing (risks: data-corruption). Tool class: data validation. Usually run by: QA engineer.
   Done when: A test profile with known files keeps the same file list and contents before and after each update, including files saved in redirected folders.

Acceptance criteria wording:
A release of the desktop application is accepted when the signed installer opens on clean macOS and Windows machines with no Gatekeeper or SmartScreen warning and passes notarization and Microsoft Store certification, with every installed helper named in the release notes. After install, update and uninstall with redirected Documents, every user file is still present, no helper remains and no listening service exists beyond those in the docs.

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.